What is TLS and how does it compare to SSL?

Is TLS the "new" version of SSL? What features does it add, or security issues does it address?

Can anything that supports SSL support TLS? What would be involved in making the switch? Is the switch worth it?

Why is it that emails are sent over "Opportunistic TLS" and VPN's often called SSL VPN? Is there a difference in the technology, perhaps creating room for a "TLS VPN" product line ?

From serverfault MakerOfThings7

• From post "SSL vs. TLS" on computing.net:

  "SSL has been around for about a decade from its inception at Netscape. TLS is based on SSL 3.0, mainly so the IETF could have an open, community supported standard which could then be expanded with other Internet standards.

  Basically, there isn't a world of difference between SSL and TLS. You will often see them supported in the same applications (SSL/TLS). They do not interoperate (one has to be picked at negotiation), but TLS can transform itself into SSL3 if necessary. As far I as I know, not much has been going on with TLS as a standard (it works well, just like SSL3). It was upgraded to comply with HTTP 1.1 and supports all the popular ciphers.

  In server related projects, especially open source ones, TLS is basically superceding SSL. For clients, SSL3 is pretty much a standard (usually TLS is default, but it routinely downgrades to SSL3). You can support both TLS and SSL, so there is no conflict there.

  You can make your own SSL certificate for encrypted communication with a program called openssl. Your server (of any type) will have documentation on supporting SSL/TLS.

  A certificate only means so much, because it doesn't actually verify you are the indentity you claim you be. You could claim to be BusinessXYZ and actually be a scam artist. For third party verification, you have to use a service from a company like Verisign (not sure if they bought out all their competitors or not). Verisign is what is known as a Certificate Authority (CA), because they act as a third party to identify you as in fact you. Users coming to your site engaging in SSL/TLS communication will be notified by a prompt if your site cannot be identified by a CA. If you go with a CA, they can help you with all the details."

  jscott : Might be nice to link to the source which you copied that from?

  Rajat : sorry i have google about the same bcoz i was looking the same answer

  jscott : @Rajat: I find nothing wrong with using Google. I just think you do a lot of copying/pasting without any attribution, here, and on your blog. FWIW, I did *not* give you -1. But, again, it would be nice if you updated your answer to link to the source.

  Rajat : Jscott it like that here i run small training for open source and the rural there we really dont have internet for all the time we get for almost 30 min a day like that so what i do is put to my blog for ref and copy of the internal use!! and that time i was paste to one of the mail and same think i paste to serverfault also and forgot paste the like for the same.....

  Jim B : You really shouldn't paste from another persons content without attribution. I think it's poor form and in many cases patently illegal. Is it really so much to add the link to the text?

  Rajat : ya sure next time i'll make sure i'm every day learning from you guys thanks for all the lesson from you guys all are wel come

  Stefan Lasiewski : @Rajat : It appears you have internet access now. Can you edit your post and make sure your post is correctly attributed to the source?
  From Rajat

