In various docs on SSL there is a mention of connection.
But from the context I am not sure if this means the underlying TCP connection or the SSL connection.
I am thinking that there is no SSL connection (formally defined) in the SSL protocol and only an SSL session.
Therefore if I read for example:

For each SSL session, multiple connections can be setup. Each connection uses the same session parameters but different key


An SSL session can outlive the connection which produced it

The connection is the TCP connection right?
Formally speaking is there ever a SSL Connection?

  • I was under the impression that the whole point of SSL sessions was to avoid having to negotiate a new key.
    – symcbean
    Apr 23, 2012 at 12:20

2 Answers 2


When SSL is set up, it undergoes a handshake. This handshake allows the two clients to securely decide the details of the conversation and exchange key material. Once the handshake is complete, both sides can communicate securely. This entire conversation is simply an exchange of messages, so SSL is not technically limited to any transport protocol. You could run SSL over UDP if you really wanted, though standard libs probably don't support it and I wouldn't suggest trying it.

To answer your question fully - there's no such thing as a message in the SSL protocol to say "this SSL session is ending". The session is tied to whatever logic is provided by your transport layer and application layer, and it's up to the SSL implementation to deallocate resources when the conversation has "ended".

One thing your application might do is create an SSL wrapper around a TCP connection, send a few messages, send a "I'm done" message, tear down the SSL wrapper, then go back to the first step without closing the TCP connection. This way you could run multiple SSL "sessions" in serial using a single connection. I'm not sure what the use-case is, and I'd just make a new connection, but there's no technical limitation to stop you.

  • Just to clarify, the reason I don't suggest running SSL over UDP is that UDP doesn't provide strong ordering, protection against packet injection, or protection against IP spoofing.
    – Polynomial
    Apr 22, 2012 at 11:16

The actual connection will be TCP with SSL dictating the security aspect of it and the application layer serving the actual data. The same connection can be used to initiate a new SSL 'connection' using the previous session or new. Session are used or reused to dictate if it is a complete handshake(expensive calls) or abbreviated handshake.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .