SqueakSSL + SAN certificates
Locked
SqueakSSL + SAN certificates
 
|
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 |
Re: [Vm-dev] SqueakSSL + SAN certificates
|
|
If it were possible, then there would be no need to add this.
Levente On Wed, 27 May 2015, Norbert Hartl wrote: > > Sounds great! Is it possible to access to whole certificate data as well? > > Norbert > >> Am 26.05.2015 um 23:55 schrieb Levente Uzonyi <[hidden email]>: >> >> 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 > > |
Re: SqueakSSL + SAN certificates
|
|
In reply to this post by Levente Uzonyi-2
I fixed a bug in the C code and reuploded it, along with a precompiled
version of the plugin: http://leves.web.elte.hu/squeak/SqueakSSL/SqueakSSL It's built on Ubuntu 14.04 with GCC 4.8.2. Levente On Tue, 26 May 2015, 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 > > |
Re: [Vm-dev] SqueakSSL + SAN certificates
|
|
In reply to this post by Levente Uzonyi-2
I thought you wanted to access the parsed data, which is not easily
accessible. It's possible to export the certificate in some form (PEM or DER), but then you'd have to write a parser for that in Smalltalk. Levente On Wed, 27 May 2015, Norbert Hartl wrote: > > I don't understand. You are returning a field of the cert so you are parsing it somehow natively. Where is the difficulty just to return to whole binary certificate data? > > Norbert > > >> Am 27.05.2015 um 03:23 schrieb Levente Uzonyi <[hidden email]>: >> >> If it were possible, then there would be no need to add this. >> >> Levente >> >> On Wed, 27 May 2015, Norbert Hartl wrote: >> >>> >>> Sounds great! Is it possible to access to whole certificate data as well? >>> >>> Norbert >>> >>>> Am 26.05.2015 um 23:55 schrieb Levente Uzonyi <[hidden email]>: >>>> >>>> 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 >>> >>> > > |
Re: SqueakSSL + SAN certificates
|
|
In reply to this post by Levente Uzonyi-2
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. 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 |
|
|
On 28.05.2015, at 01:58, David T. Lewis <[hidden email]> 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. 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 |
Re: SqueakSSL + SAN certificates
|
|
On Thu, 28 May 2015, Tobias Pape wrote:
> > On 28.05.2015, at 01:58, David T. Lewis <[hidden email]> 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? 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 > > > > |
|
|
On 28.05.2015, at 16:34, Levente Uzonyi <[hidden email]> wrote: > On Thu, 28 May 2015, Tobias Pape wrote: > >> >> On 28.05.2015, at 01:58, David T. Lewis <[hidden email]> 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. 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 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. That way we also don't need to pass a specially formatted string to the image. I find that odd, a bit. 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. 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 |
Re: SqueakSSL + SAN certificates
|
|
On Thu, 28 May 2015, Tobias Pape wrote:
> > On 28.05.2015, at 16:34, Levente Uzonyi <[hidden email]> wrote: > >> On Thu, 28 May 2015, Tobias Pape wrote: >> >>> >>> On 28.05.2015, at 01:58, David T. Lewis <[hidden email]> 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. 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 > > > > |
Re: SqueakSSL + SAN certificates
|
|
In reply to this post by Levente Uzonyi-2
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 |
Re: [Vm-dev] Re: [squeak-dev] SqueakSSL + SAN certificates
|
|
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. 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 > |
Re: [Vm-dev] [squeak-dev] SqueakSSL + SAN certificates
|
|
Hi again
(hi sven) On 02.06.2015, at 05:56, Levente Uzonyi <[hidden email]> 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 |
Re: [Vm-dev] [squeak-dev] SqueakSSL + SAN certificates
|
|
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). So a), b) and c) are all image-side changes. 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. Levente On Thu, 20 Aug 2015, Tobias Pape wrote: > Hi again > (hi sven) > > On 02.06.2015, at 05:56, Levente Uzonyi <[hidden email]> 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 > > > > |
Re: [Vm-dev] [squeak-dev] SqueakSSL + SAN certificates
|
|
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 <[hidden email]> 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 <[hidden email]> 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 |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |