On 27.04.2017, at 19:15, Levente Uzonyi leves@caesar.elte.hu wrote:

2 years ago I implented a solution for this problem on Linux (actually platforms using OpenSSL), which integrated well with the way SqueakSSL worked (and still works)[1]. There was a plan for a better fix, but as it turned out, that was a mistake not to push the changes, because the new plan would require way too large effort to be done.

mea culpa.

In the meantime, I have contributed to the libressl project, so that their libtls can be used in our setting.

I have the first steps in a branch here: https://github.com/squeak-smalltalk/squeakssl/blob/libressl-unix/src/unix/sq...

The problem with the way of your checking that I see is that it requires actual checking work on the image side. What would work now is, that, since we actually have the server name via stringProperty 2

(SqueakSSL>>serverName: aString

^[ self primitiveSSL: handle setStringProperty: 2 toValue: aString ] on: Error ) do: [ "nothing" ]

and it is nearly always set, we could use that on the plugin side, until a new scheme arrives™.

So: IF we're on Linux AND we have a serverName AND we see SANs in a cert[1] THEN iterate the SANs and compare to serverName AND set validation level. (all in the plugin)

Levente, what do you think?

-=-=-=-=

My main problem currently is, that we will always happily connect to any site and just _after_ the fact will check whether everything's ok or not. Thats a hard security issue. I promise to come up with something better…

-=-=-=-=

IMHO, disabling verification is clearly not the solution.

It works on Windows, but sadly only on windows… (because we disable it for mac before we connect)

Best regards -Tobias

[1]: chrome now forces SANs https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/IGT2fLJr...

Levente

[1] http://forum.world.st/SqueakSSL-SAN-certificates-td4828767.html

On Thu, 27 Apr 2017, commits@source.squeak.org wrote:

...

A new version of WebClient-Core was added to project The Inbox: http://source.squeak.org/inbox/WebClient-Core-fn.105.mcz

==================== Summary ====================

Name: WebClient-Core-fn.105 Author: fn Time: 27 April 2017, 6:32:47.94973 pm UUID: 9d163339-62e5-4248-b3c4-773616160ea0 Ancestors: WebClient-Core-jr.104

Disable certificate validation on all platforms for the time being. It turns out, this does not only probably work on macOS, but also on Windows and Linux. The WebClient seems to have problems with some certificates used for popular domains, e.g. google.com and github.com. The Zinc library does not perform the validation as well at the moment.

=============== Diff against WebClient-Core-jr.104 ===============

Item was changed: ----- Method: WebClient>>sslConnect (in category 'initialize') ----- sslConnect "Do the SSL handshake" "Connect the client to a web server"

| sqSSL | proxyServer ifNotNil:[ | resp | "If we have a proxy server, do the proxy connect" resp := self proxyConnect. resp isSuccess ifFalse:[^resp]. ].

sqSSL := Smalltalk at: #SqueakSSL ifAbsent:[self error: 'SqueakSSL is missing']. "Convert the stream to a secure stream" stream := sqSSL secureSocketStream on: stream socket. stream timeout: timeout. self sslConnect: stream to: lastServer.

• • "Normally, we would verify the cert now, but this does not work properly"
• "stream verifyCert: self serverName."
• • "And cert verification

• (unless on OSX, where this does not work yet)"
• WebUtils platformName = 'Mac OS'

• ifFalse: [stream verifyCert: self serverName].
  

  ^ nil"indicating success"

!

On Thu, 27 Apr 2017, Tobias Pape wrote:

...

On 27.04.2017, at 19:15, Levente Uzonyi leves@caesar.elte.hu wrote:

2 years ago I implented a solution for this problem on Linux (actually platforms using OpenSSL), which integrated well with the way SqueakSSL worked (and still works)[1]. There was a plan for a better fix, but as it turned out, that was a mistake not to push the changes, because the new plan would require way too large effort to be done.

mea culpa.

In the meantime, I have contributed to the libressl project, so that their libtls can be used in our setting.

I have the first steps in a branch here: https://github.com/squeak-smalltalk/squeakssl/blob/libressl-unix/src/unix/sq...

The problem with the way of your checking that I see is that it requires actual checking work on the image side. What would work now is, that, since we actually have the server name via stringProperty 2

(SqueakSSL>>serverName: aString

^[ self primitiveSSL: handle setStringProperty: 2 toValue: aString ] on: Error ) do: [ "nothing" ]

and it is nearly always set, we could use that on the plugin side, until a new scheme arrives™.

So: IF we're on Linux AND we have a serverName AND we see SANs in a cert[1] THEN iterate the SANs and compare to serverName AND set validation level. (all in the plugin)

Levente, what do you think?

The question is still who will do it and when.

-=-=-=-=

My main problem currently is, that we will always happily connect to any site and just _after_ the fact will check whether everything's ok or not. Thats a hard security issue. I promise to come up with something better…

What do you mean by that? How could you verify the site's certificate without connecting to it? :)

Levente

-=-=-=-=

...

IMHO, disabling verification is clearly not the solution.

It works on Windows, but sadly only on windows… (because we disable it for mac before we connect)

Best regards -Tobias

[1]: chrome now forces SANs https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/IGT2fLJr...

...

Levente

[1] http://forum.world.st/SqueakSSL-SAN-certificates-td4828767.html

On Thu, 27 Apr 2017, commits@source.squeak.org wrote:

...

A new version of WebClient-Core was added to project The Inbox: http://source.squeak.org/inbox/WebClient-Core-fn.105.mcz

==================== Summary ====================

Name: WebClient-Core-fn.105 Author: fn Time: 27 April 2017, 6:32:47.94973 pm UUID: 9d163339-62e5-4248-b3c4-773616160ea0 Ancestors: WebClient-Core-jr.104

Disable certificate validation on all platforms for the time being. It turns out, this does not only probably work on macOS, but also on Windows and Linux. The WebClient seems to have problems with some certificates used for popular domains, e.g. google.com and github.com. The Zinc library does not perform the validation as well at the moment.

=============== Diff against WebClient-Core-jr.104 ===============

Item was changed: ----- Method: WebClient>>sslConnect (in category 'initialize') ----- sslConnect "Do the SSL handshake" "Connect the client to a web server"

| sqSSL | proxyServer ifNotNil:[ | resp | "If we have a proxy server, do the proxy connect" resp := self proxyConnect. resp isSuccess ifFalse:[^resp]. ].

sqSSL := Smalltalk at: #SqueakSSL ifAbsent:[self error: 'SqueakSSL is missing']. "Convert the stream to a secure stream" stream := sqSSL secureSocketStream on: stream socket. stream timeout: timeout. self sslConnect: stream to: lastServer.

• • "Normally, we would verify the cert now, but this does not work properly"
• "stream verifyCert: self serverName."
• • "And cert verification

• (unless on OSX, where this does not work yet)"
• WebUtils platformName = 'Mac OS'

• ifFalse: [stream verifyCert: self serverName].
  

  ^ nil"indicating success"

!