> From: owner-openssl-us...@openssl.org On Behalf Of Frediano Ziglio > Sent: Saturday, 03 November, 2012 10:26
> I'm searching for a way to pass a TLS session between two programs > under Unix. I can use unix sockets to send the file descriptor but I > don't know how to request to OpenSSL crypto information (like > algorithm used and key) in order to pass to the other process. > Do you mean session or connection? Those aren't the same thing in SSL/TLS. A *connection* is an active thing, consisting of a socket TCP connection, over which handshake is done (and optionally re-done) and data sent and received (usually) encrypted and MACed. It is represented in OpenSSL by an SSL object (which is typedef to struct ssl_st), which has lots of pointers to lots of other things to many levels. I see no supported way to serialize or otherwise move an SSL to another program. A *session* is basically the results of a full handshake, specifying ciphersuite, authentication, master-secret and related parameters for a (logical) client and server pair. Multiple connections can reuse the same session. The first connection does full handshake, and the resulting session is remembered somewhere, typically with a time limit such as an hour; subsequent connections using the same (remembered) session do an abbreviated handshake which identifies the session and thereby the master-secret, then skips to session-key derivation and activation with ChangeCipherSpec and Finished. This is called "resumption", which is slightly misleading because it can be used for concurrent connections: you can do full handshake on conn#1, end conn#1, then start conn#2 to "resume" the session; or you can do full conn#1, then start conn#2 to "resume" while conn#1 is still active. There are two ways to do sessions. The classic way is for server to assign an id, and client and server each remember it under that id. For servers handling very large numbers of clients (e.g. google) or subject to denial-of-service attacks (ditto), RFC 4507 added an alternate method where the server securely wraps the session info and returns it as a "ticket" to the client; the client can subsequently create a new connection using that session by providing the ticket, unless the server decides to reject (perhaps because it's too old). OpenSSL implements both. It can cache sessions in SSL_CTX which can be reused/shared by multiple SSL objects (connections) in the same process, although by default it enables cache only for server because the client selection logic requires application assistance. As others have said, it can DERify or PEMify an SSL_SESSION object for external sharing e.g. in a file, a database, or passing over over a pipe or similar. A ticket is already a byte string. Note that connections re-using a session are intended to be the same "parties"; this doesn't necessarily mean the same IPaddresses or the same machines, although those are reasonable approximations. But it should not exceed the authentication done, if any: if a session was created with server auth, it should be shared only with other servers using the same server cert(s), or a ticket should be accepted only by such (since the servers must share a secret key to decrypt the ticket anyway); if it was created with client auth, the client should share only with other clients using same client cert(s). ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
