> From: owner-openssl-users On Behalf Of Matthias Apitz > Sent: Friday, November 15, 2013 14:43
> El día Friday, November 15, 2013 a las 12:58:40PM -0500, Watson, Patrick > escribió: > > > Traditionally, there are 2 methods that immediately come to mind. One > way is to have the SSL version of the server listen on a different port than the > plain text version. Alternatively, your protocol could include a "STARTTLS" like > command that indicates that the system wants to communicate securely. > (See http://en.wikipedia.org/wiki/STARTTLS) > The (extremely) prominent example being HTTP on 80 vs HTTPS on 443. FTP, SMTP, NNTP are examples of the starttls approach. > I was thinking more in a solution where the client reads the first 8 > bytes from the socket and checks if the beginning of the GoodMorning > message is there in clear text (like "220 SLNP") and if not > it should handover this buffer and the socket fd for further SSL > handshake... Is this possible? > Note that the server cannot actually start SSL/TLS; the client does so, normally on its own initiative but possibly in response to a clear request. Once in SSL/TLS data phase the server can issue HelloRequest to request the client *re*negotiate, but 5246 explicitly says it SHOULD NOT do this for initial negotiation; previous versions were silent, hinting this might have been clarified because someone got it wrong. I'm not sure if openssl code can send it initially; certainly normal 'accept' logic doesn't (it waits for ClientHello before it does anything). You could code the server application to just issue HelloRequest itself, which is short and simple (and fixed), which the client could recognize, discard, and then start SSL/TLS on the socket. Or if your app protocol is at all extensible, which your example suggests, you could use that: maybe "192 please start ssl" intead of "220 ready". (OpenSSL library, both client and server, can be given a socket that is already open and already has been used for clear communication, but it should not have any clear data buffered and it must not have any of the proper SSL handshake 'used up'; that's how starttls-type methods work among other things. If the server could actually send needed handshake data, you would need to either use a BIO-pair to redirect OpenSSL's I/O through code you write that re-uses the used data before new data, or create a modified socket-BIO which does the same thing.) ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
