|Table of Contents|
|SSL v1.0||Only used within Netscape development laboratories, never publicly released.|
|SSL v2.0||Released in February 1995, quickly found to have a number of security flaws. The flaws were in the logic and the protocol itself, the ciphers were not at fault and were adequately secure at the time.|
|SSL v3.0||Released in 1996, fixed the logic / protocol flaws of v2.0|
in January 1999 as an upgrade to SSL.
In 2002, Phillip Rogaway discovered a theoretical attack against the use of Cipher Block Chaining in TLS v1.0 and SSL v3.0.
|TLS v1.1||Defined in RFC4346 in April 2006. Protects against the Cipher Block Chaining attacks by replacing the implicit Initialization Vector with an explicit one, and changed the handling of padding errors.|
|TLS v1.2||Defined in RFC5246 in August 2008. Added AES encryption and SHA-256 hashing. Further refined to disallow backward compatability to SSL v2.0 and use of weaker ciphers as per RFC6176.|
Netscape developed a protocol they called Secure Sockets Layer (SSL) to provide multiple network communications security features. These include host authentication through the use of digital certificates, key exchange through asymmetric cryptography, efficient message confidentiality through symmetric cryptography, and message integrity through hashed message authentication codes.
Later modifications to SSL evolved into Transport Layer Security (TLS), which was first defined in 1999. We had already gotten into the habit of using "SSL" as a generic term, sort of like making a "Xerox" of a document or wiping our nose with a "Kleenex". Further confusing matters, TLS v1.0, v1.1, and v1.2 are also known as SSL v3.1, v3.2, and v3.3, respectively!
As you see in the table at left, the sequence of protocols was defined as a series of refinements and corrections to design errors.
Application protocols can specify the use of TLS in two ways. One method, used by HTTPS as opposed to HTTP, is to connect to a different TCP port — 443 for HTTPS versus 80 for HTTP. Once TLS has been established, HTTPS is exactly the same protocol as HTTP.
Other protocols always connect to the same TCP port but
then the client (that is, the host that initiated the
connection) sends a request to switch to TLS protection.
For example, the
STARTTLS request used
in SMTP and NNTP for mail and news, respectively.
TLS is established through a handshaking sequence:
1 — The client requests a secure connection and presents its list of supported ciphers and hash functions.
2 — The server picks the strongest cipher and hash function that it also supports, and notifies the client of that selection.
3 — The server sends its digital certificate, containing (among other things) the server's name and public key encapsulated within a digital signature from a trusted Certificate Authority or CA.
4 — Optionally, the client may contact the CA, using a URL embedded within the certificate, to see if the certificate is still valid or if it has been placed on the Certificate Revocation List (CRL) for any of a variety of reasons. Clients generally do not do this step as it would delay the establishment of the desired connection. However, if the CA has been compromised (as has happened in some high profile cases), the browser will accept bogus certificates.
5 — The client generates a random number, encrypts it with the server's public key, and sends the result to the server. It is possible that the server is really an imposter. Anyone can connect to the server and save a copy of the offered digital certificate, later claiming to be that server and sending out the saved certificate. This step offers a challenge to the purported server.
6 — An imposter could not continue, but the legitimate server can use its private key to decrypt that random number and continue with the handshaking sequence.
7 — Both the client and the server use that random number (or nonce, for "number used only once") to generate the shared secret key or keys to be used for subsequent communication. Asymmetric cryptography, using private-public key pairs, is computationally very expensive in comparison to symmetric algorithms. For the limited number of steps based on small data as used in host authentication and key management, the computational efficient just doesn't matter. But the subsequent communication might easily move many gigabytes of data if what follows is a long stream of audio or video data, or the download of large data files.
At this point, things seem pretty good, right? We are using a fairly complicated protocol, but we are on its sixth version (plus a refinement to disallow rolling back to earlier, insecure versions), and its most recent major release added cryptographically stronger ciphers and disallowed the use of weaker ones.
We are keeping up with our patches, so we have the latest version of the OpenSSL shared libraries, programming API, and command-line toolkit. We have the latest Apache web server using its mod_ssl or possibly the gnutls module for HTTPS over TLS. And, the latest version of the Firefox browser. So, we should be safe, right? Right?
Back in 2002, Phillip Rogaway discovered an attack against certain uses of Cipher Block Chaining modes of encryption. For details, see his paper "Evaluation of Some Blockcipher Modes of Operation". Rogaway's attack was certainly possible, in theory, but there was no practical implementation or demonstration of the attack, and it was thought to be nothing but a theoretical risk for the time being.
The IETF and the TLS working group published the TLS 1.1 protocol in RFC4346 in April 2006. This plugged the logical holes in TLS 1.0.
Our problem is that the IT industry did not move beyond TLS version 1.0 in either browsers or clients, because the threat was thought to be nothing but a theoretical one requiring a brute-force search of an impractically large space.
Thai Duong and Juliano Rizzo gave a presentation at the Ekoparty Security Conference in Buenos Aires in September, 2011. Their paper "Here Come The ⊕ Ninjas", dated May 13, 2011, describes their approach in detail. A hostile Java applet injects data, providing a chosen-plaintext attack leading to a decrease in search requirement by a factor of 222. The theoretical attack has become practical.
Duong and Rizzo introduced a Java applet named BEAST, for Browser Exploit Against SSL/TLS. This applet breaks the "same-origin" policy built into browsers by taking advantage of a flaw in the Oracle/Java software framework.
As I mentioned, developers of web servers and web clients for the most part have not moved beyond TLS 1.0.
Looking at web server software, Apache using gnutls supports TLS 1.1 and 1.2, with TLS 1.2 disabled by default. Microsoft's IIS at version 7.5 supports both TLS 1.1 and 1.2, using TLS implementations built into the operating system, although both are disabled by default. So, it should be possible to run TLS 1.2 on your website. But when will the TLS v1.2 clients arrive?
Looking at browsers, Opera version 10 supports TLS 1.1 and 1.2. Microsoft's Internet Explorer on Windows 7/2008R2 and later can use TLS 1.1 and 1.2, although they are disabled by default. Safari on Windows 7/2008R2 and later may be able to use it.
Chrome and Firefox use the Mozilla Network Security Services (NSS) SSL/TLS implementation, and TLS 1.1 and 1.2 are not supported. Safari on Mac OS X uses a custom SSL/TLS engine that does not support TLS 1.1 or 1.2. This page introduces a report about server and browser support for TLS versions, and the report is available here.
Sadly, developers of both web servers and browsers have pointed at the other camp, saying "There is no reason for web servers to support TLS 1.1 and later because web browsers do not support that protocol", and vice-versa.
Qualys does periodic tests of large sets of public web servers to survey the sets of supported protocols. Here are their results of starting with Alexa's top one million HTTPS sites, as presented at Hack in the Box in Amsterdam in 2011:
The Qualys study is introduced
the detailed study is available here.
Out of about 300,000 of the most popular HTTPS servers, close to half of them still supported SSL v2.0, a protocol that browsers introduced since 2005-2006 refuse to use!
Only about 0.3% of the most popular HTTPS servers supported TLS version 1.1 or 1.2, the remaining 99.7% used a protocol susceptible to the BEAST attack.
Both Firefox and Chrome have been patched by updating NSS to randomize some header fields and thereby prevent the chosen plaintext injection.
Some resources on the weakness of RC4:
Many web servers were reconfigured to disable ciphers other than RC4, included in the TLS 1.0 cipher suite. RC4 is a stream cipher, not a block cipher, and so an attack based on abuse of Cipher Block Chaining will not work against it. The concern over BEAST pushed about half the HTTPS servers on the Internet to use RC4. Unfortunately for U.S. Government website administrators, or so it seemed at the time, RC4 was not approved for use under FIPS 140-2.
Then by late summer of 2013 the community came to the realization that RC4 had weaknesses. Meanwhile BEAST is a client-side attack, best mitigated in the client browser. By September of that year Qualys had concluded that for the most part patched browsers were working around BEAST and related threats and RC4 should no longer be used.
Now the preferred cipher would be AES-256-GCM — AES in Galois Counter Mode using a 256-bit key.
One year later, Juliano Rizzo and Thai Duong presented their latest work. CRIME, or Compression Ratio Info-leak Made Easy, is a practical attack against the way that TLS can be used in browsers. It would be especially useful for stealing session cookies, which would allow the attacker to then masquerade as the victim. It has been described as the potential "nation-state attack", something used not by criminals to steal your credit card number, but by nations like Iran and China to find dissidents. For more information see Ivan Ristić's blog at Qualys, Ars Technica's report, Kaspersky Lab's threatpost, and the description at iSEC Partners.
The underlying cause is that some information leaks through when you compress data before encryption, especially if the attacker is able to repeatedly insert small pieces of known data with the sensitive and relatively predictable target data. It's an elegant attack based on information theory. When the attacker-provided data has more in common with the sensitive cookie data, there is more redundancy to remove and the output of the compression will be smaller. The attacker can't read the resulting ciphertext (yet), but the smaller size indicates that the guess is getting closer.
Many of us were very worried, but CRIME seems to be much less of a threat than we had feared.
First, the server must support the compression of request data before compression. The DEFLATE compression in TLS is vulnerable, and about 42% of servers world-wide support it according to Qualys' SSL Labs tests. The newer SPDY protocol developed and used by Google is also vulnerable, but it was only supported by about 2% of servers when CRIME was announced.
Second, the browser must also support compression. Chrome supported TLS compression, and both Chrome and Firefox support SPDY, but Chrome removed support for TLS compression and Firefox either removed support or never supported it in the first place.
It seems that CRIME would be relatively easy to exploit, but much harder to find potential victims.
The easiest and friendliest, while still being very thorough and conservative is the Qualys SSL Labs automated SSL Server Test
You can also use the
gnutls-cli tool to
examine web server certificates.
Here is an example, with really long lines broken for display:
A group of researchers at Stanford University and the University of Texas published an alarming paper based on their research: "The most dangerous code in the world: validating SSL certificates in non-browser software". They say, "We demonstrate that SSL certificate validation is completely broken in many security-critical applications and libraries."
The APIs (or Application Programming Interfaces) of the standard SSL/TLS implementations have confusing settings and options. This includes OpenSSL, GnuTLS, and JSSE, plus data-transport libraries such as cURL. This leads to weaknesses in applications built on these libraries.
Amazon's EC2 Java library is vulnerable, breaking the security of all cloud applications based on it. So are the software development kits which Amazon and PayPal on-line merchants use to transmit payment details. Integrated "shopping cart" applications relying on these broken libraries include ZenCart, Ubercart, PrestaShop and osCommerce. Chase Bank's mobile banking application and other Android apps are also vulnerable.
These poorly designed APIs confront
programmers with confusing low-level interfaces.
One example used in the paper is an Amazon PHP based payment
library that attempts to secure a connection by setting cURL's
CURLOPT_SSL_VERIFYHOST parameter to
That certainly looks reasonable!
However, it should be set to
If a programmer sets it to
that is non-zero and so it ends up being interpreted as
1 and the disables the verification!
Some popular API calls don't even try to be secure.
fsockopen and Python's
httplib are popular with
programmers, even though they establish SSL connections
with no attempt at verifying the server's identity.
The authors draw three main lessons from this mess, in addition to the observation that that SSL bugs tend to be buried in the middleware and hard to find.