The biggest issue with all cryptography, both symmetric and public-key, is its susceptibility to man-in-the-middle (MITM) attacks. Simply put, Alice and Bob want to communicate securely by setting up a shared secret key they will use to encrypt their messages. But, a malicious third party (Eve) intercepts the messages, pretends to be Bob when talking to Alice and pretends to be Alice when talking to Bob. Instead of Alice setting up a secret connection with Bob, Eve sets up a secret connection with both Alice and Bob, and relays all the communications. Eve ends up controlling the entire communication.
Public-key crytpography doesn’t have a solution for this problem, and the only way we’ve found around this attack is the mechanism of certificates, signed by (reliable) third parties, that Alice and Bob can use to prove that they are in fact who they claim they are. In order to prevent the signatures to be forged by yet another MITM attack, the public keys of most Certificate Authorities (CAs) that are needed to verify the certificate signatures typically come preinstalled with most modern browsers.
So, certificate verification is a big step in SSL/TLS, the protocol that all
browsers use for secure communication (whenever you see
https:// in your
browser URL bar).
While it seems like certificates completely eliminate the chance of MITM attacks
(unless the browser or CA private keys are compromised), there is still some
surface area for attacks, like SSL strip. The basis for this attack lies in the
fact that most websites, say your email hosts website, is usually accessed
http. The website then responds with an
http 302 Found code, along
with the location where the browser should go looking for the resource. Websites
use this mechanism to redirect all visits over
http to the
website instead. That is, when you go to
automatically end up at
https://www.google.com, probably without the user ever
And there’s the rub: unless you’re a very security-concious person, you wouldn’t
even notice whether or not you’ve been redirected to the
https version of the
Supposing you visit your mail provider’s website over
http — let’s be honest,
we all do —, a man in the middle could intercept this traffic and essentially
stop the redirect from happening. Instead, the man in the middle could set up
https connection with your mail provider, but simply downgrade from
http before sending the response back to the user. To the user, the only
noticeable difference would be that the connection remains over
https, but other than that, the user experience is identical.
Certificates are of no help here, because the user’s browser never even realizes it should be communicating over TLS!
At this point, of course, we’re back to our classical MITM scenario: the malicous eavesdropper has access to all the unencrypted messages coming from the unsuspecting user.
Does this mean TLS and certificates are essentially useless? Not entirely, and
there are definitely ways to somewhat mitigate this vulnerability. One easy
thing you could do as a web host is enabling HTTP Strict Transport Security
(HSTS). It’s a specific
https header that the server can set on its response
packets that intstructs the browser to only every allow the site to be accessed
https for a given duration of time (eg, a year). Because the header can
only be set over
https, it means that the user must have established an
https connection with the webserver at least once for HSTS to take effect.
This means the initial visit is still vulnerable to SSL stripping attacks, but
it greatly decreases the risk.
Although browsers are really stepping up to give clear
warning of websites that are served up over insecure