Quantcast

SSL/HTTPS - SecureSocketStream/SSLSession for Pharo/Squeak and other Smalltalk implementations

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

SSL/HTTPS - SecureSocketStream/SSLSession for Pharo/Squeak and other Smalltalk implementations

Sven Van Caekenberghe
SSL/HTTPS - SecureSocketStream/SSLSession for Pharo/Squeak and other Smalltalk implementations


HTTP client and server functionality has become an essential part of any Smalltalk implementation. There exist various open source solutions delivering this functionality.

Users quickly find out that HTTPS is not as readily available as HTTP. Although a solution exists in the form of SqueakSSL, it is not easily portable to Pharo and certainly not to other Smalltalk implementations. Furthermore, SqueakSSL is incomplete and more a working proof of concept than a high quality, high performance, maintainable piece of code, partially because of its dependence on the internals of SocketStream.

Hence, some people wanting HTTPS on Pharo as well as one organisation have come foreword with a bounty to force a solution. Here are the requirements, a plan of action and a number of steps to build such a solution.


First of all, it would be stupid not to start from the work already done for SqueakSSL. Any new solution should start from the existing plugin, from the existing set of primitives and from the current implementation of these primitives for the Windows, Mac OS X and Linux platforms.

The Smalltalk part of the solution should be as platform independent as possible. We therefor need a new, clean implementation of SocketStream, with proper internal buffering and optimised versions of the bulk input and output primitives. The code should be time and space efficient. At first, only binary I/O is needed. Encoding/decoding is best done by wrapping the stream. Maybe a bivalent stream could be an option. The current ASCII support in quite limited.

Next a SecureSocketStream can be implemented using this clean base combined with the SSLSession primitives. Here too, time and space efficiency are important although SSL will by definition be less efficient.

Eventually, HTTP frameworks can then use this SecureSocketStream to actually implement HTTPS. Although the primary requirement is client functionality, server functionality should be provided as well.

Next the existing issues with certificates need to be resolved, on all 3 platforms.

Finally, the C code of the plugin for each of the 3 platforms needs to be cleaned up and improved where necessary. This requires contributions from developers who know and understand a platform as well as how SSL is supposed to work. Furthermore they have to understand and be motivated to work on Smalltalk plugins. Up to 3 different developers might be needed.

The current implementation on Mac OS X does not seem to (directly) use the standard OpenSSL library from Linux although this library exists on Mac OS X. This could be an opportunity to reduce the number of implementations of the plugin to 2 API's.

Needless to say the whole implementation should be open source licensed (MIT), be documented and have a number of units tests to cover it's main functionality as well edge cases encountered in the field.

Friendly cooperation with other open source projects in the Smalltalk world is a plus. This project should benefit the whole community.


The bounty should be split in different parts.

The first part is setting up the new project, delivering the new SocketStream, SSLSession and SecureSocketStream, including the HTTPS client proof of concept. Traction within the community has to be developed.

Next the issues with the plugin have to be identified. Then the work on the plugin code for each platform has to be defined and 3 more bounties could be offered.

The goal should be to include the plugin in VM's by default.

With a proper solution to the plugin issues, SSL server functionality should be no problem.


I offer to take on part one and help manage the coordination of this project.

So is there anyone capable and willing to help out on the plugin on on one or more platforms for part of the bounty ?

Are there others who wish to raise the bounty ?

We will need a couple of good beta testers who understand this field as well.


Sven


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL/HTTPS - SecureSocketStream/SSLSession forPharo/Squeak and other Smalltalk implementations

Rob Withers-2
Try this, after loading the Crypto packages.  I haven't tried it myself,
yet, as I only got on this list and loaded Pharo a few days ago, but I will
probably dig into it over the weekend.  I did load Crypto, though.

http://www.squeaksource.com/Cryptography/SSL-mtf.16.mcz

Is there a Pharo repository I could drop ported code into?

Regards,
Rob





-----Original Message-----
From: Sven Van Caekenberghe
Sent: Tuesday, May 10, 2011 1:42 PM
To: Pharo Project
Subject: [Pharo-project] SSL/HTTPS - SecureSocketStream/SSLSession
forPharo/Squeak and other Smalltalk implementations

SSL/HTTPS - SecureSocketStream/SSLSession for Pharo/Squeak and other
Smalltalk implementations


HTTP client and server functionality has become an essential part of any
Smalltalk implementation. There exist various open source solutions
delivering this functionality.

Users quickly find out that HTTPS is not as readily available as HTTP.
Although a solution exists in the form of SqueakSSL, it is not easily
portable to Pharo and certainly not to other Smalltalk implementations.
Furthermore, SqueakSSL is incomplete and more a working proof of concept
than a high quality, high performance, maintainable piece of code, partially
because of its dependence on the internals of SocketStream.

Hence, some people wanting HTTPS on Pharo as well as one organisation have
come foreword with a bounty to force a solution. Here are the requirements,
a plan of action and a number of steps to build such a solution.


First of all, it would be stupid not to start from the work already done for
SqueakSSL. Any new solution should start from the existing plugin, from the
existing set of primitives and from the current implementation of these
primitives for the Windows, Mac OS X and Linux platforms.

The Smalltalk part of the solution should be as platform independent as
possible. We therefor need a new, clean implementation of SocketStream, with
proper internal buffering and optimised versions of the bulk input and
output primitives. The code should be time and space efficient. At first,
only binary I/O is needed. Encoding/decoding is best done by wrapping the
stream. Maybe a bivalent stream could be an option. The current ASCII
support in quite limited.

Next a SecureSocketStream can be implemented using this clean base combined
with the SSLSession primitives. Here too, time and space efficiency are
important although SSL will by definition be less efficient.

Eventually, HTTP frameworks can then use this SecureSocketStream to actually
implement HTTPS. Although the primary requirement is client functionality,
server functionality should be provided as well.

Next the existing issues with certificates need to be resolved, on all 3
platforms.

Finally, the C code of the plugin for each of the 3 platforms needs to be
cleaned up and improved where necessary. This requires contributions from
developers who know and understand a platform as well as how SSL is supposed
to work. Furthermore they have to understand and be motivated to work on
Smalltalk plugins. Up to 3 different developers might be needed.

The current implementation on Mac OS X does not seem to (directly) use the
standard OpenSSL library from Linux although this library exists on Mac OS
X. This could be an opportunity to reduce the number of implementations of
the plugin to 2 API's.

Needless to say the whole implementation should be open source licensed
(MIT), be documented and have a number of units tests to cover it's main
functionality as well edge cases encountered in the field.

Friendly cooperation with other open source projects in the Smalltalk world
is a plus. This project should benefit the whole community.


