> Am 13.01.2016 um 13:59 schrieb Sven Van Caekenberghe <s...@stfx.eu>: > >> >> On 13 Jan 2016, at 13:33, Norbert Hartl <norb...@hartl.name> wrote: >> >> Sven, >> >>> Am 12.01.2016 um 16:25 schrieb Sven Van Caekenberghe <s...@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. Norbert >> Norbert >> >>> >>> And please let us know how it goes ;-) >>> >>>> On 12 Jan 2016, at 16:05, Norbert Hartl <norb...@hartl.name >>>> <mailto:norb...@hartl.name>> wrote: >>>> >>>> Is there a way to make SSL connections to the outside world using client >>>> certificates from pharo? >>>> >>>> thanks, >>>> >>>> Norbert
