[squeak-dev] SqueakSSL + SAN certificates

Levente Uzonyi leves at elte.hu
Fri May 29 18:38:33 UTC 2015


On Thu, 28 May 2015, Tobias Pape wrote:

>
> On 28.05.2015, at 16:34, Levente Uzonyi <leves at elte.hu> wrote:
>
>> On Thu, 28 May 2015, Tobias Pape wrote:
>>
>>>
>>> On 28.05.2015, at 01:58, David T. Lewis <lewis at mail.msen.com> wrote:
>>>
>>>> Is there any reason *not* to move SqueakSSL-Core-ul.30 from inbox to
>>>> trunk? I know that we are finalizing a release, and also that there
>>>> has been some follow up discussion about parsing certificates in the
>>>> image, but SqueakSSL-Core-ul.30 seems like a harmless and beneficial
>>>> update. So unless there are objections, I would vote to move it to
>>>> trunk now.
>>>>
>>>
>>> Yes, the code does not handle non-SAN-aware plugin-versions.
>>
>> "The image side code is in the Inbox[2]. It is backwards compatible -- everything works as before without the VM changes."
>>
>> Did you experience any problems with backwards compatibility?
>
> Actually I only read the code. Sorry.
> I just saw that subjectAltNameDNS will hand through the primitiveFailed
> if used on a plugin that does not have SQSSL_PROP_SUBJECTALTNAMEDNS.
>  Verifcation is not fully done yet on OSX anyway…
>
>
> And the more I read the C code and the Smalltalk code, I'd really like to
> not change the Smalltalk side.

If you want the plugin to verify that the certificate matches the name of 
the server, then the Smalltalk code will have to be changed too.

>
> Here's why:
> The point of both SNI and sAN are that you want that the server name you
> called to is validated. One is on the protocol level one is on the ceritificate

SNI allows one to name the server, and this allows the plugin to verify 
that the certificate matches the server name.

> level. Both Windows Schannel and OS X Secure Transport abstract that away.
> And I think it is easily possible to do that with openssl as well by
> just traversing all sANs and setting the same validity information as with
> SNI.

OpenSSL (prior v1.1.0) doesn't support the verification of the server name 
out of the box[1].
On Win32 it's turned off with the ISC_REQ_MANUAL_CRED_VALIDATION flag.
The same applies to the OSX version:
 	/* Disable cert verification since we do that ourselves */
 	status = SSLSetEnableCertVerify(ssl->ctx, false);

This means that no variants of the plugin verify the server name, it's 
only done in Smalltalk.
On Win32 and OSX it can be implemented easily. It's possible to do it with 
OpenSSL too, but it's a bit more complicated.

>  That way we also don't need to pass a specially formatted string to
> the image. I find that odd, a bit.

It may be odd, but this is an essential part of the verification 
process[2].

>
> On a different note, providing Certificate information to the image is probably
> still a good idea but I don't think we should do sAN that way.

How much information would you like to pass to the image? Just the 
server's certificate, or the whole certificate chain?
What about the overhead of the certificate serialization? Would you just 
ignore it, or make the certificate extraction optional?

Levente

[1] https://wiki.openssl.org/index.php/SSL/TLS_Client#Certificate_Names
[2] https://wiki.openssl.org/index.php/SSL/TLS_Client#Verification

>
> Thoughts?
>
> Best regards
> 	-Tobias
>
>
>
>>
>> Levente
>>
>>> We have no code for OSX/Windows yet and no VM ships with
>>> a compatible plugin whatsoever. I'd like to postpone this one until
>>> we have
>>> a) covered all 3 platforms and
>>> b) have at least one binary somewhere.
>>>
>>> Best regards
>>> 	-Tobias
>>>
>>>> Dave
>>>>
>>>>
>>>> On Tue, May 26, 2015 at 11:55:42PM +0200, Levente Uzonyi wrote:
>>>>> Hi All,
>>>>>
>>>>> I've implemented support for reading the domain names from the
>>>>> certificate's SAN extension[1] in SqueakSSL.
>>>>> The image side code is in the Inbox[2]. It is backwards compatible --
>>>>> everything works as before without the VM changes.
>>>>> I've also uploaded the modified files[3][4] for the unix platform, and a
>>>>> diff[5] (which somehow doesn't include the changes of the .h file).
>>>>>
>>>>> The VM support code for other platforms are to be done.
>>>>>
>>>>> These changes fix the failing SqueakSSL test in the Trunk, so I suggest
>>>>> including the .mcz file in the 4.6 release.
>>>>>
>>>>> Levente
>>>>>
>>>>> [1] https://en.wikipedia.org/wiki/SubjectAltName
>>>>> [2]
>>>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2015-May/184581.html
>>>>> [3] http://leves.web.elte.hu/squeak/SqueakSSL/SqueakSSL.h
>>>>> [4] http://leves.web.elte.hu/squeak/SqueakSSL/sqUnixOpenSSL.c
>>>>> [5] http://leves.web.elte.hu/squeak/SqueakSSL/diff.txt
>
>
>
>


More information about the Squeak-dev mailing list