The bounty should be split in different parts.

The first part is setting up the new project, delivering the new
SocketStream, SSLSession and SecureSocketStream, including the HTTPS client
proof of concept. Traction within the community has to be developed.

Next the issues with the plugin have to be identified. Then the work on the
plugin code for each platform has to be defined and 3 more bounties could be
offered.

The goal should be to include the plugin in VM's by default.

With a proper solution to the plugin issues, SSL server functionality should
be no problem.


I offer to take on part one and help manage the coordination of this
project.

So is there anyone capable and willing to help out on the plugin on on one
or more platforms for part of the bounty ?

Are there others who wish to raise the bounty ?

We will need a couple of good beta testers who understand this field as
well.


Sven



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL/HTTPS - SecureSocketStream/SSLSession for Pharo/Squeak and other Smalltalk implementations

Guido Chari
In reply to this post by Sven Van Caekenberghe
I port the plugin to VisualSmalltalk and we have it working well (not heavily tested) for half a year.

I could help on this project on the plugin part (for windows and unix only) and on the image side. The problem is that i'm going on vacaction on next weeks so i shall participate only since mid-June. Also i have not too much free time.

Anyway i will be interested on using and testing it.

Guido

2011/5/10 Sven Van Caekenberghe <[hidden email]>
SSL/HTTPS - SecureSocketStream/SSLSession for Pharo/Squeak and other Smalltalk implementations


HTTP client and server functionality has become an essential part of any Smalltalk implementation. There exist various open source solutions delivering this functionality.

Users quickly find out that HTTPS is not as readily available as HTTP. Although a solution exists in the form of SqueakSSL, it is not easily portable to Pharo and certainly not to other Smalltalk implementations. Furthermore, SqueakSSL is incomplete and more a working proof of concept than a high quality, high performance, maintainable piece of code, partially because of its dependence on the internals of SocketStream.

Hence, some people wanting HTTPS on Pharo as well as one organisation have come foreword with a bounty to force a solution. Here are the requirements, a plan of action and a number of steps to build such a solution.


First of all, it would be stupid not to start from the work already done for SqueakSSL. Any new solution should start from the existing plugin, from the existing set of primitives and from the current implementation of these primitives for the Windows, Mac OS X and Linux platforms.

The Smalltalk part of the solution should be as platform independent as possible. We therefor need a new, clean implementation of SocketStream, with proper internal buffering and optimised versions of the bulk input and output primitives. The code should be time and space efficient. At first, only binary I/O is needed. Encoding/decoding is best done by wrapping the stream. Maybe a bivalent stream could be an option. The current ASCII support in quite limited.

Next a SecureSocketStream can be implemented using this clean base combined with the SSLSession primitives. Here too, time and space efficiency are important although SSL will by definition be less efficient.

Eventually, HTTP frameworks can then use this SecureSocketStream to actually implement HTTPS. Although the primary requirement is client functionality, server functionality should be provided as well.

Next the existing issues with certificates need to be resolved, on all 3 platforms.

Finally, the C code of the plugin for each of the 3 platforms needs to be cleaned up and improved where necessary. This requires contributions from developers who know and understand a platform as well as how SSL is supposed to work. Furthermore they have to understand and be motivated to work on Smalltalk plugins. Up to 3 different developers might be needed.

The current implementation on Mac OS X does not seem to (directly) use the standard OpenSSL library from Linux although this library exists on Mac OS X. This could be an opportunity to reduce the number of implementations of the plugin to 2 API's.

Needless to say the whole implementation should be open source licensed (MIT), be documented and have a number of units tests to cover it's main functionality as well edge cases encountered in the field.

Friendly cooperation with other open source projects in the Smalltalk world is a plus. This project should benefit the whole community.


The bounty should be split in different parts.

The first part is setting up the new project, delivering the new SocketStream, SSLSession and SecureSocketStream, including the HTTPS client proof of concept. Traction within the community has to be developed.

Next the issues with the plugin have to be identified. Then the work on the plugin code for each platform has to be defined and 3 more bounties could be offered.

The goal should be to include the plugin in VM's by default.

With a proper solution to the plugin issues, SSL server functionality should be no problem.


I offer to take on part one and help manage the coordination of this project.

So is there anyone capable and willing to help out on the plugin on on one or more platforms for part of the bounty ?

Are there others who wish to raise the bounty ?

We will need a couple of good beta testers who understand this field as well.


Sven



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL/HTTPS - SecureSocketStream/SSLSession for Pharo/Squeak and other Smalltalk implementations

Sven Van Caekenberghe

On 12 May 2011, at 15:59, Guido Chari wrote:

> I port the plugin to VisualSmalltalk and we have it working well (not heavily tested) for half a year.
>
> I could help on this project on the plugin part (for windows and unix only) and on the image side. The problem is that i'm going on vacaction on next weeks so i shall participate only since mid-June. Also i have not too much free time.
>
> Anyway i will be interested on using and testing it.
>
> Guido

That is great, Guido!

Don't worry, it will take some time, no rush.

What OS platforms did you work on ? All 3 ?

Sven


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL/HTTPS - SecureSocketStream/SSLSession forPharo/Squeak and other Smalltalk implementations

Stéphane Ducasse
In reply to this post by Rob Withers-2
you can in pharoTaskForces
or you can create a PharoSSL

Stef


> Try this, after loading the Crypto packages.  I haven't tried it myself, yet, as I only got on this list and loaded Pharo a few days ago, but I will probably dig into it over the weekend.  I did load Crypto, though.
>
> http://www.squeaksource.com/Cryptography/SSL-mtf.16.mcz
>
> Is there a Pharo repository I could drop ported code into?
>
> Regards,
> Rob
>
>
>
>
>
> -----Original Message----- From: Sven Van Caekenberghe
> Sent: Tuesday, May 10, 2011 1:42 PM
> To: Pharo Project
> Subject: [Pharo-project] SSL/HTTPS - SecureSocketStream/SSLSession forPharo/Squeak and other Smalltalk implementations
>
> SSL/HTTPS - SecureSocketStream/SSLSession for Pharo/Squeak and other Smalltalk implementations
>
>
> HTTP client and server functionality has become an essential part of any Smalltalk implementation. There exist various open source solutions delivering this functionality.
>
> Users quickly find out that HTTPS is not as readily available as HTTP. Although a solution exists in the form of SqueakSSL, it is not easily portable to Pharo and certainly not to other Smalltalk implementations. Furthermore, SqueakSSL is incomplete and more a working proof of concept than a high quality, high performance, maintainable piece of code, partially because of its dependence on the internals of SocketStream.
>
> Hence, some people wanting HTTPS on Pharo as well as one organisation have come foreword with a bounty to force a solution. Here are the requirements, a plan of action and a number of steps to build such a solution.
>
>
> First of all, it would be stupid not to start from the work already done for SqueakSSL. Any new solution should start from the existing plugin, from the existing set of primitives and from the current implementation of these primitives for the Windows, Mac OS X and Linux platforms.
>
> The Smalltalk part of the solution should be as platform independent as possible. We therefor need a new, clean implementation of SocketStream, with proper internal buffering and optimised versions of the bulk input and output primitives. The code should be time and space efficient. At first, only binary I/O is needed. Encoding/decoding is best done by wrapping the stream. Maybe a bivalent stream could be an option. The current ASCII support in quite limited.
>
> Next a SecureSocketStream can be implemented using this clean base combined with the SSLSession primitives. Here too, time and space efficiency are important although SSL will by definition be less efficient.
>
> Eventually, HTTP frameworks can then use this SecureSocketStream to actually implement HTTPS. Although the primary requirement is client functionality, server functionality should be provided as well.
>
> Next the existing issues with certificates need to be resolved, on all 3 platforms.
>
> Finally, the C code of the plugin for each of the 3 platforms needs to be cleaned up and improved where necessary. This requires contributions from developers who know and understand a platform as well as how SSL is supposed to work. Furthermore they have to understand and be motivated to work on Smalltalk plugins. Up to 3 different developers might be needed.
>
> The current implementation on Mac OS X does not seem to (directly) use the standard OpenSSL library from Linux although this library exists on Mac OS X. This could be an opportunity to reduce the number of implementations of the plugin to 2 API's.
>
> Needless to say the whole implementation should be open source licensed (MIT), be documented and have a number of units tests to cover it's main functionality as well edge cases encountered in the field.
>
> Friendly cooperation with other open source projects in the Smalltalk world is a plus. This project should benefit the whole community.
>
>
> The bounty should be split in different parts.
>
> The first part is setting up the new project, delivering the new SocketStream, SSLSession and SecureSocketStream, including the HTTPS client proof of concept. Traction within the community has to be developed.
>
> Next the issues with the plugin have to be identified. Then the work on the plugin code for each platform has to be defined and 3 more bounties could be offered.
>
> The goal should be to include the plugin in VM's by default.
>
> With a proper solution to the plugin issues, SSL server functionality should be no problem.
>
>
> I offer to take on part one and help manage the coordination of this project.
>
> So is there anyone capable and willing to help out on the plugin on on one or more platforms for part of the bounty ?
>
> Are there others who wish to raise the bounty ?
>
> We will need a couple of good beta testers who understand this field as well.
>
>
> Sven
>
>
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL/HTTPS - SecureSocketStream/SSLSession forPharo/Squeak and other Smalltalk implementations

Stéphane Ducasse
In reply to this post by Rob Withers-2
Or you keep
        Cryptology and publish a pharo tag.

Stef

On May 12, 2011, at 3:52 PM, Rob Withers wrote:

> Try this, after loading the Crypto packages.  I haven't tried it myself, yet, as I only got on this list and loaded Pharo a few days ago, but I will probably dig into it over the weekend.  I did load Crypto, though.
>
> http://www.squeaksource.com/Cryptography/SSL-mtf.16.mcz
>
> Is there a Pharo repository I could drop ported code into?
>
> Regards,
> Rob
>
>
>
>
>
> -----Original Message----- From: Sven Van Caekenberghe
> Sent: Tuesday, May 10, 2011 1:42 PM
> To: Pharo Project
> Subject: [Pharo-project] SSL/HTTPS - SecureSocketStream/SSLSession forPharo/Squeak and other Smalltalk implementations
>
> SSL/HTTPS - SecureSocketStream/SSLSession for Pharo/Squeak and other Smalltalk implementations
>
>
> HTTP client and server functionality has become an essential part of any Smalltalk implementation. There exist various open source solutions delivering this functionality.
>
> Users quickly find out that HTTPS is not as readily available as HTTP. Although a solution exists in the form of SqueakSSL, it is not easily portable to Pharo and certainly not to other Smalltalk implementations. Furthermore, SqueakSSL is incomplete and more a working proof of concept than a high quality, high performance, maintainable piece of code, partially because of its dependence on the internals of SocketStream.
>
> Hence, some people wanting HTTPS on Pharo as well as one organisation have come foreword with a bounty to force a solution. Here are the requirements, a plan of action and a number of steps to build such a solution.
>
>
> First of all, it would be stupid not to start from the work already done for SqueakSSL. Any new solution should start from the existing plugin, from the existing set of primitives and from the current implementation of these primitives for the Windows, Mac OS X and Linux platforms.
>
> The Smalltalk part of the solution should be as platform independent as possible. We therefor need a new, clean implementation of SocketStream, with proper internal buffering and optimised versions of the bulk input and output primitives. The code should be time and space efficient. At first, only binary I/O is needed. Encoding/decoding is best done by wrapping the stream. Maybe a bivalent stream could be an option. The current ASCII support in quite limited.
>
> Next a SecureSocketStream can be implemented using this clean base combined with the SSLSession primitives. Here too, time and space efficiency are important although SSL will by definition be less efficient.
>
> Eventually, HTTP frameworks can then use this SecureSocketStream to actually implement HTTPS. Although the primary requirement is client functionality, server functionality should be provided as well.
>
> Next the existing issues with certificates need to be resolved, on all 3 platforms.
>
> Finally, the C code of the plugin for each of the 3 platforms needs to be cleaned up and improved where necessary. This requires contributions from developers who know and understand a platform as well as how SSL is supposed to work. Furthermore they have to understand and be motivated to work on Smalltalk plugins. Up to 3 different developers might be needed.
>
> The current implementation on Mac OS X does not seem to (directly) use the standard OpenSSL library from Linux although this library exists on Mac OS X. This could be an opportunity to reduce the number of implementations of the plugin to 2 API's.
>
> Needless to say the whole implementation should be open source licensed (MIT), be documented and have a number of units tests to cover it's main functionality as well edge cases encountered in the field.
>
> Friendly cooperation with other open source projects in the Smalltalk world is a plus. This project should benefit the whole community.
>
>
> The bounty should be split in different parts.
>
> The first part is setting up the new project, delivering the new SocketStream, SSLSession and SecureSocketStream, including the HTTPS client proof of concept. Traction within the community has to be developed.
>
> Next the issues with the plugin have to be identified. Then the work on the plugin code for each platform has to be defined and 3 more bounties could be offered.
>
> The goal should be to include the plugin in VM's by default.
>
> With a proper solution to the plugin issues, SSL server functionality should be no problem.
>
>
> I offer to take on part one and help manage the coordination of this project.
>
> So is there anyone capable and willing to help out on the plugin on on one or more platforms for part of the bounty ?
>
> Are there others who wish to raise the bounty ?
>
> We will need a couple of good beta testers who understand this field as well.
>
>
> Sven
>
>
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL/HTTPS - SecureSocketStream/SSLSession for Pharo/Squeak and other Smalltalk implementations

Guido Chari
In reply to this post by Sven Van Caekenberghe
VisualSmalltalk runs only on Windows.

My port of SqueakSSL is to windows.

But i have expierence on Unix too.

Never worked on Mac.

2011/5/12 Sven Van Caekenberghe <[hidden email]>

On 12 May 2011, at 15:59, Guido Chari wrote:

> I port the plugin to VisualSmalltalk and we have it working well (not heavily tested) for half a year.
>
> I could help on this project on the plugin part (for windows and unix only) and on the image side. The problem is that i'm going on vacaction on next weeks so i shall participate only since mid-June. Also i have not too much free time.
>
> Anyway i will be interested on using and testing it.
>
> Guido

That is great, Guido!

Don't worry, it will take some time, no rush.

What OS platforms did you work on ? All 3 ?

Sven



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL/HTTPS - SecureSocketStream/SSLSession forPharo/Squeak and other Smalltalk implementations

Sven Van Caekenberghe
In reply to this post by Rob Withers-2
Hi Rob,

On 12 May 2011, at 15:52, Rob Withers wrote:

> Try this, after loading the Crypto packages.  I haven't tried it myself, yet, as I only got on this list and loaded Pharo a few days ago, but I will probably dig into it over the weekend.  I did load Crypto, though.
>
> http://www.squeaksource.com/Cryptography/SSL-mtf.16.mcz
>
> Is there a Pharo repository I could drop ported code into?

This looks like a quite impressive code base. I think I once heard about this, but never really looked at it.

If I understand this correctly, browsing in SqueakSource, this is actually an SSL implementation, 100% done in Smalltalk ?

Some questions then:

- in what state is the code, does it work ?

- how compatible is it wrt SSL standards ?

- how fast is it, is it useable ?

- why was it not used for SqueakSSL ?

Sven
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL/HTTPS - SecureSocketStream/SSLSessionforPharo/Squeak and other Smalltalk implementations

Rob Withers-2
In reply to this post by Stéphane Ducasse
Stef,

The Cryptography project, which has Cryptography, CryptographyPlugins,
LayeredProtocol and SSL packages are all tagged with pharo.   When I look at
the pharo tag, none of these show up.  Do they need to be releases?

How can I use the pharo tag from inside of Pharo, with the Monticello
Browser?

Rob

-----Original Message-----
From: Stéphane Ducasse
Sent: Thursday, May 12, 2011 10:10 AM
To: [hidden email]
Subject: Re: [Pharo-project] SSL/HTTPS -
SecureSocketStream/SSLSessionforPharo/Squeak and other Smalltalk
implementations

Or you keep
Cryptology and publish a pharo tag.

Stef

On May 12, 2011, at 3:52 PM, Rob Withers wrote:

> Try this, after loading the Crypto packages.  I haven't tried it myself,
> yet, as I only got on this list and loaded Pharo a few days ago, but I
> will probably dig into it over the weekend.  I did load Crypto, though.
>
> http://www.squeaksource.com/Cryptography/SSL-mtf.16.mcz
>
> Is there a Pharo repository I could drop ported code into?
>
> Regards,
> Rob
>
>
>
>
>
> -----Original Message----- From: Sven Van Caekenberghe
> Sent: Tuesday, May 10, 2011 1:42 PM
> To: Pharo Project
> Subject: [Pharo-project] SSL/HTTPS - SecureSocketStream/SSLSession
> forPharo/Squeak and other Smalltalk implementations
>
> SSL/HTTPS - SecureSocketStream/SSLSession for Pharo/Squeak and other
> Smalltalk implementations
>
>
> HTTP client and server functionality has become an essential part of any
> Smalltalk implementation. There exist various open source solutions
> delivering this functionality.
>
> Users quickly find out that HTTPS is not as readily available as HTTP.
> Although a solution exists in the form of SqueakSSL, it is not easily
> portable to Pharo and certainly not to other Smalltalk implementations.
> Furthermore, SqueakSSL is incomplete and more a working proof of concept
> than a high quality, high performance, maintainable piece of code,
> partially because of its dependence on the internals of SocketStream.
>
> Hence, some people wanting HTTPS on Pharo as well as one organisation have
> come foreword with a bounty to force a solution. Here are the
> requirements, a plan of action and a number of steps to build such a
> solution.
>
>
> First of all, it would be stupid not to start from the work already done
> for SqueakSSL. Any new solution should start from the existing plugin,
> from the existing set of primitives and from the current implementation of
> these primitives for the Windows, Mac OS X and Linux platforms.
>
> The Smalltalk part of the solution should be as platform independent as
> possible. We therefor need a new, clean implementation of SocketStream,
> with proper internal buffering and optimised versions of the bulk input
> and output primitives. The code should be time and space efficient. At
> first, only binary I/O is needed. Encoding/decoding is best done by
> wrapping the stream. Maybe a bivalent stream could be an option. The
> current ASCII support in quite limited.
>
> Next a SecureSocketStream can be implemented using this clean base
> combined with the SSLSession primitives. Here too, time and space
> efficiency are important although SSL will by definition be less
> efficient.
>
> Eventually, HTTP frameworks can then use this SecureSocketStream to
> actually implement HTTPS. Although the primary requirement is client
> functionality, server functionality should be provided as well.
>
> Next the existing issues with certificates need to be resolved, on all 3
> platforms.
>
> Finally, the C code of the plugin for each of the 3 platforms needs to be
> cleaned up and improved where necessary. This requires contributions from
> developers who know and understand a platform as well as how SSL is
> supposed to work. Furthermore they have to understand and be motivated to
> work on Smalltalk plugins. Up to 3 different developers might be needed.
>
> The current implementation on Mac OS X does not seem to (directly) use the
> standard OpenSSL library from Linux although this library exists on Mac OS
> X. This could be an opportunity to reduce the number of implementations of
> the plugin to 2 API's.
>
> Needless to say the whole implementation should be open source licensed
> (MIT), be documented and have a number of units tests to cover it's main
> functionality as well edge cases encountered in the field.
>
> Friendly cooperation with other open source projects in the Smalltalk
> world is a plus. This project should benefit the whole community.
>
>
> The bounty should be split in different parts.
>
> The first part is setting up the new project, delivering the new
> SocketStream, SSLSession and SecureSocketStream, including the HTTPS
> client proof of concept. Traction within the community has to be
> developed.
>
> Next the issues with the plugin have to be identified. Then the work on
> the plugin code for each platform has to be defined and 3 more bounties
> could be offered.
>
> The goal should be to include the plugin in VM's by default.
>
> With a proper solution to the plugin issues, SSL server functionality
> should be no problem.
>
>
> I offer to take on part one and help manage the coordination of this
> project.
>
> So is there anyone capable and willing to help out on the plugin on on one
> or more platforms for part of the bounty ?
>
> Are there others who wish to raise the bounty ?
>
> We will need a couple of good beta testers who understand this field as
> well.
>
>
> Sven
>
>
>



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL/HTTPS - SecureSocketStream/SSLSessionforPharo/Squeak and other Smalltalk implementations

