2012/11/6 Dave Thompson <dthomp...@prinpay.com>: >> 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. >
Yes, it's a connection, not a session in this case that I want to "move". So as you say there is no currently a way to move a connection from a process to another. Thanks > 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 ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
