Tapped in

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.