586

I get confused with the terms in this area. What is SSL, TLS, and HTTPS? What are the differences between them?

Improve this question
2

3 Answers 3

Reset to default
570

TLS is the new name for SSL. Namely, SSL protocol got to version 3.0; TLS 1.0 is "SSL 3.1". TLS versions currently defined include TLS 1.1 and 1.2. Each new version adds a few features and modifies some internal details. We sometimes say "SSL/TLS".

HTTPS is HTTP-within-SSL/TLS. SSL (TLS) establishes a secured, bidirectional tunnel for arbitrary binary data between two hosts. HTTP is a protocol for sending requests and receiving answers, each request and answer consisting of detailed headers and (possibly) some content. HTTP is meant to run over a bidirectional tunnel for arbitrary binary data; when that tunnel is an SSL/TLS connection, then the whole is called "HTTPS".

To explain the acronyms:

  • "SSL" means "Secure Sockets Layer". This was coined by the inventors of the first versions of the protocol, Netscape (the company was later bought by AOL).
  • "TLS" means "Transport Layer Security". The name was changed to avoid any legal issues with Netscape so that the protocol could be "open and free" (and published as a RFC). It also hints at the idea that the protocol works over any bidirectional stream of bytes, not just Internet-based sockets.
  • "HTTPS" is supposed to mean "HyperText Transfer Protocol Secure", which is grammatically unsound. Nobody, except the terminally bored pedant, ever uses the translation; "HTTPS" is better thought of as "HTTP with an S that means SSL". Other protocol acronyms have been built the same way, e.g. SMTPS, IMAPS, FTPS... all of them being a bare protocol that "got secured" by running it within some SSL/TLS.
