Should we still use [SSL] as tag instead of [TLS]?

Question

This was originally decided at The big tag naming discussion in 2011:

4. It looks like tls should be a synonym for ssl.

   While technically TLS is a different protocol than SSL, they are quite similar (TLS 1.0 is more similar to SSL 3.0 than SSL 3.0 to SSL 2.0), and often implementations know (versions of) both protocols.

   SSL is the preferable tag name since the acronym is more known than TLS. (I'm just now writing a tag wiki excerpt + tag wiki which mentions both names.)

In the mean time SSL 3.0 has been deprecated and more people should be familiar with TLS.

So we should consider making tls the main tag and ssl a synonym of it. Security.se is already using TLS as the main tag.

Answer 1

My opinion is that "SSL" and "TLS" are not to be opposed. TLS is the standard acronym for a standard protocol, published by IETF as a "Standards Track" RFC; it now covers three protocol versions (TLS 1.0, 1.1 and 1.2) that are quite similar to each other. On the other hand, "SSL" is a loose designation for three protocols that are very distinct from each other(*), and, for a long time, were known to the non-Netscape world only through drafts and what amounts to reverse engineering (i.e. SSL was what you had to do to be able to talk to Netscape Navigator). SSL 3.0 is now a RFC as well, but not a "standard"; it came very late on the scene (2011) and has category "Historic", which is, in the RFC hierarchy, at the very bottom, even lower than mere "informational".

Meanwhile, the "SSL" acronym became widespread in all dealings with HTTPS. That last acronym means "HTTP Secure", but who knows that ? Most people believe that the 'S' at the end of "HTTPS" means "SSL" -- and we may note that it still is "HTTPS", not "HTTPT". When an administrator wants a certificate for his Web server, he googles for a "SSL certificate", not a "TLS certificate". When programming in Java, you use a SSLSocket object; with .NET it is a SslStream. If using C then the most widely used implementation is OpenSSL, and almost all relevant functions have a name that starts with "SSL".

Furthermore, the split between the "SSL" and "TLS" names does not match the technical reality. SSL 3.0 and TLS 1.0 are almost identical to each other; and library implementing either is easily modified into supporting both. The differences between SSL 3.0 and all TLS versions are much smaller than between SSL 2.0 and SSL 3.0; grouping SSL 3.0 with SSL 2.0 under the name "SSL" while keeping TLS 1.0 in TLS is akin to stating that bats are birds, or that whales are a kind of fish.

The naming difference does not match security either -- if we want to separate between "broken" and "non-broken" protocol versions, we should put TLS 1.0 in the "broken" bag since it does not resist chosen-plaintext attacks (the so-called "BEAST" attack) unless the implementation performs some elaborate trickeries that are not specified anywhere except as a handful of more-or-less clear blog posts (the "1/n-1 split").

My point here is that while IETF's goal was, initially, to rename the protocol (partly to avoid legal issues with possible Netscape's trademarks, partly to insist on the idea that the protocol fits any transport medium, not just TCP connections), this particular battle is lost. The renaming effort began in 1996 (at least) and has not succeeded yet, almost 20 years after -- I don't see it winning any time soon. Right now, insisting on saying that "TLS is not SSL" verges on the pedantic, and tends to spread confusion instead of reducing it.

My stance, when I talk about any of the SSL and TLS protocol versions, is to say "SSL" to designate the whole family of protocols, and that includes SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2 -- these are all "SSL" in my view. When I want to avoid any further debate I often say "SSL/TLS" (a Google-compatible compromise -- since it is matched by searches using both acronyms). When I want to designate a specific protocol version, I use the complete expression, e.g. "SSL 3.0".

Back to the question at hand, I think that ssl and tls shall be complete synonyms of each other; and there is no distinction that should be made between protocol versions at tag level. In fact, if we want to have sub-tags, then they should not be about protocol versions but about protocol elements, e.g. ssl-dhe or tls-aead. (I don't think such sub-tags are warranted right now; but I believe they would still be more relevant than sub-tags based on the particular protocol version.)

We can still make tls the "canonical" tag if that's what it takes to keep some people happy, although, as explained above, ssl would probably clearer as a searching tool. People who know what TLS is also know what SSL is, and it would need some peculiar amount of narrow-mindedness to see "ssl" and think "oh, it says 'SSL', so it is certainly not about TLS 1.0". On the other hand, people who know only the term "SSL" may well miss on posts if they don't know that "TLS" is relevant too. Fortunately, the search engine knows how to apply synonyms (that's what they are for).

---

^{(*) SSL 1.0 was never published, and has been described as "very embarrassing". Known details about it seem to imply that it was, indeed, very distinct from both SSL 2.0 and SSL 3.0.}

Answer 2

For me, in an ideal world:

1. ssl for questions related to SSL 2.0^†, since tls doesn't make sense here
2. tls for questions related to SSL 3.0 & TLS

However, users might accidentally use ssl for SSL 3.0 / TLS questions, even if the tag description says that ssl is only used for 2.0. Further, the volume of questions we receive for 2.0 is rather low.

Thus for ease of use, my vote is have tls be the main tag and ssl the synonym.

Whatever the case, ssl should definitely not be the main tag.

^† And SSL 1.0, I guess, if such a question ever pops up somehow