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
Sounds great! Is it possible to access to whole certificate data as well?
Norbert
Am 26.05.2015 um 23:55 schrieb Levente Uzonyi leves@elte.hu:
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
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 leves@elte.hu:
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
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 leves@elte.hu:
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 leves@elte.hu:
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
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 leves@elte.hu:
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 leves@elte.hu:
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
Am 27.05.2015 um 19:22 schrieb Levente Uzonyi leves@elte.hu:
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.
I've written an ASN.1 parser [1]. I have also a draft version for X.509 module. I can read DER/BER formats which I do already in the GSM stack stuff we did [2]. The ASN.1 implementation has only a runtime model (no generated classes). I usually export the runtime model with Fuel if I don't want to generate it. It wouldn't be a very performant approach but maybe it will be usable in some way. I'd give it a shot.
Norbert
[1] http://smalltalkhub.com/#!/~NorbertHartl/ASN1 http://smalltalkhub.com/#!/~NorbertHartl/ASN1 [2] http://smalltalkhub.com/#!/~osmocom http://smalltalkhub.com/#!/~osmocom
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 leves@elte.hu:
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 leves@elte.hu:
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 27.05.2015, at 19:58, Norbert Hartl norbert@hartl.name wrote:
Am 27.05.2015 um 19:22 schrieb Levente Uzonyi leves@elte.hu:
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.
I've written an ASN.1 parser [1]. I have also a draft version for X.509 module. I can read DER/BER formats which I do already in the GSM stack stuff we did [2]. The ASN.1 implementation has only a runtime model (no generated classes). I usually export the runtime model with Fuel if I don't want to generate it. It wouldn't be a very performant approach but maybe it will be usable in some way. I'd give it a shot.
Well, it probably is a good idea to hand certs up to the image, i suppose :) Try to give that a shot?
best regards -Tobias
Norbert
[1] http://smalltalkhub.com/#!/~NorbertHartl/ASN1 [2] http://smalltalkhub.com/#!/~osmocom
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 leves@elte.hu:
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 27.05.2015 um 20:56 schrieb Tobias Pape Das.Linux@gmx.de:
On 27.05.2015, at 19:58, Norbert Hartl <norbert@hartl.name mailto:norbert@hartl.name> wrote:
Am 27.05.2015 um 19:22 schrieb Levente Uzonyi leves@elte.hu:
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.
I've written an ASN.1 parser [1]. I have also a draft version for X.509 module. I can read DER/BER formats which I do already in the GSM stack stuff we did [2]. The ASN.1 implementation has only a runtime model (no generated classes). I usually export the runtime model with Fuel if I don't want to generate it. It wouldn't be a very performant approach but maybe it will be usable in some way. I'd give it a shot.
Well, it probably is a good idea to hand certs up to the image, i suppose :) Try to give that a shot?
Sure! If it comes in DER/BER format it shouldn't be to hard to adapt my code to expose the complete certificate structure. I've done it once already shown at ESUG …. 2013 I guess. I implemented even an old ASN.1 type (any) for that.
Norbert
best regards -Tobias
Norbert
[1] http://smalltalkhub.com/#!/~NorbertHartl/ASN1 [2] http://smalltalkhub.com/#!/~osmocom
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 leves@elte.hu:
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
I've written an ASN.1 parser [1]. I have also a draft version for X.509
module. I can read DER/BER formats which I do already in the GSM stack stuff we did [2]. The ASN.1 implementation has only a runtime model (no generated classes). I usually export the runtime model with Fuel if I don't want to generate it. It wouldn't be a very performant approach but maybe it will be usable in some way. I'd give it a shot.
There is also a nice ASN.1 parser in Cyrptography but it's class based. It's a nice model though. We used it for our implementation of TLS before squeakSSL.
All the best,
Ron Teitelbaum
From: vm-dev-bounces@lists.squeakfoundation.org [mailto:vm-dev-bounces@lists.squeakfoundation.org] On Behalf Of Norbert Hartl Sent: Wednesday, May 27, 2015 3:00 PM To: Squeak Virtual Machine Development Discussion Subject: Re: [Vm-dev] SqueakSSL + SAN certificates
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
Hi Levente,
On 26.05.2015, at 23:55, Levente Uzonyi leves@elte.hu 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
What about a pull-request to the gitHub repo[1]?
Best regards -Tobias
Hi Tobias,
On Wed, 27 May 2015, Tobias Pape wrote:
Hi Levente,
On 26.05.2015, at 23:55, Levente Uzonyi leves@elte.hu 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
What about a pull-request to the gitHub repo[1]?
Done. I saw that the code there is different from the code in the svn repository. Why is that? One important difference is that it has a memory leak, which is not present in the svn repo. It's also fixed in the pull-request.
Levente
Best regards -Tobias
On 27.05.2015, at 19:25, Levente Uzonyi leves@elte.hu wrote:
Hi Tobias,
On Wed, 27 May 2015, Tobias Pape wrote:
Hi Levente,
On 26.05.2015, at 23:55, Levente Uzonyi leves@elte.hu 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
What about a pull-request to the gitHub repo[1]?
Done. I saw that the code there is different from the code in the svn repository. Why is that? One important difference is that it has a memory leak, which is not present in the svn repo. It's also fixed in the pull-request.
Thanks. Comments in the PR :D
Best regards -Tobias
Levente
Best regards -Tobias
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
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
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
vm-dev@lists.squeakfoundation.org