Improve this answer
8
  • 53
    To make the confusing perfect: SSL (secure socket layer) often refers to the old protocol variant which starts with the handshake right away and therefore requires another port for the encrypted protocol such as 443 instead of 80. TLS (transport layer security) often refers to the new variant which allows to start with an unencrypted traditional protocol and then issuing a command (usually STARTTLS) to initialize the handshake.
    – Hendrik Brummermann
    Commented Jul 10, 2011 at 17:23
  • 19
    SSL no longer exists. There is TLS 0.9, and for the insane, TLS version -0.1.
    – Jumbogram
    Commented Jul 11, 2011 at 2:03
  • 66
    Don't confuse the issue by mentioning STARTTLS! TLS and SSL provides a generic secure connection that can be used to send any protocol over it: when the HTTP protocol is sent over TLS or SSL it is referred to as HTTPS. The STARTTLS feature is only available in the SMTP email exchange protocol and has nothing to do with HTTP or HTTPS. TLS and SSL know nothing about the STARTSSL command. Both TLS and SSL always starts with the handshake to establish a secure connection.
    – Hoylen
    Commented Mar 28, 2014 at 0:36
  • 3
    If TLS and SSL are essentially the same thing, how come when setting up an e-mail account in Outlook the encryption options are SSL or TLS?
    – Celeritas
    Commented May 30, 2014 at 23:45
  • 20
    With SMTP and IMAP, there are two methods to use SSL: one is similar to HTTPS (you start with SSL, and within the tunnel you use the plain protocol), the other uses the STARTTLS command (you start with the plain protocol, and then switch to SSL after some negotiation). The client must know what to do beforehand (notably because both methods don't use the same port: 143 for IMAP+STARTTLS, 993 with IMAP-within-SSL). As general overlords of Confusion, Microsoft decided to call these two methods "SSL" and "TLS".
    – Thomas Pornin
    Commented May 31, 2014 at 10:18
69

SSL and TLS are protocols that aim to provide privacy and data integrity between two parties (see RFC 2246), designed to run over a reliable communication protocol (typically TCP). Although the TLS specification doesn't talk about sockets, the design of SSL/TLS was done so that applications could use them almost like traditional TCP sockets, for example SSLSocket in Java extends Socket (there are small differences in terms of usability, though).

HTTPS is HTTP over SSL/TLS, where the SSL/TLS connection is established first, and then normal HTTP data is exchanged over this SSL/TLS connection. Whether you use SSL or TLS for this depends on the configuration of your browser and of the server (there usually is an option to allow SSLv2, SSLv3 or TLS 1.x). The details of how HTTP and SSL/TLS form HTTPS are in RFC 2818.

Regarding the difference between SSL and TLS, you may be interested in these two answers I wrote for these similar questions on StackOverflow and ServerFault:

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 so 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 can send 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.

Generally, the higher the version or SSL/TLS, the more secure it is, provided you choose your cipher suites properly too (higher versions of TLS also offer using cipher suites that are considered better). (SSLv2 is considered insecure.) In addition, SSL doesn't fall under the IETF scope. For example, the TLS renegotiation fix had to be retrofitted for SSLv3 (although SSL/TLS stacks had to be updated anyway).

You may also be interested in this answer:

Note that some people oppose SSL and TLS as being the difference between "SSL/TLS upon connection" and "upgrade to TLS" (after some conversation using the application protocol). Despite some of these answers being relatively highly upvoted, this is incorrect. This mistake is propagated by the fact that certain applications, like Microsoft Outlook, offer two configuration options called "SSL" and "TLS" for SMTP/IMAP configuration when they really mean "SSL/TLS upon connection" and "upgrade to TLS". (The same goes for the JavaMail library, I think.)

The RFCs that talk about STARTTLS were written when TLS was already an official RFC, that's why they only talk about upgrading the connection to TLS. In practice, if you tweak the configuration of your mail client to force it to use SSLv3 instead of TLS (not something I would generally recommend), it's still likely to be able to upgrade to SSL/TLS using STARTTLS with an SSLv3 connection, simply because it's more about the mode of operation than the version of SSL/TLS and/or the cipher suites.

There is also a variant of HTTP where the upgrade to SSL/TLS is done within the HTTP protocol (similar to STARTTLS in LDAP/SMTP). This is described in RFC 2817. As far as I know, this is almost never used (and it's not what's used by https:// in browsers). The main relevant part of this RFC is the section about CONNECT for HTTP proxy servers (this is used by HTTP proxy servers to relay HTTPS connections).

Improve this answer
4
  • 3
    RFC 2817 is not used in practice because it messes too much with the internal structure of HTTPS client. Instead, clients now use the "Server Name Indication" to solve the same problem, namely to advertise the intended server name before the server sends its certificate (this is for virtual hosting); SNI is an extension added by the client at the beginning of the TLS handshake.
    – Thomas Pornin
    Commented Jul 11, 2011 at 12:04
  • @Thomas, agreed, but the diff. between HTTPS (as we use) and RFC 2817 would have been the same as between SMTPS and STMP+STARTTLS. Indeed, one of the points it addresses is the same problem as SNI, but I think there was less demand at the time for this, and clients/servers supporting RFC 2817 never really took off. Making sure the URI was visibly https:// (to make it arguably more secure?) seems to have been an argument to keep the clear distinction (instead of possibly transparent upgrade), AFAIK. There's also a discussion here: ietf.org/mail-archive/web/tls/current/msg01096.html
    – Bruno
    Commented Jul 11, 2011 at 13:00
  • 1
    You write SSLv3 over TLS Is that a typing mistake of some sort? What do you mean? As I understand it the versions went something like SSL v1 SSL v2 SSL v3 TLS v1.0 TLS v1.1 TLS v1.2 So to say SSLv3 over TLS is like saying Windows 98 over Windows 7. Or encryption within an encryption. What do you mean?
    – barlop
    Commented Oct 20, 2014 at 13:03
  • 2
    @barlop Sorry, it was indeed badly worded, I meant it as "instead of".
    – Bruno
    Commented Oct 20, 2014 at 13:38
18

SSL VS TLS

The terms SSL and TLS are often used interchangeably or in conjunction with each other (TLS/SSL), but one is in fact the predecessor of the other — SSL 3.0 served as the basis for TLS 1.0 which, as a result, is sometimes referred to as SSL 3.1.

Which is more Secure SSL or TLS

In terms of security they both are consider equally secured

The main difference is that, while SSL connections begin with security and proceed directly to secured communications, TLS connections first begin with an insecure “hello” to the server and only switch to secured communications after the handshake between the client and the server is successful. If the TLS handshake fails for any reason, the connection is never created.

(SSL and TLS vs HTTP)

HTTP protocol is used to request and recive the data and https in which the 's' is nothing but secure SSL which makes the http protocol request and receive activity encrypted so no middle man attacker can obtain the data easily.

If neither SSL nor TLS is used with HTTP

then your connection with the web server is unencrypted all the data will be sent in plaintext any middle man attacker can obtain and view that data.

so should go with SSL or TLS

well, both are same but TLS is more extensible and hoping to get more support in future and TLS is backward compatible.

Improve this answer
3
  • 11
    Sorry, -1 for "The main difference is that, while SSL connections begin with security and proceed directly to secured communications, TLS connections first begin with an insecure “hello” to the server and only switch to secured communications after the handshake between the client and the server is successful." . SSLv3 and TLS connections are both initiated with a handshake, done in the very same way (both starting with ClientHello). You might be confusing SSL/TLS on connection and upgrade to TLS via something like STARTTLS.
    – Bruno
    Commented Jul 11, 2011 at 9:17
  • TLS 1.2 finally supports SHA-2 based HMAC, so in theory new deployments should be using TLS 1.2 only
    – Hubert Kario
    Commented Jul 12, 2011 at 20:53
  • 1
    @Bruno the claim that an initial cleartext hello is the TLS vs. SSL difference is indeed false, however I suspect the confusion is not with SMTP connection upgrade but rather with the Server Name Indication (SNI) extension of TLS whereby a virtual server host is first told in cleartext which of its hostnames to perform a handshake for (and by extension which certificate to use). So it's indeed a wrong claim for TLS itself, but it's probably a somewhat nearer miss.
    – Chris Stratton
    Commented Jul 22, 2017 at 19:47

You must log in to answer this question.

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