Thanks to the recent NSA/Snowden allegations, all of the major websites have been sending every cat picture, post, and tweet over “secure” HTTP (HTTP/S).  This particular usage of HTTP/S is dangerous theater.

HTTP/S only secures a connection between two endpoints.  An endpoint would be a device (like your phone or desktop) or a server (like or  HTTP/S does nothing to secure data once it arrives at an endpoint.

Even when implemented flawlessly, the protocols used to make HTTP/S secure are not bullet-proof.  It would not be terribly difficult for a government — or even a highly-motivated individual — to compromise the security that HTTP/S offers.

HTTP/S is secured by either the Secure Sockets Layer (SSL) protocol, or by the newer Transport Layer Security (TLS) protocol. To illustrate the limits of HTTP/S, here is a rough idea of how SSL and TLS work:

  • SSL and TLS use two different types of cryptography: public-key and symmetric-key.
  • The first stage uses public-key cryptography to safely pre-share a secret that will be used in the subsequent symmetric-key cryptography stage.
  • A critical step in good public-key cryptography is authentication — the act of making sure that the users on each end of the conversation actually are who they claim to be.
  • Public-key cryptography without authentication is vulnerable to what is called a “man-in-the-middle attack.”


    Say we have two conversation partners, A & B.  In public-key cryptography, each partner generates a key pair.

    The key pair consists of a public-key and a private-key that are related to each other.  The public-key is used to encrypt messages and is shared with a conversation partner.  The private-key is used to decrypt messages that were encrypted by its corresponding public key.  The private key is kept secret.

    Without authentication, it becomes possible for a third-party C to insert himself into the conversation by passing his public-key off as A’s to B and as B’s to A.

  • SSL/TLS “solves” the authentication problem by using certificate authorities (CAs).  The CA is a server which verifies that the public-key presented by a conversation partner is actually his.
  • After the secret has been shared, symmetric-key cryptography can be used to encrypt communications going forward.

By authenticating a public-key with a CA, we are really just substituting trust in our connection with trust in our CA.  CAs are susceptible to governments, bugs, hackers, disgruntled employees, etc.  Governments can easily listen in on an internet connection.  It is just an extra step for them to coerce a CA into validating bogus keys.  This has already happened in other countries. 

An even bigger issue here is stored data.  When our pictures, messages, and account numbers hit persistent storage in the data center, they are typically not encrypted at that point.  Consider the recent Target data breach, or the NSA’s PRISM surveillance program.  In both cases, no one even had to bother with decrypting an SSL stream — they just went in through the back door and captured the raw data.  This is especially dangerous when people under oppressive regimes are lulled into trusting websites more than they should.

As a technology, SSL/TLS is not a bad thing.  It presents an additional obstacle to anyone trying to eavesdrop on a connection.  SSL/TLS becomes a bad thing when internet companies abuse it as PR stunt while continuing to hand over sensitive data to governments upon request.

← Older   Newer →

Leave a Reply

<a href="" title="">, <abbr title="">, <acronym title="">, <b>, <blockquote cite="">, <cite>, <code>, <del datetime="">, <em>, <i>, <q cite="">, <s>, <strike>, <strong>