On 11/15/10 17:05, Olivier Mascia wrote:

> Le 15 nov. 2010 à 14:07, Alex Peshkoff a écrit :
>
>>> Ok, that's trash and dirty uncompilable code as is, but very close to be. Client code is similar though much shorter. It goes with a SSL_connect call after the socket connect() call, obviously.
>> Oliver, do we need .pem or some other file at client site? Or may be we
>> need to access trusted authority center using internet?
> It all depends on what you want to do. If you want the server to expose a certificate which was obtained / purchased from a well-known certification authority and want the client to check that the certificate presented by the server is indeed signed by one of these certification authorities, then you have to let the client site check the certificate chain up to the root and validate it trusts the root. For that it obviously need a list of root certificates that it trusts. This is what web browsers do. Some do rely on some trusted list of root certificates exposed by the OS itself, that is the case with IE on Windows for instance. What about linux?

This is browser-related issue. From somewhere browsers know list of
trusted authorities, and if can't check certificate with one of them,
asks question - what to do later? With a lot of warnings about security
problems.

> Now let's consider real cases. Who will buy a certificate from a known authority for his Firebird server? I won't.

I won't too - because I do not need one. But suppose some people can do
it. And here we once again come to the question of supporting different
behavior depending upon users' needs.

> If the client sites know the server to which they should connect they could have a very short list of well-known roots: the self-signed server certificate itself and nothing else.
>
> If the client site doesn't care checking the identity of the server it connects to, then no certificate stuff is needed at the client site, but man in the middle attacks are of course possible. Once the session is engaged and *if* the server you're talking to is the right one, all is well and you can talk privately over that encrypted channel.

If we continue comparing with use of HTTPS in browsers - well, I will
never enter my credit card's pin2 to the site who's certificate can't be
correctly checked by browser :-)