Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

This is a technical deep dive after this overview question was asked.

What are the protocol differences between SSL and TLS?
Is there really enough of a difference to warrant a name change? (versus calling it "SSLv4" or SSLv5 for the newer versions of TLS)

share|improve this question
I suspect if you want a really in-depth understanding you are going to have to start reading the specs. Check out the wiki page. It includes links to to the RFCs and specs. –  Zoredache Sep 6 '10 at 20:42
@Zoredache, please don't use "wiki" as short for "Wikipedia". –  Spiff Sep 6 '10 at 22:09

5 Answers 5

up vote 20 down vote accepted

SSLv2 and SSLv3 are completely different (and both are now considered insecure). SSLv3 and TLSv1.0 are very similar, but have a few differences.

You could consider TLSv1.0 as SSLv3.1 (in fact that's what happens within the records exchanged). It's just easier to compare the TLSv1.0 with TLSv1.1 and TLSv1.2 because they've all been edited within IETF and follow more or less the same structure. SSLv3 being edited by a different institution (Netscape), it makes it a bit more difficult to spot the differences.

Here are a few differences, but I doubt I can list them all:

  • In the ClientHello message (first message sent by the client, to initiate the handshake), the version is {3,0} for SSLv3, {3,1} for TLSv1.0 and {3,2} for TLSv1.1.
  • The ClientKeyExchange differs.
  • The MAC/HMAC differs (TLS uses HMAC whereas SSL uses an earlier version of HMAC).
  • The key derivation differs.
  • The client application data can be sent straight after sending the SSL/TLS Finished message in SSLv3. In TLSv1, it must wait for the server's Finished message.
  • The list of cipher suites differ (and some of them have been renamed from SSL_* to TLS_*, keeping the same id number).
  • There are also differences regarding the new re-negotiation extension.

I would strongly recommend Eric Rescorla's book - SSL and TLS: Designing and Building Secure Systems, Addison-Wesley, 2001 ISBN 0-201-61598-3, if you really want more details. I've learnt about some of the points mentioned above from this book. The author occasionally mentions the differences between SSLv3 and TLS (v1.0 only at the time the book was written) when explaining some of the SSL/TLS message, but you do need the background explanation about these messages to have a chance to understand (and it's not appropriate to copy/paste from this book here).

share|improve this answer
It looks like the TLS Extensions only apply to TLS and not SSL, correct? So, for example, TLS clients may send an extended 'ClientHello' record, while SSL3-only clients would only ever send the original 'ClientHello'. –  culix Feb 24 at 14:25
@culix, generally speaking, that's indeed correct (mainly because the TLS extensions are defined in the framework of IETF). SSLv3 was also able to have extra data in its ClientHello record (same as TLS 1.0 and 1.1). (Look for draft302.txt and "In the interests of forward compatibility...", compare with sections in the TLS specs). To cope with stacks not supporting this, there's also workarounds such as the SCSV pseudo cipher-suite in the renegotiation extension. –  Bruno Feb 24 at 15:19


  • TLS runs quite on top of a standard protocol. A TLS connection starts like an unencrypted session of a standard service, but at some point they start negotiating encryption. It requires extending the standard protocol for this negotiation.
  • Standard protocols run on top of SSL. A SSL connection first negotiates encryption, then run the basic protocol over it.
share|improve this answer
That's not correct, you're talking of the difference between starting with SSL/TLS and switching to TLS within the protocol via commands like STARTTLS: stackoverflow.com/questions/3660798/… –  Bruno Sep 9 '10 at 11:57

I will just echo the other answers but perhaps with a slightly different emphasis.

There was a secure sockets protocol which was "owned" by Netscape which was called SSL version 2. A new version with a different record structure and security improvements also "owned" by Netscape was released and called SSL version 3. Inside the protocol in several places is a binary version number field. For SSL version 3, this field is set to 0x03 0x00, i.e. version 3.0. Then the IETF decided to create its own standard. Possibly because there were some intellectual property uncertainties about SSL, including whether "SSL" was a Netscape trademark, when the IETF released the next version of this protocol they gave it their own name: Transport Layer Security protocol, or TLS version 1.0. The record format and overall structure is identical and consistent with SSL v3. The binary version number is was revved to 0x03 0x01, and as others have noted there were some minor crypto changes. There has since been TLS version 1.1 and 1.2, for which the internal protocol numbers are 0x03 0x02 and 0x03 0x03.

Ignoring SSLv2, it was basically just a name change along with normal protocol fine-tuning that happens as people get smarter about security and performance.

share|improve this answer

Fundamentally, it is a nothing but a name change for a newer version of the protocol. I believe the main reason for that was to differentiate it from the older, informal standard mainly designed by Netscape after it became an official IETF standards track protocol.

As was said in the answers to your earlier question, this doesn't mean SSLv3 and TLSv1.0 are compatible. Citing from RFC 2246:

the differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough that TLS 1.0 and SSL 3.0 do not interoperate.

I guess if you really want to know the exact differences in the protocols, you must read the standards and compare yourself.

SSLv3 protocol draft from Netscape TLSv1.0 RFC 2246

share|improve this answer
@SvenW I would compare for myself but it is a big challenge I'm not sure I want to undertake. That standard has been around for 10 years now. Surely someone already did the comparison, with pretty graphics so that guys like me can understand it. –  makerofthings7 Sep 7 '10 at 1:11
@MakerOfThings7 Unfortunately this question is not something that can be boiled down to a pie-chart. The only things that could be put on a chart are encryption bit-rates or (and I'm stretching here) the level of security granted (where SSLv3 is "-" and TLS is "="...) The only insight to be gained can be had by actually reading the specs, or at least the Wikipedia page (which I provided to you in the previous question.) –  gWaldo Sep 7 '10 at 2:09
@SvenW Have you read and understood both the specs yourself? –  makerofthings7 Sep 7 '10 at 11:53
No. Why should I? I am not a developer writing software against this specification, which is about the only reason to do that I can think of. If I need to use SSL/TLS, I read the doc for OpenSSL etc., that is sufficient for users and administrators. –  Sven Sep 7 '10 at 12:02
@SvenW No offense, but I'll keep this open until I get a response from someone who read and understood the specs... which is reasonable given my question. –  makerofthings7 Sep 7 '10 at 16:10

The encryption protocol SSL is now named TLS, resulting in two names for the same protocol. Current software will negotiate TLS version 1 or SSL version 3 automatically. Humans, on the other hand, have to decide between using the more recognizable SSL term versus the official TLS designation.

SSL is the predecessor of TLS.

TLS and SSL encrypt the segments of network connections at the Application Layer to ensure secure end-to-end transit at the Transport Layer.

share|improve this answer
So it's a name change? That's it? –  makerofthings7 Sep 6 '10 at 20:25
yes TLS is the newer version, TLS can transform itself into SSL3 if necessary. –  aleroot Sep 6 '10 at 20:35
No it's not quite a name change. TLSv1 is interoperable with SSLv3 (and will fallback) but that's not necessarily true the other way around. TLSv1 is like SSLv4. Note: there's multiple versions of TLS also. –  Philip Reynolds Sep 6 '10 at 20:39

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.