Hi guys in the mooc (first example) we have the following expression (ZnEasy getPng: 'http://pharo.org/web/files/pharo.png') and it does not work anymore. I'm pair programming with Amal in Rennes from the university in italy and from her univ in Rennes we both get on 60 and 50 and time out https sslException: text code: code self error: (String streamContents: [ :stream | stream << 'SSL Exception: ' << text << ' [code:'. stream print: code. stream << ']' ]) Any idea. Tx in advance
On Fri, Mar 24, 2017 at 3:02 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi guys
in the mooc (first example) we have the following expression
(ZnEasy getPng: 'http://pharo.org/web/files/pharo.png')
and it does not work anymore. I'm pair programming with Amal in Rennes from the university in italy and from her univ in Rennes we both get on 60 and 50
and time out https
sslException: text code: code self error: (String streamContents: [ :stream | stream << 'SSL Exception: ' << text << ' [code:'. stream print: code. stream << ']' ])
Any idea.
Tx in advance
What platform are you on. On Windows 7, Pharo 60447, Win32 VM built on Mar 9 2017 16:38:45 CUT Compiler: 4.9.2 VMMaker versionString VM: 201703091627 I can confirm the same error with this... (ZnEasy getPng: 'http://pharo.org/web/files/pharo.png'). but picking some random SSL PNG, this works fine... (ZnEasy getPng: ' https://blog.keycdn.com/blog/wp-content/uploads/2015/10/http1-vs-http2.png' ). It is strange that you are getting an SSL error using http rather than https. It seems the server is redirecting to http to https and maybe this is not handled? https://geekflare.com/http-to-https-redirection/ When was the last update to rewrite rules on the server? cheers -ben
I can confirm it too on mac. A problem in the SSL plugin? (we know is not in the best shape⦠but Iâd like to know why this was working before and not it stopped). Esteban
On 24 Mar 2017, at 08:48, Ben Coman <btc@openInWorld.com> wrote:
On Fri, Mar 24, 2017 at 3:02 PM, Stephane Ducasse <stepharo.self@gmail.com <mailto:stepharo.self@gmail.com>> wrote: Hi guys
in the mooc (first example) we have the following expression
(ZnEasy getPng: 'http://pharo.org/web/files/pharo.png' <http://pharo.org/web/files/pharo.png'>)
and it does not work anymore. I'm pair programming with Amal in Rennes from the university in italy and from her univ in Rennes we both get on 60 and 50
and time out https
sslException: text code: code self error: (String streamContents: [ :stream | stream << 'SSL Exception: ' << text << ' [code:'. stream print: code. stream << ']' ])
Any idea.
Tx in advance
What platform are you on.
On Windows 7, Pharo 60447, Win32 VM built on Mar 9 2017 16:38:45 CUT Compiler: 4.9.2 VMMaker versionString VM: 201703091627 I can confirm the same error with this... (ZnEasy getPng: 'http://pharo.org/web/files/pharo.png' <http://pharo.org/web/files/pharo.png'>).
but picking some random SSL PNG, this works fine... (ZnEasy getPng: 'https://blog.keycdn.com/blog/wp-content/uploads/2015/10/http1-vs-http2.png' <https://blog.keycdn.com/blog/wp-content/uploads/2015/10/http1-vs-http2.png'>).
It is strange that you are getting an SSL error using http rather than https. It seems the server is redirecting to http to https and maybe this is not handled? https://geekflare.com/http-to-https-redirection/ <https://geekflare.com/http-to-https-redirection/>
When was the last update to rewrite rules on the server?
cheers -ben
Hmm, we'll have to study this better, since the following still works for me (while Stef's original URL, http://pharo.org/web/files/pharo.png, also fails for me): ZnEasy getPng: 'http://pharo.org/files/pharo.png'. This is also the URL used in the unit tests. Now, needless to say that the day Pharo cannot access its own server using TLS/SSL we are in trouble. I have warned about this before. We need to work on the SSL Plugin. Step one is the following: https://pharo.fogbugz.com/f/cases/19606/Switch-SSL-Plugin-Code-for-macOS-to-... Hopefully we can do something similar for Windows, but that is out of my area of expertise. Just to be clear: this is related to TLS/SSL (Zodiac), not Zinc. The problem is probably not in the fundamental logic of encrypting/decrypting the stream, but it in the setup of the connection, most probably related to certificates. Sven
On 24 Mar 2017, at 09:08, Esteban Lorenzano <estebanlm@gmail.com> wrote:
I can confirm it too on mac. A problem in the SSL plugin? (we know is not in the best shape⦠but Iâd like to know why this was working before and not it stopped).
Esteban
On 24 Mar 2017, at 08:48, Ben Coman <btc@openInWorld.com> wrote:
On Fri, Mar 24, 2017 at 3:02 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote: Hi guys
in the mooc (first example) we have the following expression
(ZnEasy getPng: 'http://pharo.org/web/files/pharo.png')
and it does not work anymore. I'm pair programming with Amal in Rennes from the university in italy and from her univ in Rennes we both get on 60 and 50
and time out https
sslException: text code: code self error: (String streamContents: [ :stream | stream << 'SSL Exception: ' << text << ' [code:'. stream print: code. stream << ']' ])
Any idea.
Tx in advance
What platform are you on.
On Windows 7, Pharo 60447, Win32 VM built on Mar 9 2017 16:38:45 CUT Compiler: 4.9.2 VMMaker versionString VM: 201703091627 I can confirm the same error with this... (ZnEasy getPng: 'http://pharo.org/web/files/pharo.png').
but picking some random SSL PNG, this works fine... (ZnEasy getPng: 'https://blog.keycdn.com/blog/wp-content/uploads/2015/10/http1-vs-http2.png').
It is strange that you are getting an SSL error using http rather than https. It seems the server is redirecting to http to https and maybe this is not handled? https://geekflare.com/http-to-https-redirection/
When was the last update to rewrite rules on the server?
cheers -ben
Some further notes.
On 24 Mar 2017, at 14:20, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hmm, we'll have to study this better, since the following still works for me (while Stef's original URL, http://pharo.org/web/files/pharo.png, also fails for me):
ZnEasy getPng: 'http://pharo.org/files/pharo.png'.
This is also the URL used in the unit tests.
Of course that one works, because it does not do a redirect from HTTP to HTTPS, duh. Still it is good to known that at least for examples/demos/tests we still have it.
Now, needless to say that the day Pharo cannot access its own server using TLS/SSL we are in trouble. I have warned about this before. We need to work on the SSL Plugin. Step one is the following:
https://pharo.fogbugz.com/f/cases/19606/Switch-SSL-Plugin-Code-for-macOS-to-...
Hopefully we can do something similar for Windows, but that is out of my area of expertise.
Just to be clear: this is related to TLS/SSL (Zodiac), not Zinc. The problem is probably not in the fundamental logic of encrypting/decrypting the stream, but it in the setup of the connection, most probably related to certificates.
I took a file from one of my servers that it up to date and well configured (nginx, let's encrypt certificate). That works fine. ZnEasy getJpeg: 'https://audio359.eu/img/audio359-main-800.jpg'. Testing our failing URL and this succeeding URL using curl on macOS, I see the following: $ curl -v https://audio359.eu/img/audio359-main-800.jpg > /dev/null * TCP_NODELAY set * Connected to audio359.eu (146.185.177.20) port 443 (#0) * TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 * Server certificate: audio359.eu * Server certificate: Let's Encrypt Authority X3 * Server certificate: DST Root CA X3
GET /img/audio359-main-800.jpg HTTP/1.1 ...
vs. $ curl -v https://pharo.org/web/files/pharo.png > /dev/null * TCP_NODELAY set * Connected to pharo.org (104.28.26.35) port 443 (#0) * TLS 1.2 connection using TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 * Server certificate: sni25155.cloudflaressl.com * Server certificate: COMODO ECC Domain Validation Secure Server CA 2 * Server certificate: COMODO ECC Certification Authority
GET /web/files/pharo.png HTTP/1.1 ...
I see 2 differences: - a different cipher suite (combination of algorithms used) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 vs. TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 with the key differences being RSA vs ECDSA - at least an indication of SNI (server name identification) being used I guess we have no control over how our website is served, since the CMS used (and cloud flare CDN being involved).
Sven
On 24 Mar 2017, at 09:08, Esteban Lorenzano <estebanlm@gmail.com> wrote:
I can confirm it too on mac. A problem in the SSL plugin? (we know is not in the best shape⦠but Iâd like to know why this was working before and not it stopped).
Esteban
On 24 Mar 2017, at 08:48, Ben Coman <btc@openInWorld.com> wrote:
On Fri, Mar 24, 2017 at 3:02 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote: Hi guys
in the mooc (first example) we have the following expression
(ZnEasy getPng: 'http://pharo.org/web/files/pharo.png')
and it does not work anymore. I'm pair programming with Amal in Rennes from the university in italy and from her univ in Rennes we both get on 60 and 50
and time out https
sslException: text code: code self error: (String streamContents: [ :stream | stream << 'SSL Exception: ' << text << ' [code:'. stream print: code. stream << ']' ])
Any idea.
Tx in advance
What platform are you on.
On Windows 7, Pharo 60447, Win32 VM built on Mar 9 2017 16:38:45 CUT Compiler: 4.9.2 VMMaker versionString VM: 201703091627 I can confirm the same error with this... (ZnEasy getPng: 'http://pharo.org/web/files/pharo.png').
but picking some random SSL PNG, this works fine... (ZnEasy getPng: 'https://blog.keycdn.com/blog/wp-content/uploads/2015/10/http1-vs-http2.png').
It is strange that you are getting an SSL error using http rather than https. It seems the server is redirecting to http to https and maybe this is not handled? https://geekflare.com/http-to-https-redirection/
When was the last update to rewrite rules on the server?
cheers -ben
On Sat, Mar 25, 2017 at 2:04 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Some further notes.
On 24 Mar 2017, at 14:20, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hmm, we'll have to study this better, since the following still works for me (while Stef's original URL, http://pharo.org/web/files/pharo.png, also fails for me):
ZnEasy getPng: 'http://pharo.org/files/pharo.png'.
This is also the URL used in the unit tests.
Of course that one works, because it does not do a redirect from HTTP to HTTPS, duh. Still it is good to known that at least for examples/demos/tests we still have it.
Now, needless to say that the day Pharo cannot access its own server using TLS/SSL we are in trouble. I have warned about this before. We need to work on the SSL Plugin. Step one is the following:
https://pharo.fogbugz.com/f/cases/19606/Switch-SSL-Plugin-Code-for-macOS-to-...
Hopefully we can do something similar for Windows, but that is out of my area of expertise.
Just to be clear: this is related to TLS/SSL (Zodiac), not Zinc. The problem is probably not in the fundamental logic of encrypting/decrypting the stream, but it in the setup of the connection, most probably related to certificates.
I took a file from one of my servers that it up to date and well configured (nginx, let's encrypt certificate). That works fine.
ZnEasy getJpeg: 'https://audio359.eu/img/audio359-main-800.jpg'.
Testing our failing URL and this succeeding URL using curl on macOS, I see the following:
$ curl -v https://audio359.eu/img/audio359-main-800.jpg > /dev/null * TCP_NODELAY set * Connected to audio359.eu (146.185.177.20) port 443 (#0) * TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 * Server certificate: audio359.eu * Server certificate: Let's Encrypt Authority X3 * Server certificate: DST Root CA X3
GET /img/audio359-main-800.jpg HTTP/1.1 ...
vs.
$ curl -v https://pharo.org/web/files/pharo.png > /dev/null * TCP_NODELAY set * Connected to pharo.org (104.28.26.35) port 443 (#0) * TLS 1.2 connection using TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 * Server certificate: sni25155.cloudflaressl.com * Server certificate: COMODO ECC Domain Validation Secure Server CA 2 * Server certificate: COMODO ECC Certification Authority
GET /web/files/pharo.png HTTP/1.1 ...
I see 2 differences:
- a different cipher suite (combination of algorithms used) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 vs. TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 with the key differences being RSA vs ECDSA - at least an indication of SNI (server name identification) being used
I guess we have no control over how our website is served, since the CMS used (and cloud flare CDN being involved).
For Cloudflare customers at the free level of service Sites using UniversalSSL are issued SHA2+ECDSA certificates, which require clients that support TLSv1.2 and SNI. For customers at a paid level of service Cloudflare's server configuration for TLS cipher suites is set in nginx (which we use extensively) with the following configuration command: ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers EECDH+CHACHA20:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5; ssl_prefer_server_ciphers on; https://support.cloudflare.com/hc/en-us/articles/200933580-What-cipher-suite... The Real Cost of a CloudFlare âFreeâ SSL Certificate https://info.ssl.com/the-real-cost-of-a-cloudflare-free-ssl-certificate/ SSL on my free plan isn't working on an old OS/Browser https://support.cloudflare.com/hc/en-us/articles/204144518-SSL-FAQ cheers -ben
Sven
On 24 Mar 2017, at 09:08, Esteban Lorenzano <estebanlm@gmail.com> wrote:
I can confirm it too on mac. A problem in the SSL plugin? (we know is not in the best shape⦠but Iâd like to know why this was working before and not it stopped).
Esteban
On 24 Mar 2017, at 08:48, Ben Coman <btc@openInWorld.com> wrote:
On Fri, Mar 24, 2017 at 3:02 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote: Hi guys
in the mooc (first example) we have the following expression
(ZnEasy getPng: 'http://pharo.org/web/files/pharo.png')
and it does not work anymore. I'm pair programming with Amal in Rennes from the university in italy and from her univ in Rennes we both get on 60 and 50
and time out https
sslException: text code: code self error: (String streamContents: [ :stream | stream << 'SSL Exception: ' << text << ' [code:'. stream print: code. stream << ']' ])
Any idea.
Tx in advance
What platform are you on.
On Windows 7, Pharo 60447, Win32 VM built on Mar 9 2017 16:38:45 CUT Compiler: 4.9.2 VMMaker versionString VM: 201703091627 I can confirm the same error with this... (ZnEasy getPng: 'http://pharo.org/web/files/pharo.png').
but picking some random SSL PNG, this works fine... (ZnEasy getPng: 'https://blog.keycdn.com/blog/wp-content/uploads/2015/10/http1-vs-http2.png').
It is strange that you are getting an SSL error using http rather than https. It seems the server is redirecting to http to https and maybe this is not handled? https://geekflare.com/http-to-https-redirection/
When was the last update to rewrite rules on the server?
cheers -ben
Very interesting findings. I am always delighted by your investigations Ben, that is inspiring me a lot to be a better programmer. Security is a large beast and it becomes more and more pervasive in the projects. I was busy with some more Kerberos yesterday and it would be very useful for me to have support for it in Pharo natively. Kerberos looks complicated until one realizes that there is nothing like it for doing what it does in a simple way :-D HTTP/2 is also there now and we will have to support this too. Phil On Sat, Mar 25, 2017 at 12:37 AM, Ben Coman <btc@openinworld.com> wrote:
On Sat, Mar 25, 2017 at 2:04 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Some further notes.
On 24 Mar 2017, at 14:20, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hmm, we'll have to study this better, since the following still works
for me (while Stef's original URL, http://pharo.org/web/files/pharo.png, also fails for me):
ZnEasy getPng: 'http://pharo.org/files/pharo.png'.
This is also the URL used in the unit tests.
Of course that one works, because it does not do a redirect from HTTP to HTTPS, duh. Still it is good to known that at least for examples/demos/tests we still have it.
Now, needless to say that the day Pharo cannot access its own server using TLS/SSL we are in trouble. I have warned about this before. We need to work on the SSL Plugin. Step one is the following:
https://pharo.fogbugz.com/f/cases/19606/Switch-SSL-Plugin- Code-for-macOS-to-openssl
Hopefully we can do something similar for Windows, but that is out of my area of expertise.
Just to be clear: this is related to TLS/SSL (Zodiac), not Zinc. The problem is probably not in the fundamental logic of encrypting/decrypting the stream, but it in the setup of the connection, most probably related to certificates.
I took a file from one of my servers that it up to date and well configured (nginx, let's encrypt certificate). That works fine.
ZnEasy getJpeg: 'https://audio359.eu/img/audio359-main-800.jpg'.
Testing our failing URL and this succeeding URL using curl on macOS, I see the following:
$ curl -v https://audio359.eu/img/audio359-main-800.jpg > /dev/null * TCP_NODELAY set * Connected to audio359.eu (146.185.177.20) port 443 (#0) * TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 * Server certificate: audio359.eu * Server certificate: Let's Encrypt Authority X3 * Server certificate: DST Root CA X3
GET /img/audio359-main-800.jpg HTTP/1.1 ...
vs.
$ curl -v https://pharo.org/web/files/pharo.png > /dev/null * TCP_NODELAY set * Connected to pharo.org (104.28.26.35) port 443 (#0) * TLS 1.2 connection using TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 * Server certificate: sni25155.cloudflaressl.com * Server certificate: COMODO ECC Domain Validation Secure Server CA 2 * Server certificate: COMODO ECC Certification Authority
GET /web/files/pharo.png HTTP/1.1 ...
I see 2 differences:
- a different cipher suite (combination of algorithms used) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 vs. TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 with the key differences being RSA vs ECDSA - at least an indication of SNI (server name identification) being used
I guess we have no control over how our website is served, since the CMS used (and cloud flare CDN being involved).
For Cloudflare customers at the free level of service Sites using UniversalSSL are issued SHA2+ECDSA certificates, which require clients that support TLSv1.2 and SNI.
For customers at a paid level of service Cloudflare's server configuration for TLS cipher suites is set in nginx (which we use extensively) with the following configuration command: ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers EECDH+CHACHA20:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+ AES256:EECDH+3DES:RSA+3DES:!MD5; ssl_prefer_server_ciphers on;
https://support.cloudflare.com/hc/en-us/articles/ 200933580-What-cipher-suites-does-Cloudflare-use-for-SSL-
The Real Cost of a CloudFlare âFreeâ SSL Certificate https://info.ssl.com/the-real-cost-of-a-cloudflare-free-ssl-certificate/
SSL on my free plan isn't working on an old OS/Browser https://support.cloudflare.com/hc/en-us/articles/204144518-SSL-FAQ
cheers -ben
Sven
On 24 Mar 2017, at 09:08, Esteban Lorenzano <estebanlm@gmail.com>
wrote:
I can confirm it too on mac. A problem in the SSL plugin? (we know is not in the best shape⦠but
Iâd like to know why this was working before and not it stopped).
Esteban
On 24 Mar 2017, at 08:48, Ben Coman <btc@openInWorld.com> wrote:
On Fri, Mar 24, 2017 at 3:02 PM, Stephane Ducasse <
stepharo.self@gmail.com> wrote:
Hi guys
in the mooc (first example) we have the following expression
(ZnEasy getPng: 'http://pharo.org/web/files/pharo.png')
and it does not work anymore. I'm pair programming with Amal in Rennes from the university in italy and from her univ in Rennes we both get on 60 and 50
and time out https
sslException: text code: code self error: (String streamContents: [ :stream | stream << 'SSL Exception: ' << text << ' [code:'. stream print: code. stream << ']' ])
Any idea.
Tx in advance
What platform are you on.
On Windows 7, Pharo 60447, Win32 VM built on Mar 9 2017 16:38:45 CUT Compiler: 4.9.2 VMMaker versionString VM: 201703091627 I can confirm the same error with this... (ZnEasy getPng: 'http://pharo.org/web/files/pharo.png').
but picking some random SSL PNG, this works fine... (ZnEasy getPng: 'https://blog.keycdn.com/blog/ wp-content/uploads/2015/10/http1-vs-http2.png').
It is strange that you are getting an SSL error using http rather than https. It seems the server is redirecting to http to https and maybe this is not handled? https://geekflare.com/http-to-https-redirection/
When was the last update to rewrite rules on the server?
cheers -ben
On Sat, Mar 25, 2017 at 4:50 PM, phil@highoctane.be <phil@highoctane.be> wrote:
Very interesting findings.
I am always delighted by your investigations Ben, that is inspiring me a lot to be a better programmer
Just a compulsion to pull on a loose thread and see where it leads. Don't ever lend me a knitted jumper with a loose thread ;) cheers -ben
Security is a large beast and it becomes more and more pervasive in the projects. I was busy with some more Kerberos yesterday and it would be very useful for me to have support for it in Pharo natively. Kerberos looks complicated until one realizes that there is nothing like it for doing what it does in a simple way :-D
And from Kerberos its only a hop, skip and jump to in-Image support of Microsoft's bastardised Kerberos for Windows authentication. (errr, maybe thats a wish too far .) cheers -ben
HTTP/2 is also there now and we will have to support this too.
Phil
On Sat, Mar 25, 2017 at 12:37 AM, Ben Coman <btc@openinworld.com> wrote:
On Sat, Mar 25, 2017 at 2:04 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Some further notes.
On 24 Mar 2017, at 14:20, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hmm, we'll have to study this better, since the following still works for me (while Stef's original URL, http://pharo.org/web/files/pharo.png, also fails for me):
ZnEasy getPng: 'http://pharo.org/files/pharo.png'.
This is also the URL used in the unit tests.
Of course that one works, because it does not do a redirect from HTTP to HTTPS, duh. Still it is good to known that at least for examples/demos/tests we still have it.
Now, needless to say that the day Pharo cannot access its own server using TLS/SSL we are in trouble. I have warned about this before. We need to work on the SSL Plugin. Step one is the following:
https://pharo.fogbugz.com/f/cases/19606/Switch-SSL-Plugin-Code-for-macOS-to-...
Hopefully we can do something similar for Windows, but that is out of my area of expertise.
Just to be clear: this is related to TLS/SSL (Zodiac), not Zinc. The problem is probably not in the fundamental logic of encrypting/decrypting the stream, but it in the setup of the connection, most probably related to certificates.
I took a file from one of my servers that it up to date and well configured (nginx, let's encrypt certificate). That works fine.
ZnEasy getJpeg: 'https://audio359.eu/img/audio359-main-800.jpg'.
Testing our failing URL and this succeeding URL using curl on macOS, I see the following:
$ curl -v https://audio359.eu/img/audio359-main-800.jpg > /dev/null * TCP_NODELAY set * Connected to audio359.eu (146.185.177.20) port 443 (#0) * TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 * Server certificate: audio359.eu * Server certificate: Let's Encrypt Authority X3 * Server certificate: DST Root CA X3
GET /img/audio359-main-800.jpg HTTP/1.1 ...
vs.
$ curl -v https://pharo.org/web/files/pharo.png > /dev/null * TCP_NODELAY set * Connected to pharo.org (104.28.26.35) port 443 (#0) * TLS 1.2 connection using TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 * Server certificate: sni25155.cloudflaressl.com * Server certificate: COMODO ECC Domain Validation Secure Server CA 2 * Server certificate: COMODO ECC Certification Authority
GET /web/files/pharo.png HTTP/1.1 ...
I see 2 differences:
- a different cipher suite (combination of algorithms used) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 vs. TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 with the key differences being RSA vs ECDSA - at least an indication of SNI (server name identification) being used
I guess we have no control over how our website is served, since the CMS used (and cloud flare CDN being involved).
For Cloudflare customers at the free level of service Sites using UniversalSSL are issued SHA2+ECDSA certificates, which require clients that support TLSv1.2 and SNI.
For customers at a paid level of service Cloudflare's server configuration for TLS cipher suites is set in nginx (which we use extensively) with the following configuration command: ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers EECDH+CHACHA20:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5; ssl_prefer_server_ciphers on;
https://support.cloudflare.com/hc/en-us/articles/200933580-What-cipher-suite...
The Real Cost of a CloudFlare âFreeâ SSL Certificate https://info.ssl.com/the-real-cost-of-a-cloudflare-free-ssl-certificate/
SSL on my free plan isn't working on an old OS/Browser https://support.cloudflare.com/hc/en-us/articles/204144518-SSL-FAQ
cheers -ben
Sven
On 24 Mar 2017, at 09:08, Esteban Lorenzano <estebanlm@gmail.com> wrote:
I can confirm it too on mac. A problem in the SSL plugin? (we know is not in the best shape⦠but Iâd like to know why this was working before and not it stopped).
Esteban
On 24 Mar 2017, at 08:48, Ben Coman <btc@openInWorld.com> wrote:
On Fri, Mar 24, 2017 at 3:02 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote: Hi guys
in the mooc (first example) we have the following expression
(ZnEasy getPng: 'http://pharo.org/web/files/pharo.png')
and it does not work anymore. I'm pair programming with Amal in Rennes from the university in italy and from her univ in Rennes we both get on 60 and 50
and time out https
sslException: text code: code self error: (String streamContents: [ :stream | stream << 'SSL Exception: ' << text << ' [code:'. stream print: code. stream << ']' ])
Any idea.
Tx in advance
What platform are you on.
On Windows 7, Pharo 60447, Win32 VM built on Mar 9 2017 16:38:45 CUT Compiler: 4.9.2 VMMaker versionString VM: 201703091627 I can confirm the same error with this... (ZnEasy getPng: 'http://pharo.org/web/files/pharo.png').
but picking some random SSL PNG, this works fine... (ZnEasy getPng: 'https://blog.keycdn.com/blog/wp-content/uploads/2015/10/http1-vs-http2.png').
It is strange that you are getting an SSL error using http rather than https. It seems the server is redirecting to http to https and maybe this is not handled? https://geekflare.com/http-to-https-redirection/
When was the last update to rewrite rules on the server?
cheers -ben
On 25 Mar 2017, at 00:37, Ben Coman <btc@openinworld.com> wrote:
On Sat, Mar 25, 2017 at 2:04 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Some further notes.
On 24 Mar 2017, at 14:20, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hmm, we'll have to study this better, since the following still works for me (while Stef's original URL, http://pharo.org/web/files/pharo.png, also fails for me):
ZnEasy getPng: 'http://pharo.org/files/pharo.png'.
This is also the URL used in the unit tests.
Of course that one works, because it does not do a redirect from HTTP to HTTPS, duh. Still it is good to known that at least for examples/demos/tests we still have it.
Now, needless to say that the day Pharo cannot access its own server using TLS/SSL we are in trouble. I have warned about this before. We need to work on the SSL Plugin. Step one is the following:
https://pharo.fogbugz.com/f/cases/19606/Switch-SSL-Plugin-Code-for-macOS-to-...
Hopefully we can do something similar for Windows, but that is out of my area of expertise.
Just to be clear: this is related to TLS/SSL (Zodiac), not Zinc. The problem is probably not in the fundamental logic of encrypting/decrypting the stream, but it in the setup of the connection, most probably related to certificates.
I took a file from one of my servers that it up to date and well configured (nginx, let's encrypt certificate). That works fine.
ZnEasy getJpeg: 'https://audio359.eu/img/audio359-main-800.jpg'.
Testing our failing URL and this succeeding URL using curl on macOS, I see the following:
$ curl -v https://audio359.eu/img/audio359-main-800.jpg > /dev/null * TCP_NODELAY set * Connected to audio359.eu (146.185.177.20) port 443 (#0) * TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 * Server certificate: audio359.eu * Server certificate: Let's Encrypt Authority X3 * Server certificate: DST Root CA X3
GET /img/audio359-main-800.jpg HTTP/1.1 ...
vs.
$ curl -v https://pharo.org/web/files/pharo.png > /dev/null * TCP_NODELAY set * Connected to pharo.org (104.28.26.35) port 443 (#0) * TLS 1.2 connection using TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 * Server certificate: sni25155.cloudflaressl.com * Server certificate: COMODO ECC Domain Validation Secure Server CA 2 * Server certificate: COMODO ECC Certification Authority
GET /web/files/pharo.png HTTP/1.1 ...
I see 2 differences:
- a different cipher suite (combination of algorithms used) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 vs. TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 with the key differences being RSA vs ECDSA - at least an indication of SNI (server name identification) being used
I guess we have no control over how our website is served, since the CMS used (and cloud flare CDN being involved).
For Cloudflare customers at the free level of service Sites using UniversalSSL are issued SHA2+ECDSA certificates, which require clients that support TLSv1.2 and SNI.
For customers at a paid level of service Cloudflare's server configuration for TLS cipher suites is set in nginx (which we use extensively) with the following configuration command: ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers EECDH+CHACHA20:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5; ssl_prefer_server_ciphers on;
https://support.cloudflare.com/hc/en-us/articles/200933580-What-cipher-suite...
The Real Cost of a CloudFlare âFreeâ SSL Certificate https://info.ssl.com/the-real-cost-of-a-cloudflare-free-ssl-certificate/
SSL on my free plan isn't working on an old OS/Browser https://support.cloudflare.com/hc/en-us/articles/204144518-SSL-FAQ
cheers -ben
That is why I already started https://pharo.fogbugz.com/f/cases/19864/Add-support-for-Server-Name-Indicati...
Sven
On 24 Mar 2017, at 09:08, Esteban Lorenzano <estebanlm@gmail.com> wrote:
I can confirm it too on mac. A problem in the SSL plugin? (we know is not in the best shape⦠but Iâd like to know why this was working before and not it stopped).
Esteban
On 24 Mar 2017, at 08:48, Ben Coman <btc@openInWorld.com> wrote:
On Fri, Mar 24, 2017 at 3:02 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote: Hi guys
in the mooc (first example) we have the following expression
(ZnEasy getPng: 'http://pharo.org/web/files/pharo.png')
and it does not work anymore. I'm pair programming with Amal in Rennes from the university in italy and from her univ in Rennes we both get on 60 and 50
and time out https
sslException: text code: code self error: (String streamContents: [ :stream | stream << 'SSL Exception: ' << text << ' [code:'. stream print: code. stream << ']' ])
Any idea.
Tx in advance
What platform are you on.
On Windows 7, Pharo 60447, Win32 VM built on Mar 9 2017 16:38:45 CUT Compiler: 4.9.2 VMMaker versionString VM: 201703091627 I can confirm the same error with this... (ZnEasy getPng: 'http://pharo.org/web/files/pharo.png').
but picking some random SSL PNG, this works fine... (ZnEasy getPng: 'https://blog.keycdn.com/blog/wp-content/uploads/2015/10/http1-vs-http2.png').
It is strange that you are getting an SSL error using http rather than https. It seems the server is redirecting to http to https and maybe this is not handled? https://geekflare.com/http-to-https-redirection/
When was the last update to rewrite rules on the server?
cheers -ben
On Fri, Mar 24, 2017 at 3:48 PM, Ben Coman <btc@openinworld.com> wrote:
On Fri, Mar 24, 2017 at 3:02 PM, Stephane Ducasse <stepharo.self@gmail.com
wrote:
Hi guys
in the mooc (first example) we have the following expression
(ZnEasy getPng: 'http://pharo.org/web/files/pharo.png')
and it does not work anymore. I'm pair programming with Amal in Rennes from the university in italy and from her univ in Rennes we both get on 60 and 50
and time out https
sslException: text code: code self error: (String streamContents: [ :stream | stream << 'SSL Exception: ' << text << ' [code:'. stream print: code. stream << ']' ])
Any idea.
Tx in advance
What platform are you on.
On Windows 7, Pharo 60447, Win32 VM built on Mar 9 2017 16:38:45 CUT Compiler: 4.9.2 VMMaker versionString VM: 201703091627 I can confirm the same error with this... (ZnEasy getPng: 'http://pharo.org/web/files/pharo.png').
but picking some random SSL PNG, this works fine... (ZnEasy getPng: 'https://blog.keycdn.com/blog/wp-content/uploads/2015/10/ http1-vs-http2.png').
It is strange that you are getting an SSL error using http rather than https. It seems the server is redirecting to http to https and maybe this is not handled? https://geekflare.com/http-to-https-redirection/
Nope. Thats not it. Same problem with... ZnEasy getPng: 'https://pharo.org:443/web/files/pharo.png' Now if I put this hack in ZdcSecureSocketStream>>connect.... [ (result := self sslSession connect: in from: 1 to: count into: out). Transcript crShow: result. result = 0 ] whileFalse: [ .... ZnEasy getPng: 'https://blog.keycdn.com/blog/wp-content/uploads/2015/10/ http1-vs-http2.png'. ==> 99 134 0 while... ZnEasy getPng: 'https://pharo.org:443/web/files/pharo.png' ==> 99 -5 If I try the same in Pharo5.0-ReleaseWin32, build 50761, VM built on May 4 2016 12:17:02 Compiler: 4.6.2 VMMaker versionString https://github.com/pharo-project/pharo-vm.git Commit: b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200 By: Esteban Lorenzano <estebanlm@gmail.com> Jenkins build #589 ZnEasy getPng: 'https://pharo.org:443/web/files/pharo.png' ==> 292 -1
On Fri, Mar 24, 2017 at 4:11 PM, Ben Coman <btc@openinworld.com> wrote:
On Fri, Mar 24, 2017 at 3:48 PM, Ben Coman <btc@openinworld.com> wrote:
On Fri, Mar 24, 2017 at 3:02 PM, Stephane Ducasse <
stepharo.self@gmail.com> wrote:
Hi guys
in the mooc (first example) we have the following expression
(ZnEasy getPng: 'http://pharo.org/web/files/pharo.png')
and it does not work anymore. I'm pair programming with Amal in Rennes from the university in italy and from her univ in Rennes we both get on 60 and 50
and time out https
sslException: text code: code self error: (String streamContents: [ :stream | stream << 'SSL Exception: ' << text << ' [code:'. stream print: code. stream << ']' ])
Any idea.
Tx in advance
What platform are you on.
On Windows 7, Pharo 60447, Win32 VM built on Mar 9 2017 16:38:45 CUT Compiler: 4.9.2 VMMaker versionString VM: 201703091627 I can confirm the same error with this... (ZnEasy getPng: 'http://pharo.org/web/files/pharo.png').
but picking some random SSL PNG, this works fine... (ZnEasy getPng: ' https://blog.keycdn.com/blog/wp-content/uploads/2015/10/http1-vs-http2.png' ).
It is strange that you are getting an SSL error using http rather than https. It seems the server is redirecting to http to https and maybe this is not handled? https://geekflare.com/http-to-https-redirection/
Nope. Thats not it. Same problem with... ZnEasy getPng: 'https://pharo.org:443/web/files/pharo.png'
Now if I put this hack in ZdcSecureSocketStream>>connect.... [ (result := self sslSession connect: in from: 1 to: count into: out). Transcript crShow: result. result = 0 ] whileFalse: [ ....
ZnEasy getPng: ' https://blog.keycdn.com/blog/wp-content/uploads/2015/10/http1-vs-http2.png'. ==> 99 134 0
while... ZnEasy getPng: 'https://pharo.org:443/web/files/pharo.png' ==> 99 -5
If I try the same in Pharo5.0-ReleaseWin32, build 50761, VM built on May 4 2016 12:17:02 Compiler: 4.6.2 VMMaker versionString https://github.com/pharo-project/pharo-vm.git Commit: b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200 By: Esteban Lorenzano <estebanlm@gmail.com> Jenkins build #589
ZnEasy getPng: 'https://pharo.org:443/web/files/pharo.png' ==> 292 -1
In Chrome, after opening each of the following and going... More Tools > Developer Tools > Security I see a difference... * https://pharo.org:443/web/files/pharo.png The connection to this site is encrypted and authenticated using a strong protocol (TLS 1.2), a strong key exchange (ECDHE_ECDSA with P-256), and a strong cipher (AES_128_GCM). * https://blog.keycdn.com/blog/wp-content/uploads/2015/10/http1-vs-http2.png The connection to this site is encrypted and authenticated using a strong protocol (TLS 1.2), a strong key exchange (ECDHE_RSA with P-256), and a strong cipher (AES_256_GCM). I haven't parsed this properly, but maybe related https://github.com/openssl/openssl/issues/2658 This server itself seems okay... https://www.thesslstore.com/ssltools/ssl-checker.php?hostname=pharo.org#resu... cheers -ben
participants (5)
-
Ben Coman -
Esteban Lorenzano -
phil＠highoctane.be -
Stephane Ducasse -
Sven Van Caekenberghe