HTTPS is not infallible

When your browser connects to a web site whose address starts with https, you’re connecting to a “secure server.” It’s considered secure, because (at least some of) the traffic between your browser and the web server is encrypted.

This business has a formidable amount of jargon. Your browser connects via one of several types and versions of protocols, and it uses one of many possible ciphers. Newer protocols are more secure than older protocols, and ciphers with longer encryption keys are more secure than ciphers with shorter keys. If an attacker can exploit some protocol vulnerability, he may be able to capture enough information to decipher encrypted data.

When your browser and a web server negotiate a connection, they try to pick the most secure combination of protocol and cipher that they can both understand. If an older browser connects to an up-to-date server, one of two things will happen:

  1. If the server has been configured to support older protocols, the server will use one of those older protocols in order to be able to talk to the browser. This is the  less secure choice.
  2. If the server has been configured not to support older protocols, the browser won’t be able to connect at all (the user will get an error message in their browser). This choice is more secure, but it causes problems for users with older browsers.

SSLLabs has a nifty web page that lets you test a web server. Type the address of your online banking site into the SSLLabs server test page and see how your bank’s site looks. My bank’s site got an F, because it supports older protocols and weak ciphers. The knuckle-dragging server pukes that work for my bank had to choose between requiring strong encryption and getting complaints from customers (and they clearly made the wrong choice).

(SSLLabs also has a page which lets you test your browser, and the browser I use for banking is not vulnerable to the things the page tests. That assuages some of the misgivings I have about using my bank’s web site.)

In the past year or so, several protocol vulnerabilities have been revealed (and corrected). These flaws often have catchy names:

This class of vulnerability is typically exploited by a man-in-the-middle (MITM) attack (see footnote). Imagine that Alice and Bob communicate with each other using written messages which they encrypt using some method that they both know how to decrypt. Alice writes a message, encrypts it, and then gives the encrypted message to a courier named Eve who takes it to Bob (these names are traditional: the courier is named Eve, because she likes to eavesdrop).

If Eve learns how to decrypt the messages, then she (the “man” in this MITM attack) can read what Alice and Bob are saying to each other. Eve could even alter the messages she delivers. In a real example, Alice would be your browser, Bob would be the web server, and Eve is someone who is somehow able to capture the traffic between the two (like someone who has tapped into the network at Alice’s ISP).

A couple of those vulnerabilities (FREAK and logjam) allow the attacker to force the the server and browser to use an older protocol and/or a cipher with a shorter key length than the browser and server might otherwise elect to use. Eve then has an easier time decrypting the traffic that she’s able to capture.

That’s easier, not easy. The traffic is still encrypted, and it takes time and computing resources to break the encryption. There are a couple of things to take away from all of this:

  1. It’s really important to keep your browser up-to-date so that it has the most modern set of protocols and ciphers.
  2. If you’re writing about a character who wants to eavesdrop on a target’s encrypted traffic, the attacker probably has to overcome the formidable obstacles of compromising the target’s network connection and have the computing resources to break encrypted traffic. It might be more believable to have your character try to get the target to fall for a phishing attack that installs a keylogger.

Footnote: Heartbleed is the exception here. That was something that potentially gave the attacker the ability to read the contents of a web server’s memory (which might include the private keys that would decrypt the server’s connections.)


Author: carl

A web programmer and Linux system administrator who would like to be a writer.