Rob Withers-2
In reply to this post by Sven Van Caekenberghe
Hi Sven,

It is a complete implementation with the bare minimum of supported
algorithms, based on the spec.   It is 100% in Smalltalk.  It worked last
time I tested in, several years ago.  I will be able to tell you more this
weekend.   Others have been adding fixes/small features since, but not a
lot - the base is pretty solid.  I painstakingly followed the RFC for SSL -
I think I read it over 20 times!  The only issue would be algorithm support.
I never benchmarked it, but seeing the difference in performance between
Smlltalk crypto code like 3DES and plugin code, there is a SIGNIFICANT
improvement (10x?).   I do not know the state of Profiling under Pharo.  If
someone could help set me up, then I will profile it this weekend.  I
imagine both performance and certification were the reasons for SqueakSSL.

There is also an SSH implementation I wrote that does dynamic window
resizing on net latency.

Rob

-----Original Message-----
From: Sven Van Caekenberghe
Sent: Thursday, May 12, 2011 10:16 AM
To: [hidden email]
Subject: Re: [Pharo-project] SSL/HTTPS -
SecureSocketStream/SSLSessionforPharo/Squeak and other Smalltalk
implementations

Hi Rob,

On 12 May 2011, at 15:52, Rob Withers wrote:

> Try this, after loading the Crypto packages.  I haven't tried it myself,
> yet, as I only got on this list and loaded Pharo a few days ago, but I
> will probably dig into it over the weekend.  I did load Crypto, though.
>
> http://www.squeaksource.com/Cryptography/SSL-mtf.16.mcz
>
> Is there a Pharo repository I could drop ported code into?

This looks like a quite impressive code base. I think I once heard about
this, but never really looked at it.

If I understand this correctly, browsing in SqueakSource, this is actually
an SSL implementation, 100% done in Smalltalk ?

Some questions then:

- in what state is the code, does it work ?

- how compatible is it wrt SSL standards ?

- how fast is it, is it useable ?

- why was it not used for SqueakSSL ?

Sven


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL/HTTPS - SecureSocketStream/SSLSessionforPharo/Squeak and other Smalltalk implementations

Sven Van Caekenberghe
Rob,

On 12 May 2011, at 16:38, Rob Withers wrote:

> It is a complete implementation with the bare minimum of supported algorithms, based on the spec.   It is 100% in Smalltalk.  It worked last time I tested in, several years ago.  I will be able to tell you more this weekend.   Others have been adding fixes/small features since, but not a lot - the base is pretty solid.  I painstakingly followed the RFC for SSL - I think I read it over 20 times!  The only issue would be algorithm support. I never benchmarked it, but seeing the difference in performance between Smlltalk crypto code like 3DES and plugin code, there is a SIGNIFICANT improvement (10x?).   I do not know the state of Profiling under Pharo.  If someone could help set me up, then I will profile it this weekend.  I imagine both performance and certification were the reasons for SqueakSSL.
>
> There is also an SSH implementation I wrote that does dynamic window resizing on net latency.

It would be *very cool* if that code base could be ported to Pharo.
It is really quite impressive that you did all this from the spec.

I think that it would be possible to adjust my plan a bit, so that eventually, my code would use either the native plugin or your Smalltalk implementation. Then, we can compare features, functionality, bugs, etc..

Does that sound like a good idea ?

Sven


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL/HTTPS - SecureSocketStream/SSLSession for Pharo/Squeak and other Smalltalk implementations

Jan van de Sandt
In reply to this post by Sven Van Caekenberghe
Hello,

I can help test the client part of a HTTPS implementation. Currently I use Zinc-HTTP together with stunnel.

Note that VA Smalltalk uses OpenSSL on Linux and Windows. So it is possible to use OpenSSL on windows as well [1].

Jan.

[1] http://www.openssl.org/related/binaries.html

On Tue, May 10, 2011 at 7:42 PM, Sven Van Caekenberghe <[hidden email]> wrote:
SSL/HTTPS - SecureSocketStream/SSLSession for Pharo/Squeak and other Smalltalk implementations


HTTP client and server functionality has become an essential part of any Smalltalk implementation. There exist various open source solutions delivering this functionality.

Users quickly find out that HTTPS is not as readily available as HTTP. Although a solution exists in the form of SqueakSSL, it is not easily portable to Pharo and certainly not to other Smalltalk implementations. Furthermore, SqueakSSL is incomplete and more a working proof of concept than a high quality, high performance, maintainable piece of code, partially because of its dependence on the internals of SocketStream.

Hence, some people wanting HTTPS on Pharo as well as one organisation have come foreword with a bounty to force a solution. Here are the requirements, a plan of action and a number of steps to build such a solution.


First of all, it would be stupid not to start from the work already done for SqueakSSL. Any new solution should start from the existing plugin, from the existing set of primitives and from the current implementation of these primitives for the Windows, Mac OS X and Linux platforms.

The Smalltalk part of the solution should be as platform independent as possible. We therefor need a new, clean implementation of SocketStream, with proper internal buffering and optimised versions of the bulk input and output primitives. The code should be time and space efficient. At first, only binary I/O is needed. Encoding/decoding is best done by wrapping the stream. Maybe a bivalent stream could be an option. The current ASCII support in quite limited.

Next a SecureSocketStream can be implemented using this clean base combined with the SSLSession primitives. Here too, time and space efficiency are important although SSL will by definition be less efficient.

Eventually, HTTP frameworks can then use this SecureSocketStream to actually implement HTTPS. Although the primary requirement is client functionality, server functionality should be provided as well.

Next the existing issues with certificates need to be resolved, on all 3 platforms.

Finally, the C code of the plugin for each of the 3 platforms needs to be cleaned up and improved where necessary. This requires contributions from developers who know and understand a platform as well as how SSL is supposed to work. Furthermore they have to understand and be motivated to work on Smalltalk plugins. Up to 3 different developers might be needed.

The current implementation on Mac OS X does not seem to (directly) use the standard OpenSSL library from Linux although this library exists on Mac OS X. This could be an opportunity to reduce the number of implementations of the plugin to 2 API's.

Needless to say the whole implementation should be open source licensed (MIT), be documented and have a number of units tests to cover it's main functionality as well edge cases encountered in the field.

Friendly cooperation with other open source projects in the Smalltalk world is a plus. This project should benefit the whole community.


The bounty should be split in different parts.

The first part is setting up the new project, delivering the new SocketStream, SSLSession and SecureSocketStream, including the HTTPS client proof of concept. Traction within the community has to be developed.

Next the issues with the plugin have to be identified. Then the work on the plugin code for each platform has to be defined and 3 more bounties could be offered.

The goal should be to include the plugin in VM's by default.

With a proper solution to the plugin issues, SSL server functionality should be no problem.


I offer to take on part one and help manage the coordination of this project.

So is there anyone capable and willing to help out on the plugin on on one or more platforms for part of the bounty ?

Are there others who wish to raise the bounty ?

We will need a couple of good beta testers who understand this field as well.


Sven



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL/HTTPS - SecureSocketStream/SSLSession for Pharo/Squeak and other Smalltalk implementations

Sven Van Caekenberghe
Hi Jan,

On 12 May 2011, at 17:07, Jan van de Sandt wrote:

> Hello,
>
> I can help test the client part of a HTTPS implementation. Currently I use Zinc-HTTP together with stunnel.
>
> Note that VA Smalltalk uses OpenSSL on Linux and Windows. So it is possible to use OpenSSL on windows as well [1].
>
> Jan.
>
> [1] http://www.openssl.org/related/binaries.html

That is interesting.
Is the VAST plugin open source ?

And of course, thanks for the offer, I knew you would be interested !

Sven


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL/HTTPS -SecureSocketStream/SSLSessionforPharo/Squeak and otherSmalltalk implementations

Rob Withers-2
In reply to this post by Sven Van Caekenberghe
Sure.  I cannot recall if I offered a stream interface or not.  I could add
one and we could treat this and the SqueakSSL stream as provider impl to a
wrapper stream.

I'll comment more as I dig into it.  I think I will fork a PharoSSL project,
since I know of at least one change in there.

Rob

-----Original Message-----
From: Sven Van Caekenberghe
Sent: Thursday, May 12, 2011 10:53 AM
To: [hidden email]
Subject: Re: [Pharo-project]
SSL/HTTPS -SecureSocketStream/SSLSessionforPharo/Squeak and otherSmalltalk
implementations

Rob,

On 12 May 2011, at 16:38, Rob Withers wrote:

> It is a complete implementation with the bare minimum of supported
> algorithms, based on the spec.   It is 100% in Smalltalk.  It worked last
> time I tested in, several years ago.  I will be able to tell you more this
> weekend.   Others have been adding fixes/small features since, but not a
> lot - the base is pretty solid.  I painstakingly followed the RFC for
> SSL - I think I read it over 20 times!  The only issue would be algorithm
> support. I never benchmarked it, but seeing the difference in performance
> between Smlltalk crypto code like 3DES and plugin code, there is a
> SIGNIFICANT improvement (10x?).   I do not know the state of Profiling
> under Pharo.  If someone could help set me up, then I will profile it this
> weekend.  I imagine both performance and certification were the reasons
> for SqueakSSL.
>
> There is also an SSH implementation I wrote that does dynamic window
> resizing on net latency.

It would be *very cool* if that code base could be ported to Pharo.
It is really quite impressive that you did all this from the spec.

I think that it would be possible to adjust my plan a bit, so that
eventually, my code would use either the native plugin or your Smalltalk
implementation. Then, we can compare features, functionality, bugs, etc..

Does that sound like a good idea ?

Sven



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL/HTTPS - SecureSocketStream/SSLSessionforPharo/Squeak and other Smalltalk implementations

Miguel Cobá
In reply to this post by Sven Van Caekenberghe
El jue, 12-05-2011 a las 16:53 +0200, Sven Van Caekenberghe escribió:

> Rob,
>
> On 12 May 2011, at 16:38, Rob Withers wrote:
>
> > It is a complete implementation with the bare minimum of supported algorithms, based on the spec.   It is 100% in Smalltalk.  It worked last time I tested in, several years ago.  I will be able to tell you more this weekend.   Others have been adding fixes/small features since, but not a lot - the base is pretty solid.  I painstakingly followed the RFC for SSL - I think I read it over 20 times!  The only issue would be algorithm support. I never benchmarked it, but seeing the difference in performance between Smlltalk crypto code like 3DES and plugin code, there is a SIGNIFICANT improvement (10x?).   I do not know the state of Profiling under Pharo.  If someone could help set me up, then I will profile it this weekend.  I imagine both performance and certification were the reasons for SqueakSSL.
> >
> > There is also an SSH implementation I wrote that does dynamic window resizing on net latency.
>
> It would be *very cool* if that code base could be ported to Pharo.
> It is really quite impressive that you did all this from the spec.
>
> I think that it would be possible to adjust my plan a bit, so that eventually, my code would use either the native plugin or your Smalltalk implementation. Then, we can compare features, functionality, bugs, etc..
>
> Does that sound like a good idea ?

But the performance is an issue. And I think that there was a discussion
several years ago that lead to choice a plugin instead of the
all-smalltalk code (independently of the queality of the smalltalk
code). Also a point was made about the maintainability of the smalltalk
code with respect to a library of the underlying OS, with respect to
CERT issues and 0-day exploits. given the few resources in the community
for simpler (relative to crypto) projects like *completion, RB and so, I
think is a wise decision to use the proved, tested and maintained OS
libraries through a plugin part of the standard VM. Of course, the
smalltalk implementation can be used as a fallback for platforms where a
plugin isn't available.

Cheers
>
> Sven
>
>

--
Miguel Cobá
http://twitter.com/MiguelCobaMtz
http://miguel.leugim.com.mx




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL/HTTPS -SecureSocketStream/SSLSessionforPharo/Squeak and otherSmalltalk implementations

Sven Van Caekenberghe
In reply to this post by Rob Withers-2

On 12 May 2011, at 17:58, Rob Withers wrote:

> Sure.  I cannot recall if I offered a stream interface or not.  
> I could add one and we could treat this and the SqueakSSL stream as provider impl to a wrapper stream.

The code that I am working on has a good [Secure]SocketStream implementation, it depends on a Socket like object, and on an SSLSession, which currently is the plugin. I imagine that it could also be your code.

> I'll comment more as I dig into it.  I think I will fork a PharoSSL project, since I know of at least one change in there.

If I understood correctly, you need all of Cryptography, right ?
So would it not make more sense to (if necessary), start or add a Cryptography-Pharo ?
I mean, your code is much more than SSL.

Sven


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL/HTTPS - SecureSocketStream/SSLSessionforPharo/Squeak and other Smalltalk implementations

Stéphane Ducasse
In reply to this post by Rob Withers-2

On May 12, 2011, at 4:31 PM, Rob Withers wrote:

> Stef,
>
> The Cryptography project, which has Cryptography, CryptographyPlugins, LayeredProtocol and SSL packages are all tagged with pharo.   When I look at the pharo tag, none of these show up.  Do they need to be releases?

By tag I do not know :)


> How can I use the pharo tag from inside of Pharo, with the Monticello Browser?
>
> Rob
>
> -----Original Message----- From: Stéphane Ducasse
> Sent: Thursday, May 12, 2011 10:10 AM
> To: [hidden email]
> Subject: Re: [Pharo-project] SSL/HTTPS - SecureSocketStream/SSLSessionforPharo/Squeak and other Smalltalk implementations
>
> Or you keep
> Cryptology and publish a pharo tag.
>
> Stef
>
> On May 12, 2011, at 3:52 PM, Rob Withers wrote:
>
>> Try this, after loading the Crypto packages.  I haven't tried it myself, yet, as I only got on this list and loaded Pharo a few days ago, but I will probably dig into it over the weekend.  I did load Crypto, though.
>>
>> http://www.squeaksource.com/Cryptography/SSL-mtf.16.mcz
>>
>> Is there a Pharo repository I could drop ported code into?
>>
>> Regards,
>> Rob
>>
>>
>>
>>
>>
>> -----Original Message----- From: Sven Van Caekenberghe
>> Sent: Tuesday, May 10, 2011 1:42 PM
>> To: Pharo Project
>> Subject: [Pharo-project] SSL/HTTPS - SecureSocketStream/SSLSession forPharo/Squeak and other Smalltalk implementations
>>
>> SSL/HTTPS - SecureSocketStream/SSLSession for Pharo/Squeak and other Smalltalk implementations
>>
>>
>> HTTP client and server functionality has become an essential part of any Smalltalk implementation. There exist various open source solutions delivering this functionality.
>>
>> Users quickly find out that HTTPS is not as readily available as HTTP. Although a solution exists in the form of SqueakSSL, it is not easily portable to Pharo and certainly not to other Smalltalk implementations. Furthermore, SqueakSSL is incomplete and more a working proof of concept than a high quality, high performance, maintainable piece of code, partially because of its dependence on the internals of SocketStream.
>>
>> Hence, some people wanting HTTPS on Pharo as well as one organisation have come foreword with a bounty to force a solution. Here are the requirements, a plan of action and a number of steps to build such a solution.
>>
>>
>> First of all, it would be stupid not to start from the work already done for SqueakSSL. Any new solution should start from the existing plugin, from the existing set of primitives and from the current implementation of these primitives for the Windows, Mac OS X and Linux platforms.
>>
>> The Smalltalk part of the solution should be as platform independent as possible. We therefor need a new, clean implementation of SocketStream, with proper internal buffering and optimised versions of the bulk input and output primitives. The code should be time and space efficient. At first, only binary I/O is needed. Encoding/decoding is best done by wrapping the stream. Maybe a bivalent stream could be an option. The current ASCII support in quite limited.
>>
>> Next a SecureSocketStream can be implemented using this clean base combined with the SSLSession primitives. Here too, time and space efficiency are important although SSL will by definition be less efficient.
>>
>> Eventually, HTTP frameworks can then use this SecureSocketStream to actually implement HTTPS. Although the primary requirement is client functionality, server functionality should be provided as well.
>>
>> Next the existing issues with certificates need to be resolved, on all 3 platforms.
>>
>> Finally, the C code of the plugin for each of the 3 platforms needs to be cleaned up and improved where necessary. This requires contributions from developers who know and understand a platform as well as how SSL is supposed to work. Furthermore they have to understand and be motivated to work on Smalltalk plugins. Up to 3 different developers might be needed.
>>
>> The current implementation on Mac OS X does not seem to (directly) use the standard OpenSSL library from Linux although this library exists on Mac OS X. This could be an opportunity to reduce the number of implementations of the plugin to 2 API's.
>>
>> Needless to say the whole implementation should be open source licensed (MIT), be documented and have a number of units tests to cover it's main functionality as well edge cases encountered in the field.
>>
>> Friendly cooperation with other open source projects in the Smalltalk world is a plus. This project should benefit the whole community.
>>
>>
>> The bounty should be split in different parts.
>>
>> The first part is setting up the new project, delivering the new SocketStream, SSLSession and SecureSocketStream, including the HTTPS client proof of concept. Traction within the community has to be developed.
>>
>> Next the issues with the plugin have to be identified. Then the work on the plugin code for each platform has to be defined and 3 more bounties could be offered.
>>
>> The goal should be to include the plugin in VM's by default.
>>
>> With a proper solution to the plugin issues, SSL server functionality should be no problem.
>>
>>
>> I offer to take on part one and help manage the coordination of this project.
>>
>> So is there anyone capable and willing to help out on the plugin on on one or more platforms for part of the bounty ?
>>
>> Are there others who wish to raise the bounty ?
>>
>> We will need a couple of good beta testers who understand this field as well.
>>
>>
>> Sven
>>
>>
>>
>
>
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL/HTTPS - SecureSocketStream/SSLSession for Pharo/Squeak and other Smalltalk implementations

Jan van de Sandt
In reply to this post by Sven Van Caekenberghe
Hi,

No the VASt plugin is not open source. It is not really a plugin. It is just Smalltalk code that calls the OpenSSL lib using external functions (the FFI of VASt). The OpenSSL library delivered with VASt is a very old version and there are some concurrency issues on windows. So I do think that Instantiations is interested in an upgrade. If technically possible than perhaps some kind of cooperation is possible.

