[Vm-dev] [squeak-dev] SqueakSSL + SAN certificates

Tobias Pape Das.Linux at gmx.de
Wed Aug 26 12:05:29 UTC 2015


Hi all

(psa: I'm on vacation and will only answer irregularly or not at all)


On 21.08.2015, at 18:10, Levente Uzonyi <leves at elte.hu> wrote:

> Hi Tobias,
> 
> That sounds like a good plan. To sum it up, the only difference to the current version is that the plugin will verify server names as well (this is something OpenSSL doesn't support out of box, but it has all the tools necessary to do).

No, the plugin will verify everything; server name, certificate validity, cert chain validity, etc. etc.

> So a), b) and c) are all image-side changes.

The way I intended this is to make a, b, and c all plugin- and image-side changes.

Currently, validation is disabled manually:
- Windows: https://github.com/itsmeront/squeakssl/blob/fb6262a66ee9b6a17b5cd95fb228658499747f81/src/Win32/sqWin32SSL.c#L179
- OS X: https://github.com/itsmeront/squeakssl/blob/fb6262a66ee9b6a17b5cd95fb228658499747f81/src/Mac%20OS/sqMacSSL.c#L154
or just not present:
- Well, OpenSSL: https://github.com/itsmeront/squeakssl/blob/96618367c18b5d0faea7869036c3255a0a8bcad8/src/unix/sqUnixOpenSSL.c#L47

Windows and OS X naturally can do the whole and the kitchen sink in validation
for us. And that's a good thing™. Really. So, for OpenSSL. It's really complex,
actually. So the OpenBSD people (who — IMHO — know what they are doing) provide
a new API atop LibreSSL (ie, OpenSSL for that matter), that makes thinks less 
error prone:

	http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/tls_accept_fds.3?query=tls_init&sec=3

Essentially:

tls_init
tls_client (or  tls_server, for that matter)
tls_connect_fds (or tls_accept_fds)
tls_read/tls_write
tls_close_fds
tls_free

As wit Schannel (win) and SecureTransport (OSX), it is possible to disable checking upfront:

tls_config_insecure_noverifycert
tls_config_insecure_noverifyname

(note the names)

So the scheme “Always verify except when explicitly asked not to” would work
for all platforms.



> I'm not sure if we need c) at all, because we can simply signal a resumable error when the certificate chain fails to be verified by the plugin, and let you, the user, handle that error when necessary.

That's what I want to avoid.
If the user did not say upfront they want not verification, there will be no way forward
if verification fails (from plugin perspective). A user-level error handler could then retry
with verification disabled (after asking the user, of course)

Best regards
	-Tobias (back to vacation ;))

> 
> Levente
> 
> On Thu, 20 Aug 2015, Tobias Pape wrote:
> 
>> Hi again
>> (hi sven)
>> 
>> On 02.06.2015, at 05:56, Levente Uzonyi <leves at elte.hu> wrote:
>> 
>>> Hi David,
>>> 
>>> There's a debate about how SAN certificates - and server name verification in general - should be handled[1][2].
>>> I tend to agree with Tobias on verifying the server name in the plugin, but getting there will require further efforts - especially on the unix platform.
>>> 
>>> While this version solves a particular case, and is backwards compatible on the image side, I think we should look for a better, more general solution.
>> 
>> I have sketched an Idea how to handle verification in SqueakSSL in general (and briefly presented to Bert),
>> I'm not yet sure, however, and I'm on vacation the next two weeks. But after
>> that I'd like to spark a discussion (hoepfully including Sven, for Zodiac) that will involve:
>> 
>> a) no manual verification. Period.
>> b) fail on non-verification.
>> c) optional 'unverified' mode that has to be requested explicitly
>> d) Moving the Unix platform code to libtls (easier to understand)
>> 
>> That's my 2ct for now, more in September.
>> 
>> Best regards
>> 	-Tobias
>> 
>> 
>> 
>>> 
>>> Levente
>>> 
>>> [1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2015-May/184613.html
>>> [2] http://lists.squeakfoundation.org/pipermail/squeak-dev/2015-May/184631.html
>>> 
>>> On Mon, 1 Jun 2015, David T. Lewis wrote:
>>> 
>>>> 
>>>> Hi Levente,
>>>> 
>>>> Regarding your VM changes for SqueakSSL, shall I commit these to the SVN
>>>> trunk repository? Ian delegated access to platforms/unix so that I can do
>>>> that for you if you like.
>>>> 
>>>> We have several Mantis entries to track your SqueakSSL work:
>>>> 
>>>> http://bugs.squeak.org/view.php?id=7751 (Add SSL plugin)
>>>> http://bugs.squeak.org/view.php?id=7793 (Memory leak in the SqueakSSL plugin on unix)
>>>> http://bugs.squeak.org/view.php?id=7824 (Add TLS SNI Server Name Indication support to SqueakSSL plugin)
>>>> 
>>>> Your latest version http://leves.web.elte.hu/squeak/SqueakSSL/ adds
>>>> the SAN certificates support, so I think we should commit your latest
>>>> version and close the Mantis issues.
>>>> 
>>>> If you agree I will update the SVN files.
>>>> 
>>>> Thanks,
>>>> Dave
>>>> 
>>>> p.s. There are still issues in SqueakSSL when sizeof(sqInt) is 8
>>>> (64 bit images) but that is a separate discussion.
>>>> 
>>>> 
>>>> 
>>>> 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