Is HTTPS A Lost Cause?

Following the allegations that the NSA is capable of reading encrypted communications many people wonder if using HTTPS is beyond help. Is any trust left in HTTPS at all?

And we're not talking about forged certificates. The question is whether or not the encryption built into HTTPS can be circumvented and if so, whether or not there is a cure.

The NSA's Surveillance and Attack Workbench

According to Bruce Schneier who has helped the Guardian journalists to make sense of the documents Edward Snowden handed them, the NSA has acquired a number of capabilities to turn the internet into a global surveillance tool:

As to Bruce Schneier's interpretation of the Snowden documents there is little doubt that

  • the NSA monitors the internet traffic to an extend, that interesting activity of individual users can be identified. By storing fingerprints of interesting HTTPS requests in large databases the NSA can trigger their activities by those fingerprints and is able to react to individual user's actions.

  • The NSA can redirect HTTPS traffic to a set of their own (quantum) servers, which are located at the core backbone of the internet and they can use their quantum servers to impersonate ordinary websites to launch an infection attack on a user's browser and computer system.

    This is possible, because NSA's quantum servers are based at a privileged position on the internet backbone, so they can react much faster to a HTTPS request than the legitimate website does. This speed advantage is being used to prevent the browser to build a connection with the original, legitimate website. Think of this as a better version of DNS spoofing without altering the IP.

  • Once the traffic has been redirected to quantum servers, these servers launch a variety of pre-arranged attacks against the user's computer system exploiting vulnerabilities of the OS and installed applications to download more pre-fabricated, NSA-prepared payloads of infecting code that help to compromise the computer system long-term. These activities read pretty much like a sophisticated version of what you'll expect from the ordinary, criminal malware industry that bothers internet users for the last couple of years.
All this sounds scary enough to fuel severe concerns about the online security of every single individual using the internet. But let me focus on the security of HTTPS for a moment.

How would someone who has this kind of abilities use it to make HTTPS traffic insecure?

I'll try to find an answer to this question, because if HTTPS is beyond help, we've lost one of the foundations on which trust in the internet age is being build.

It Starts with the Beginning

The trust HTTPS helps to establish relies on two major tasks:

Using HTTPS should make sure that the browser we use is actually connected to the website we intend to visit and after connecting to the intended server, a reliably encrypted connection should make the transfer of information between the browser and the server inaccessible for everyone, except to the endpoints of the connection.

The two tools to achieve this are digital signatures and strong symmetric ciphers which are built into the HTTPS protocol.

In order to find out what a gifted agency can do to harm the HTTPS data transmission, I'll take you to follow a process of informed guessing on what's going on in the first few milliseconds of an HTTPS connection as described by Jeff Moser in the year 2009.

The Handshake

When a browser contacts say Google via https, NSA's Quantum computers will use their speed advantage to modify the HTTPS handshake process which is performed in the clear before any kind of cryptography is being applied. Essentially, there are two pieces of information that have to be sent back to the victim's browser in the server hello packet, which can make a difference if modified. First, the server picks the encryption method that will eventually be used, and at this point the NSA can pick one of the weaker algorithms (ie. RC4-MD5) and secondly, the server certificate has to be sent to the browser. While choosing a weak encryption algorithm is easy, the certificate has to stand the test of the browser.

These server certificates were introduced to prevent anyone to sneak into the connection by attaching digital signatures to the information being exchanged. But checking the validity of such a digital signature relies entirely on the trustworthiness of the server certificate that's presented in the handshake dance between the browser and the quantum server dressed as Google. All the browser can do to check the server certificate is to use another public key from its built-in database, which is maintained by Mozilla. Roughly 20 percent of the institutions (CAs) in this database use a public key of only 1024 Bits. I found some 22 of the 116 CA public keys on a CentOS installation (2010) and 20 of 131 on Fedora (2012).

This raises the question, if one of these CAs might have co-operated with the NSA as far as to issue a sub-CA certificate signed with one of these minimal-length RSA keys, which would enable the agency to fabricate fake server certificates for any server they like, because this would extend the trust-chain of SSL certificates right into the proper NSA department. On the other hand, they might have been successful in factoring one of these 20 public key moduli to use the secret key directly, 1024 bit is not out of reach for a committed attempt to gain the ability to sign server certificates.

Attacks are selective

Forging a Google server certificate might sound risky, and you can be sure that the NSA will do its very best to avoid all risks of being caught in the act. But bear in mind that such a forged server cert will only be presented to one victim's browser at a time. All the rest of the internet community will get the real thing from Google, because the quantum servers only kick in when a trigger indicates that an interesting target is building up a connection. The victim might be able to reproduce signs of a forgery, the internet community as a whole will not notice anything strange.

Anyway, without a success at this step, no-one would be able to read the pre-master secret the victim's browser will send encrypted with the server's public key from the certificate. If the agency cannot modify certificates that stand the browser test, they will only be able to act as a kind of relay proxy to the real Google server, being able to record the encrypted traffic for later scrutiny.

Given that there has not been any certificate modification, what can be gained by selecting a weak encryption method in the HTTPS handshake?

Well, maybe the most important achievement is switching off the Diffie-Hellman Key Exchange which would make things more difficult for the agency. But then there is the problem of attacking RC4. How difficult is that?

Certainly, RC4 has its weaknesses, but its hard to say if there is a feasible attack under real-world conditions, when RC4 is used as it should be. Known attacks on RC4 today usually rely on a very large number of encryptions of the same plain text, a condition that isn't met by real-world use of RC4 in encrypted internet traffic. But it's certainly much easier to tackle RC4 than any of the strong encryption methods like AES with 256 bit keys.

Switching on Strong Cryptography

As we've seen the server hello packet determines the final selection of the encryption method used by HTTPS. When you look at your browser's list of supported ciphers you'll see 48 different encryption methods from DHE-DSS-AES-256-SHA down to RSA-RC4-40-MD5.

Some of them are disabled (set to false) because they use desperately short key lengths from 56 bits to 40 bits or no encryption at all.

But RSA with RC4 using 128 bit keys and the outdated MD5 hash function is still a choice the Firefox browser will be happy to play with.

You can use the right mouse button to toggle the boolean value to false to tell your browser not to use this encryption suite any longer, but I doubt this user setting will survive a browser update.

So, what can the web server actually do to improve HTTPS security, as it's the web server's choice that eventually determines the encryption mechanisms that will be used.

Endpoint Security Matters

In his famous quote about the quality of encryption Edward Snowdon highlighted the importance of the endpoints (the web server and the user's computer) being secure.

Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it.
In view of the NSA's attack capabilities one can imagine that maintaining endpoint security on the user's side is the hardest job. For that reason it might be prudent to focus on how to configure the web server to use only strong cryptography and to get rid of the weaker encryption methods.

Unfortunately there is a default setting in apache that might be the norm when SSL-enabled web server are being set up

SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP

I think, the majority of web servers are currently using this default setting, provided within the apache package. What does all this mean?

According to the brilliant but complex apache manual page this default is composed to be the most liberal view of accepting ciphers arranging them in the following way:

first, remove from consideration any ciphers that do not authenticate, i.e. for SSL only the Anonymous Diffie-Hellman ciphers. Next, use ciphers using RC4 and RSA. Next include the high, medium and then the low security ciphers. Finally pull all SSLv2 and export ciphers to the end of the list.
The default will generate a list of all 50 different encryption suites, with the weakest export ciphers at the end. Because RSA-RC4 is top of the list, it gets automatically selected during the handshake process.

A much more restrictive set up would be:

SSLCipherSuite !ADH:!SSLv2:!SSLv3:AES:+HIGH

This will "only" enable the following thirtytwo ciphers : 

openssl ciphers -v '!ADH:!SSLv2:!SSLv3:AES:+HIGH'   
ECDHE-RSA-AES256-GCM-SHA384   TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-SHA384       TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
ECDHE-ECDSA-AES256-SHA384     TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
DHE-DSS-AES256-GCM-SHA384     TLSv1.2 Kx=DH       Au=DSS  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384     TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-SHA256         TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256
DHE-DSS-AES256-SHA256         TLSv1.2 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA256
ADH-AES256-GCM-SHA384         TLSv1.2 Kx=DH       Au=None Enc=AESGCM(256) Mac=AEAD
ADH-AES256-SHA256             TLSv1.2 Kx=DH       Au=None Enc=AES(256)  Mac=SHA256
ECDH-RSA-AES256-GCM-SHA384    TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
ECDH-ECDSA-AES256-GCM-SHA384  TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
ECDH-RSA-AES256-SHA384        TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA384
ECDH-ECDSA-AES256-SHA384      TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA384
AES256-GCM-SHA384             TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(256) Mac=AEAD
AES256-SHA256                 TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA256
ECDHE-RSA-AES128-GCM-SHA256   TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-SHA256       TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA256
ECDHE-ECDSA-AES128-SHA256     TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA256
DHE-DSS-AES128-GCM-SHA256     TLSv1.2 Kx=DH       Au=DSS  Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-GCM-SHA256     TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-SHA256         TLSv1.2 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA256
DHE-DSS-AES128-SHA256         TLSv1.2 Kx=DH       Au=DSS  Enc=AES(128)  Mac=SHA256
ADH-AES128-GCM-SHA256         TLSv1.2 Kx=DH       Au=None Enc=AESGCM(128) Mac=AEAD
ADH-AES128-SHA256             TLSv1.2 Kx=DH       Au=None Enc=AES(128)  Mac=SHA256
ECDH-RSA-AES128-GCM-SHA256    TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128) Mac=AEAD
ECDH-ECDSA-AES128-GCM-SHA256  TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD
ECDH-RSA-AES128-SHA256        TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(128)  Mac=SHA256
ECDH-ECDSA-AES128-SHA256      TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128)  Mac=SHA256
AES128-GCM-SHA256             TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(128) Mac=AEAD
AES128-SHA256                 TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA256

I wonder how many browsers would play nicely with such a setting, but in fairness, it doesn't seem unreasonable to me to request using strong cryptography from a browser, in light of the prevailing attempts to undermine our online security on a global scale.