Two years ago I created an open source alternative for VASt users on windows WinHttpClient & WinCrypt. This is of no use for Zinc because it depends on windows http stack :-(

Jan.





On Thu, May 12, 2011 at 5:21 PM, Sven Van Caekenberghe <[hidden email]> wrote:
Hi Jan,

On 12 May 2011, at 17:07, Jan van de Sandt wrote:

> Hello,
>
> I can help test the client part of a HTTPS implementation. Currently I use Zinc-HTTP together with stunnel.
>
> Note that VA Smalltalk uses OpenSSL on Linux and Windows. So it is possible to use OpenSSL on windows as well [1].
>
> Jan.
>
> [1] http://www.openssl.org/related/binaries.html

That is interesting.
Is the VAST plugin open source ?

And of course, thanks for the offer, I knew you would be interested !

Sven



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL/HTTPS - SecureSocketStream/SSLSessionforPharo/Squeak and other Smalltalk implementations

mkobetic
In reply to this post by Rob Withers-2
"Miguel Cobá"<[hidden email]> wrote:

> But the performance is an issue. And I think that there was a discussion
> several years ago that lead to choice a plugin instead of the
> all-smalltalk code (independently of the queality of the smalltalk
> code). Also a point was made about the maintainability of the smalltalk
> code with respect to a library of the underlying OS, with respect to
> CERT issues and 0-day exploits. given the few resources in the community
> for simpler (relative to crypto) projects like *completion, RB and so, I
> think is a wise decision to use the proved, tested and maintained OS
> libraries through a plugin part of the standard VM. Of course, the
> smalltalk implementation can be used as a fallback for platforms where a
> plugin isn't available.

These are certainly important things to consider, but I think the arguments need to be more specific and thought through. There are probably dozens of tried and proven libraries for pretty much anything out there, so does that mean there's no point implementing anything? Moreover an external interface is not maintenance free either, they can be surprisingly brittle in many ways and libraries tend to have their own quirks that you may need to accommodate. Anyway, I'd like to focus on the SSL performance argument here.

The primary bottleneck of an all-smalltalk SSL implementation are the hashes and symmetric ciphers, which have to chew on every byte of data going through a connection and are too slow in Smalltalk (orders of magnitude slower). The public key algorithms would be the second bottleneck but those are not nearly as bad (more like 5 - 10 times slower depending on the size of the key, and that's primarily because of lack of efficient Integer>>raisedTo:modulo: primitive that peforms well for large integers). Moreover the public key operations happen when a connection is being established, they are not involved in actual data transfer, so long lasting heavily used connections will offset their cost quite easily. To sum up the pub-key ops are no concern on the client, they will likely be a concern on a server (unless it doesn't need to handle many concurrent connections in rapid sequence). So with all that said, I'm confident that a Smalltalk implementation of SSL/TLS can perform as well as any other as long as the hashes and ciphers are farmed out (http://www.cincomsmalltalk.com/userblogs/cst/blogView?printTitle=Xtreams-SSH2).

Of course that doesn't automatically mean that is should be implemented in Smalltalk. Given that you currently have both available in Squeak (native, Cryptography, and external, SqueakSSL) see how they stack up to each other. How easy are they to configure and use, where do they work and where they don't, do they provide the same features. I'd be curious how the external implementation deals with the issue of verification of the server certificate (I don't mean checking that it's valid, the library can presumably do that for you, but how does the application check that the certificate identifies the entity that it wants to reach?). What about session management (caching, resumption control, load-balancing etc)?

Anyway, lots of things to consider indeed. One thing that wrapping an external library usually doesn't give you is thorough understanding of the mechanics and capabilities of the protocol, which is double-plus important with security. You won't get a secure connection if you don't configure/use the protocol correctly. And you have to configure it to some degree, there isn't an appropriate one-size fits all default. Arguably you shouldn't need to actually implement one to get that understanding, but it sure does help a lot :-).

My 2c,

Martin


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL/HTTPS - SecureSocketStream/SSLSessionforPharo/Squeak and other Smalltalk implementations

Nicolas Cellier
2011/5/14  <[hidden email]>:

> "Miguel Cobá"<[hidden email]> wrote:
>> But the performance is an issue. And I think that there was a discussion
>> several years ago that lead to choice a plugin instead of the
>> all-smalltalk code (independently of the queality of the smalltalk
>> code). Also a point was made about the maintainability of the smalltalk
>> code with respect to a library of the underlying OS, with respect to
>> CERT issues and 0-day exploits. given the few resources in the community
>> for simpler (relative to crypto) projects like *completion, RB and so, I
>> think is a wise decision to use the proved, tested and maintained OS
>> libraries through a plugin part of the standard VM. Of course, the
>> smalltalk implementation can be used as a fallback for platforms where a
>> plugin isn't available.
>
> These are certainly important things to consider, but I think the arguments need to be more specific and thought through. There are probably dozens of tried and proven libraries for pretty much anything out there, so does that mean there's no point implementing anything? Moreover an external interface is not maintenance free either, they can be surprisingly brittle in many ways and libraries tend to have their own quirks that you may need to accommodate. Anyway, I'd like to focus on the SSL performance argument here.
>
> The primary bottleneck of an all-smalltalk SSL implementation are the hashes and symmetric ciphers, which have to chew on every byte of data going through a connection and are too slow in Smalltalk (orders of magnitude slower). The public key algorithms would be the second bottleneck but those are not nearly as bad (more like 5 - 10 times slower depending on the size of the key, and that's primarily because of lack of efficient Integer>>raisedTo:modulo: primitive that peforms well for large integers). Moreover the public key operations happen when a connection is being established, they are not involved in actual data transfer, so long lasting heavily used connections will offset their cost quite easily. To sum up the pub-key ops are no concern on the client, they will likely be a concern on a server (unless it doesn't need to handle many concurrent connections in rapid sequence). So with all that said, I'm confident that a Smalltalk implementation of SSL/TLS can perform as well as any other as long as the hashes and ciphers are farmed out (http://www.cincomsmalltalk.com/userblogs/cst/blogView?printTitle=Xtreams-SSH2).
>

I accelerated raisedTo:modulo: a bit with a primitive
(http://bugs.squeak.org/view.php?id=7120) but that's not enough

Nicolas

> Of course that doesn't automatically mean that is should be implemented in Smalltalk. Given that you currently have both available in Squeak (native, Cryptography, and external, SqueakSSL) see how they stack up to each other. How easy are they to configure and use, where do they work and where they don't, do they provide the same features. I'd be curious how the external implementation deals with the issue of verification of the server certificate (I don't mean checking that it's valid, the library can presumably do that for you, but how does the application check that the certificate identifies the entity that it wants to reach?). What about session management (caching, resumption control, load-balancing etc)?
>
> Anyway, lots of things to consider indeed. One thing that wrapping an external library usually doesn't give you is thorough understanding of the mechanics and capabilities of the protocol, which is double-plus important with security. You won't get a secure connection if you don't configure/use the protocol correctly. And you have to configure it to some degree, there isn't an appropriate one-size fits all default. Arguably you shouldn't need to actually implement one to get that understanding, but it sure does help a lot :-).
>
> My 2c,
>
> Martin
>
>
>

12
Loading...