HTTPS couldn't be simpler from a user perspective: If you establish a secure connection (e.g., to a bank) in a web browser via an HTTPS link, your browser initially establishes an unencrypted connection to the specific server (Figure 1). The server identifies itself with a certificate containing its public key and the signature of a trusted third party, called a certificate authority (CA). The CA confirms by signature that the key belongs to the server specified in the certificate. Your browser then checks the certificate. To do so, it has a list of CAs that are trusted by the browser manufacturer. If the certificate wasn't issued by one of these CAs or the signature isn't correct or doesn't match the server, the browser displays a warning and terminates the connection, unless you need the potentially unsafe connection anyway.

Figure 1: A secure connection between client and server.

If the check is successful (or if you agree to the connection despite the error), the browser generates a symmetric key that is only used for the current session, the session key. The key is encrypted with the web server's public key and sent to the web server. Once the web server has decrypted the session key with its private key, both web browsers and web servers have a common key for the symmetric encryption process that can then be used to encrypt all other data.

However, this process does have a drawback: The session key is part of the communication. Anyone who records the encrypted communication and gets access to the private server key later can decrypt the key and then all the communication. It is therefore more secure to generate the key using the Diffie-Hellman key exchange. This encryption process ensures that the session key neither needs to be transmitted nor can be generated from the transmitted data. Even if someone does get hold of the private key and decrypts the recorded connection setup, an attacker doesn't get the session key. This process is also called "Perfect Forward Secrecy" (PFS) [1] and should ideally be used on all servers. However, several modes of attack are possible.

Attackers with a Valid Certificate

The most inconspicuous attack requires the attacker to be a man in the middle (MitM) and have a valid certificate for www.bank.example , which has been signed by a CA that is trusted by the web browser. The attacker might, for example, have procured such a certificate by attacking the CA. There are two possibilities: Either the attacker has only procured a certificate for the domain www.bank.example , or it has an intermediate certificate (Figure 2). This would allow the attacker to issue certificates on behalf of the CA. The attacker would therefore be able to create an appropriate certificate "on the fly" for any HTTPS connection on any server and then present it to the browser. In some circumstances, an attack on a CA isn't even necessary. It often happens that a CA issues certificates for servers, for which the applicant has no relevant authority.

Figure 2: An attacker can access the supposedly protected HTTPS connection in many ways and thus trick the client, as shown here with an intermediate certificate.

In all cases, the attack follows approximately the same pattern; the only difference is that a MitM with an intermediate certificate can create a certificate for the website called www.bank.example on connection, whereas a MitM that just has the certificate can use it immediately. During the attack, the MitM intercepts the requests sent by the browser and pretends to be a web server. The MitM identifies itself with a false certificate containing its public key, which allegedly belongs to www.bank.example.

Because the certificate is valid, it is accepted by the browser, which thus negotiates a session key with the MitM. Parallel to this, the MitM sets up an HTTPS connection to www.bank.example, pretending to be the user in question. After the MitM and web server have agreed on a session key, the MitM can read all the data coming from the server or the browser data and manipulate the data as needed before passing it on to the intended recipient.

The user can thus only detect an attack by checking the fingerprint of the certificate. But who knows the fingerprint? In other words, users have to rely on a solution provided by the browser: "Public key pinning" or "Certificate pinning" [2]. Pinning involves the browser receiving static, predetermined information on the admissible certificates for certain domains, for example, the key used (public key) or the issuing CA(s). This information pins the original certificate to the domain, so to speak, which makes spoofing third-party certificates difficult.

For example, if the CA is fixed, the MitM has to produce a valid certificate from precisely this CA and not from an arbitrary CA that the browser also trusts. Up to now, pinning has been supported by Chrome since Chromium 12 and Firefox from version 32. Safari and Internet Explorer have not previously supported pinning. Microsoft is considering whether to introduce it. Until then, IE users are not defenseless: The Enhanced Mitigation Experience Toolkit (EMET) has had a function similar to pinning since version 4.0 [3].

Until recently, the server was basically defenseless against these attacks. All data supplied by the client could be manipulated by MitM at will, so an attack could no longer even be recognized. However, since April 2015, there has been protection for the server in the form of pinning – at least if browsers support it. The server can use the "Public Key Pinning Extension for HTTP" (RFC 7469) [4] to specify for a certain period which public keys need to be included when testing a certificate in the trust chain.

Of course the protection only works if the user has accessed the site in question at least once without a MitM because the MitM can suppress the corresponding commands at will or change values at will. However, the protection works if the protected website has been accessed once undisturbed. After that, a rogue access point at a conference, for example, can no longer sign a fake certificate – at least as long as pinning is valid.

MitM with a Self-Signed Certificate

If the attacker doesn't have an official certificate signed by a CA for www.bank.example, they can just create and sign one themselves. However, with such a certificate, the browser will complain that it is not from a trusted publisher. If the user ignores this warning and the connection is still established, he has lost.

The same precautions apply on the client as in the first case, but it really shouldn't come to that: As soon as the browser warns you of an untrusted certificate, you should close the connection. HTTP Strict Transport Security (HSTS) can be used on the server to enforce HTTPS. A side effect in the browser is that the user is prevented from simply dismissing the warning about an invalid certificate [5].

Make HTTP from HTTPS, Version 1

The MitM can also simply convert all HTTPS links into HTTP links before it forwards the pages provided by the web server to the browser ( "SSL stripping"). If users aren't careful, they will enter their confidential data on a page transmitted without encryption. The MitM can then easily read and/or manipulate the data transmitted as clear text. Because the MitM establishes the connection to the server according to the original protocol, everything looks completely normal on the server side. A tool that demonstrates such an attack was published in 2009 [6].

As a precaution, sensitive data should only be entered on HTTPS pages, which is indicated by "https" and an identifier, such as a padlock, in the URL line that it is an encrypted page. Technically, this problem can only be partially solved. The MitM can manipulate all data and instructions sent from the server. The server protection described here only works if you have accessed the site at least once without a MitM.

Firefox promises additional protection: Since the version 44 Nightly build, sites loaded via HTTP containing a password field (<input type="password">) have been marked as insecure starting October 20, 2015 [7]. This protection is aimed at websites that could jeopardize a users' security by transferring login data unprotected. As a side effect, the function also provides protection from SSL stripping.

HSTS (RFC 6797) [8] can be used on the server to force the browser to use only HTTPS links for a certain period for the domain in question and, if necessary, for the subdomains. This works in the same way as server-side pinning, but only if the user accesses the server at least once without a MitM. The browser manufacturers are of course aware of this, which is why most browsers contain a list with domains that use HSTS. These domains are automatically configured accordingly.