Tapped in

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.

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 http://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 http://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.

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.

Make HTTP from HTTPS, Version 2

An inconspicuous attack could possibly take place if a site is transmitted via HTTP with a login form, and only the entered login data is sent to the server via HTTPS. The MitM can then change the URL for sending the form from HTTPS to HTTP, without the browser warning the user. The data is then transmitted to the MitM without encryption, and the MitM can see the data before sending it to the server via the encrypted connection.

Because it is impossible to detect whether a site loaded via HTTP or HTTPS transfers the data without having a look at the site's source code, you have to rely on the warning from the browser. If the browser warns you that data has been transferred without encryption, you should only agree to it if you don't care that a MitM is reading it, too. If this data is login data or similar confidential information, you should close the connection immediately. As already mentioned, the Firefox version 44 Nightly build has marked such sites as insecure since October 20, 2015 [7].

The easiest solution to this problem is never to mix HTTPS and HTTP on the server. However, if you can't avoid this situation, you could use a subdomain for HTTPS links for which the use of HTTPS is enforced via HSTS. This workaround is no longer advised, however, because Firefox will mark the site loaded via HTTP as insecure in the future.

Insecure Cookies

Web applications often recognize their users with a session identifier that is usually stored as a cookie and automatically transmitted to the server from the browser with each request. If this cookie is transmitted via both HTTPS and HTTP, the MitM can read it during an HTTP connection and then take over the ongoing user session – as long as no further protective measures are in place before the session hijacking, anyway.

This hijacking is even possible if the user doesn't visit the website in questions (e.g., www.bank.example), as long as the MitM is active. The browser just needs to contain a valid session cookie. Then, if the attacker plants a request to www.bank.example in a website of another domain (e.g., in the form of an IMG or script tag), the browser sends all cookies belonging to the domain www.bank.example with the request. The MitM can then read the cookies and thus masquerade as the hijacked user at www.bank.example. Several tools allow these types of attacks, such as CookieMonster [9] or Firesheep [10].

The client is powerless in this case – the browser behaves the way it should, so the problem needs to be solved on the server. If the "secure" flag is set on the server side for all cookies set via HTTPS, they are only transferred via HTTPS and not via HTTP, and the problem is solved. However, the web server now no longer detects the user on sites loaded via HTTP because the session cookie is missing. Either the area where the user should be detected must be completely loaded via HTTPS, or the web application needs to be adjusted so that it detects the user without the session cookie.

Exploiting Vulnerabilities

Last but not least, other vulnerabilities could allow a MitM to spy on at least parts of the encrypted communication. Two well-known examples of this are the BEAST and POODLE attacks, which make it possible to spy on session cookies. Both types of attack require JavaScript code to be smuggled into the browser and the requests sent by it to be observed; both of these are only possible with a MitM.

The certificate check on the client also sometimes fails, as with the old Apple goto fail; vulnerability. A MitM could exploit this vulnerability to pretend that it has a valid certificate. It is also now available as a reputably insecure crypto method: The RC4 encryption algorithm and the hash function SHA-1 should not be used anymore. RC4 has now been banned by the IETF in TLS [11]. Although SHA-1 is still used by more than a million websites, soon it won't be supported, or not fully supported, by Chrome, Firefox, or Windows.

The same goes for "export encryption" with short key lengths that some browsers and servers had supported until recently for historical reasons. However, two attacks were presented in 2015 that exploited it: FREAK and Logjam. With FREAK, the MitM first enforces the use of an unsafe key length for the RSA algorithm so it can then record the resulting insecurely encrypted data and decrypt it later. With Logjam, the MitM attacks the Diffie-Hellman key exchange to force a short key, which can then be worked out.

You should always use the most up-to-date software version to prevent attacks on vulnerabilities that have already been fixed. Look out for possible workarounds for new vulnerabilities that don't have a patch yet or for recently developed attacks. The same rule applies on the server: regularly check the security of your configuration. In this case: Replace RC4 and SHA-1, if they are still in use, as soon as possible with a newer method, especially since the browsers won't be supporting these algorithms much longer.

However, you should also watch out not to overshoot the mark when securing the server. Not everything that's desirable in theory is actually possible in practice. For example, you shouldn't use the outdated TLS 1.0 any more for security reasons; however, if you do get rid of it, you'll block out all the clients who don't have a new version – and that might be quite a lot depending on the application. The best option, then, is to carry on using TLS 1.0 for now and configure it as securely as possible.

Conclusions

The vulnerabilities presented in this article have led to a lack of confidence in encrypted connections, but they have effective countermeasures, as well, and the dangers can be controlled. The biggest problem is the existing certification system. Browsers and operating systems simply trust too many CAs on faith. If any one of them plays false, they are successfully attacked; if they don't work properly, valid but unauthorized certificates are created that make attacks much easier for a MitM.

Public key pinning and certificate pinning make it much more difficult for these attacks to be successful. Google, for example, has discovered wrongly issued certificates for its Google domains on many occasions using these methods, so the danger is absolutely real.