• TLS is essentially an upgrade to SSL. The changes to it are not dramatic, but significant enough to break compatibility with SSL3.0.

  The Wikipedia article covers it extensively but in reasonably understandable terms. (I don't mean to RTFM, but I don't want to repeat everything there.)

  They are used in similar ways, and is still referred to as SSL. Basically, you choose your encryption scheme to be one or the other.

  Chris S : +1, The biggest difference is that SSL is implicit encryption, meaning the connection starts with an encryption handshake and doesn't do anything until that's successful. TLS is explicit, the connection starts and at some point the client asks to start encrypting the communication.

  gWaldo : Well put, Chris

  grawity : @Chris: Are you sure about that? `openssl` seems to disagree. (Many programs say "TLS" when they mean "STARTTLS".)

  Chris S : @Grawity, I think you're confusing TLS's fallback mode with SSL. Many apps will use a TLS wrapper that recognizes an SSL negotiation and starts the handshake immediately. If an app is running pure TLS (w/o fallback) then it must issue the STARTTLS (or equivalent, it's protocol dependent, though most protocols use that) before the encryption handshake begins.

  Nasko : All of those comments apply to SSL/TLS being used by other protocols. SSLv3 and TLSv1.0 are almost identical with differences only known to the protocol experts.

  Nasko : Also, TLS does not break compatability with SSL, please verify your sources.

  Bruno : @Chris, TLS and SSL are virtually the same thing (except a few extensions, cipher suites, ...). STARTTLS is for upgrades to TLS within the same TCP connection. That's often called "TLS" in contrast to "SSL", but by mistake. Both TLS and SSL can be upgraded from a TCP plain connection by initiating the handshake after having exchanged some plain data. `STARTTLS` is just a way to tell the application protocol that this is going to happen (otherwise the SSL/TLS messages would mean nothing to the application protocol).

  Bruno : (I meant TLS and SSL to be "virtually the same thing" mostly from the usage point of view, some of these small changes create incompatibilities.)

  Chris S : @Bruno, can you provide links to any documentation about what you're describing? I've programmed a number of applications using OpenSSL, and what you're saying is definitely not the way their API works, I'd be interested if I'm missing out on some functionality on account of limiting myself to that API.

  Bruno : I'm fairly sure upgrading a socket could be done with OpenSSL, but haven't tried. It can definitely be done in Java and Python (via its OpenSSL wrapper). This happen for example when you use `CONNECT` on a plain HTTP proxy to connect to an HTTPS server (the proxy just relays the TCP connection after the `CONNECT` command, and the client just upgrades to TLS/SSL on the same connection). An [example here](http://code.google.com/p/python-httpclient/source/browse/trunk/httpclient/httpclient.py?spec=svn8&r=7) (`CONNECT` line 426 and `convert_ssl_sock`).

  Bruno : For the theory, "SSL and TLS: Designing and Building Secure Systems" by E. Rescorla is very good.

  Bruno : There is an example of `STARTTLS` as well in SMTP in [this document](http://sial.org/howto/openssl/tls-name/) mentioned by the OP in [another question](http://stackoverflow.com/questions/3660798/what-happens-on-the-wire-when-a-tls-ldap-or-tls-http-connection-is-set-up): the client is expected to send the SSL/TLS `ClientHello` after receiving `220 2.0.0 Ready to start TLS` from the server (itself sent in response to the `STARTTLS` command).
  From gWaldo

• TLS and SSL are closely related technologies.

  First, email and Opportunistic TLS. ESMTP has the option of performing the actual data transfer portion of the conversation over an encrypted link. This is part of the protocol and has been called TLS for most of its existence. It works roughly like this:

  -> EHLO foreignmailer.example.com
  <- 250 Howdy, stranger
  <- [list of capabilities, of which TLS is listed]
  -> [Indicates it wants to start a TLS session]
  <- [accepts negotioation]
  -> [Mail actions, of which LOGIN might be one]
  

  Once the TLS session has been started, new login methods might be available. This is an example of a protocol that includes Transaction Layer Security in it directly. The certificates used are the same kind of certificates used for SSL over HTTP.

  For an example of a service that doesn't include TLS directly, take POP3-over-SSL. In that case, the secure session is negotiated before the actual protocol is negotiated. In essence, POP3 is being encapsulated inside a secure session.

  In general, if a service supports SSL it can be extended to support TLS. Whether or not that has been done is up to the maintainers of the service. This does mean that TLS can replace SSL in "SSL VPNs".

  SSL VPNs are distinct from their IPSec based cousins in that the secure session is done at a different level. SSL VPNs do their work much the same way that POP3-over-SSL does, in that traffic is encapsulated over an existing TCP connection. IPSec VPNs create an IP-level secure tunnel, where SSL VPNs create a TCP-level secure tunnel. The reason SSL VPNs seem to be taking over is that they're easier to set up and are more tolerant of bad network conditions. SSL VPNs can and do use the TLS protocol for securing the session, though it does depend on the maker of the VPN itself.

  As for the exact protocol level differences between SSL and TLS, that I can't get into. TLS as a standard was arrived at later than SSL and therefore includes some of the lessons learned in the early SSL versions. SSLv3 was ratified back in 1996 and TLS1.0 in 1999, and further protocol development appears to be limited to the TLS suite. It has taken a LONG time for SSLv1 and v2 to go away. TLS is the clear successor of the SSL suite.

  MakerOfThings7 : @sysadmin1138 When should SSLv3 go away and it be replaced by TLS? Any situations today or in the near future that this would be relevant?

  sysadmin1138 : @MakerOfThings7 In terms of browser support, it will go away once 90% of actively browsing users support TLS without failing back to SSLv3. That'll probably happen some time in the next 5-7 years. That may change if an easy to exploit weakness is discovered in SSLv3 that would force a more rapid roll-out.
  From sysadmin1138

• Is TLS the "new" version of SSL? What features does it add, or security issues does it address?

  TLS is T ransport L ayer S ecurity and generally refers to the STARTTLS command in SMTP mail servers. It may or may not use SSL (SEE palm versamal for an example) but in general SSL is the main security system used. TLS has also been used for other purposes (like HTTP ) and the latest RFC spec is at version 1.2

  Can anything that supports SSL support TLS? What would be involved in making the switch? Is the switch worth it?

  Usually but by anything, with TLS being the consideration, you are referring to mailservers, so specifically mailservers that have an SSL cert can use TLS to transfer mail and recieve mail.

  Why is it that emails are sent over "Opportunistic TLS" and VPN's often called SSL VPN? Is there a difference in the technology, perhaps creating room for a "TLS VPN" product line ?

  This smells like the marketing meatheads got in the room. "Opportunistic TLS" simply means that if starttls does not return a 220 (Ready to start TLS) go ahead and send the email anyway. Note that TLS is a SENDER option not a reciever option it might be possible with some mail servers to refuse non-TLS mail but that would be the exception not the rule.

  TLS also supports mutual authentication and not simply encryption of a connection.

  Sending an email over a VPN (whether SSL or another security scheme) simply makes the mailservers security essentially irrelevant, you can use TLS over a VPN (and you can even use TLS as the VPN security scheme) but it doesn't necessarily affect how the mail is transported if only the VPn connection is encrypted between mailservers (so from the source and destination mailservers, they might be transmitting standard cleartext)

  Nasko : I beg to differ. TLS does not generally refer to STARTTLS command in SMTP. Any documentation that you read will refer to TLS as the TLS protocol, which is used by SMTP to protect its traffic. Now when it comes to "Opportunistic TLS", then you can involve higher level protocols which have the "opportunity" to use TLS or not.

  Jim B : You are certainly welcome to disagree however if you ask 10 admins what TLS is used for 9 will say email. Even the question presumes emails regarding TLS. I also mention that TLS is used for other things. RFC 2434 defines which ciphers can be negotiated in the serverhello message- it has nothing to do with opportunistic TLS. SMTP doies nto define any encryption. RFC 3207 defines starttls as a server extension

  Bruno : "TLS" only refers to "STARTTLS" incorrectly. STARTTLS is just a keyword to generalize the approach, but it requires integration in the initial protocol. The STARTTLS command looks similar in SMTP and IMAP, but needs to be integrated in the syntax in LDAP; the same mechanism in S-HTTP (not HTTPS) doesn't use that keyword. It's not because mail clients offer a choice between "SSL" and "TLS" to mean a choice between initial and opportunistic SSL/TLS that their use of the name is right. I bet some SMTPS servers support TLSv1 very well, upfront. You might also see some SSLv3 after using STARTTLS.
  From Jim B

• SSL as already people pointed out is a protocol designed by Netscape in the past. At some point the IETF standards body decided to adopt the SSLv3 protocol as a standard one, so it got change very subtly and it was named TLSv1.0.

  So for most people, TLSv1.0 is almost equivalent to SSLv3. The reason people still call the family of protocols SSL is because of historical reasons - everyone is used to the name, so they keep on using it. It is quite possible for the VPN to be using TLS under the cover, but the marketing name still stays as SSL VPN.

  Since TLSv1.0, there have been two revisions of the standard and it is now at TLSv1.2, which while still compatible, has some significant changes. Because of the SSL/TLS design, both client and server can negotiate which version of the protocol they want to use, so clients using TLSv1.0 can still talk to servers implementing TLSv1.2 and vice versa.

  Considering the interoperability between all the versions of the protocol, there is no "making a switch", since they are the same family. It is a question of "do I need to use newer version?". As with any other area, the answer to this question will depend on whether the current version you are using has any limitations or not. Currently there are no problems with using SSLv3, but the majority of clients and servers out there work with TLSv1.0.

  I hope this clarifies the picture a bit. If not, let me know what is still confusing I will try to explain further.

  From Nasko