22 April 2014

https, hsts, mitm and the reasons why we are converting all our sites to secure-only sites

We have converted one of our primary customer sites to https-only, and have configured the server to comply with the HSTS standard.

To get a sense of our motivation, the first thing to read is the following recent post from the EFF: https://www.eff.org/deeplinks/2014/02/websites-hsts

This is a pretty good idea, although as seen below, by itself it is unlikely to win the war. 

More worryingly, it is a standard which depends on universal browser adoption for it to be effective. It should not be a surprise to hear that Microsoft are dragging their feet on the issue, trailing behind the makers of browsers such as Chrome, Safari and Firefox, which have already adopted the standard.

(Based on past experience, it is sensible to suspect that Microsoft will be planning to provide IE with its own idiosyncratic version which will introduce a whole new layer of security flaws, while failing to work well side by side with HSTS, and obliging web developers to employ a slew of clumsy hacks to get it to work properly on their sites.)

Will HSTS be enough? The jury is still out. There seems to be only a gradual rising of awareness of how vulnerable our "secure" systems are to a man-in-the-middle (MITM) attack. On this subject, the following is required listening: 

http://player.vimeo.com/video/50018478

This presentation is 5 years old! It hardly bears thinking about how far on hackers will be from that point by now. And the industry is only just responding to this old news.

The section beginning at 42:15 is particularly worrying. Our "client" may be securely connected to https://paypal.com/uk/webapps/mpp/merchant/.iijk.cn with a valid security certificate, and believe they are securely connected to paypal, and about to log in.

In fact, they will be connected to paypal, and paypal will believe that it is securely connected to its client.

But between them is a MITM. In fact the client is directly connected to a site on the domain iijk.cn -- a site with a valid security certificate. The characters that look like / and . in the early part of the URL are actually IDN (international domain name) characters which only look like the ascii versions, and everything appearing before the .iijk.cn is just a long complicated subdomain with international characters.

What the MITM who is operating this domain does is to decrypt all the login information coming from the client, and then pass all the same information on to paypal, pretending to be the original client, via a secure connection to paypal. That is the reason why paypal believes that it is connected securely to its client.

The MITM passes all the information from paypal back to the real client, via the genuine secure connection to the iijk.cn domain. The browser is indeed securely connected to this domain, so it shows all the indications of being securely connected. There is almost nothing the client can see that will tip them off that there is anything dodgy about their connection.

And the trick only has to last long enough for the MITM to steal the login information, a matter of a few seconds. As soon as this has been recorded, the MITM bows out of the interaction, allowing the client to continue its communication with paypal, but directly, and carry out all the operations as though nothing had happened.

In the opinion of the presenter (again, the presentation was made in 2009, and provided the direct stimulus for the development of HSTS) there is really very little we can do about this vulnerability, short of making the whole internet secure.

This happens also to be the recommendation of Edward Snowden. On http://www.ted.com/talks/edward_snowden_here_s_how_we_take_back_the_internet, he says at 9:02:
The biggest thing that an Internet company in America can do today, right now, without consulting with lawyers, to protect the rights of users worldwide, is to enable SSL web encryption on every page you visit.
That is why we have converted our first site to pure https, including the HSTS standard, and plan to do the same with all the other sites we operate.




Instructions for implementing HSTS are available at: http://lowendtalk.com/discussion/10021/tutorial-http-strict-transport-security-setup-on-apache-nginx-and-lighttpd

No comments: