The Inbox: WebClient-Core-fn.105.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

The Inbox: WebClient-Core-fn.105.mcz

commits-2
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"
  !


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: WebClient-Core-fn.105.mcz

Levente Uzonyi
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.
IMHO, disabling verification is clearly not the solution.

Levente

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

On Thu, 27 Apr 2017, [hidden email] 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"
>  !

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: WebClient-Core-fn.105.mcz

fniephaus
Hi Levente,

just to explain the change on a meta level: I don't like it either, and it's definitely not the solution to the problem. But, for the time being, it's probably better to be able to access web resources than getting a debugger. On the other hand, it's already as bad for macOS users ;)
Anyhow, I agree that we need to work on a better solution and it's unfortunate, you didn't integrate your implementation. I'm afraid I don't have enough time at the moment, but will look into this again at some point if no one else is quicker...

Fabio

--

On Thu, Apr 27, 2017 at 7:15 PM Levente Uzonyi <[hidden email]> 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.
IMHO, disabling verification is clearly not the solution.

Levente

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

On Thu, 27 Apr 2017, [hidden email] 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"
>  !



Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: WebClient-Core-fn.105.mcz

Tobias Pape
In reply to this post by Levente Uzonyi

> On 27.04.2017, at 19:15, Levente Uzonyi <[hidden email]> 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/sqUnixLibreSSL.c

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/IGT2fLJrAeo

>
> Levente
>
> [1] http://forum.world.st/SqueakSSL-SAN-certificates-td4828767.html
>
> On Thu, 27 Apr 2017, [hidden email] 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"
>> !
>


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: WebClient-Core-fn.105.mcz

Tobias Pape
Hi,

> On 27.04.2017, at 20:10, Tobias Pape <[hidden email]> wrote:
>
>
>> On 27.04.2017, at 19:15, Levente Uzonyi <[hidden email]> 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/sqUnixLibreSSL.c

Wow, I wrote this in a confusing way.
What I wanted to say is: the openssl api is convoluted and error prone, so I looked at an alternative, found the (simplified) libtls api from libressl and plan to go forward using that in a new checking-setting.

Best regards
        -Tobias

>
> 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/IGT2fLJrAeo
>>
>> Levente
>>
>> [1] http://forum.world.st/SqueakSSL-SAN-certificates-td4828767.html
>>
>> On Thu, 27 Apr 2017, [hidden email] 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"
>>> !
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: WebClient-Core-fn.105.mcz

Levente Uzonyi
In reply to this post by Tobias Pape
On Thu, 27 Apr 2017, Tobias Pape wrote:

>
>> On 27.04.2017, at 19:15, Levente Uzonyi <[hidden email]> 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/sqUnixLibreSSL.c
>
> 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/IGT2fLJrAeo
>>
>> Levente
>>
>> [1] http://forum.world.st/SqueakSSL-SAN-certificates-td4828767.html
>>
>> On Thu, 27 Apr 2017, [hidden email] 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"
>>> !
>>