Am 13.01.2016 um 13:59 schrieb Sven Van Caekenberghe <sven@stfx.eu>:

On 13 Jan 2016, at 13:33, Norbert Hartl <norbert@hartl.name> wrote:

Sven,

Am 12.01.2016 um 16:25 schrieb Sven Van Caekenberghe <sven@stfx.eu>:

Given a ZdcSecureSocketStream you can access the #sslSession. In this session object you can use #certificateName: to set the path or name of the certificate (before you #connect !). That is the general idea.

Now, I don't know if this works or not. Be prepared to look in the plugin C code! On Linux this will probably work.

I spent some time to figure out how this works. But I don't get it. I don't know what this copying back and forth of bytes in the SSL handshake is supposed to do. I just can see that on a second read from the socket the connection is closed from the remote side. Not much here.
I think it will take too much time for me to figure it out. And I'm afraid I don't have that many spare cycles.

Unless you are reimplementing SSL from the ground up, it is not really super important to understand what is happening. The whole idea of using a library like OpenSSL is to delegate all the hard work to it, in particular the handshake.

The fact that the other end closes most probably means that something is wrong (duh): the client did not behave or act as expected, or it provided some strange/wrong/bogus data.

Yeah, I was able to do a similar analysis of the problem :P It is just very hard to figure out what is the bogus part in there. Using the openssl client I could verify that the certificate in the file is valid. So no glue what went wrong otherwise.

We should rethink "software bounties". I don't have the time to fix this but I'm willing to put some money on the table to have it implemented properly. There are more people wanting to pay for features implemented. And I'm sure there are developers that would like to do it when being paid.

Yeah.

But to complete this task successfully one has to know about Pharo, about C and about SSL/TLS. A C version directly using the OpenSSL API should be compared to what the SSL Plugin does, that is the only way out. And it would not hurt to rewrite the SSL Plugin itself in a very clean cross platform way using only 1 OS API in C (OpenSSL), not 3 like today, with proper logging and error handling.

Yes, it is not easy. But there are a lot of people capable of doing it I guess. Having a decent SSL implementation is absolutely desirable IMHO.