40

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)

makerofthings7
  • 8,821
  • 28
  • 115
  • 196
  • 3
    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](http://en.wikipedia.org/wiki/Transport_Layer_Security). It includes links to to the RFCs and specs. – Zoredache Sep 06 '10 at 20:42
  • 7
    @Zoredache, please don't use "wiki" as short for "Wikipedia". – Spiff Sep 06 '10 at 22:09

5 Answers5

36

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).

Bruno
  • 4,069
  • 1
  • 20
  • 37
  • It looks like the [TLS Extensions](https://tools.ietf.org/html/rfc6066) 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 '14 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 7.4.1.2 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 '14 at 15:19
  • @Bruno, Book link down..... – Pacerier Nov 02 '16 at 17:00
4

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.

3

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

Sven
  • 97,248
  • 13
  • 177
  • 225
  • @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 07 '10 at 01: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 07 '10 at 02:09
  • @SvenW Have you read and understood both the specs yourself? – makerofthings7 Sep 07 '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 07 '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 07 '10 at 16:10
  • None taken, but I would suggest taking this question to stackoverflow.com or somewhere where SSL developers hang around, as I doubt many system administrators dived so deep into this matter. – Sven Sep 07 '10 at 16:32
0

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.

aleroot
  • 3,160
  • 5
  • 28
  • 37
-2

Differences:

  • 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.
LatinSuD
  • 841
  • 1
  • 8
  • 15
  • 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: http://stackoverflow.com/questions/3660798/what-happens-on-the-wire-when-a-tls-ldap-or-tls-http-connection-is-set-up/3661416#3661416 – Bruno Sep 09 '10 at 11:57