Security researcher Moxie Marlinspike presented a new vector of attack against HTTPS using Man in the Middle (MitM) attacks against SSL web sites, and an updated version of his sslstrip tool (not yet posted), at BlackHat DC.  You can watch the video of his presentation, and there is also an interview with Moxie and BlackHat organizer Jeff Moss.  Although some journalists have gotten the point of his presentation right - such as this article by George Ou -  many have not, and there is a lot of confusion about what Moxie actually presented.  Below I present my analysis of his presentation and what it means to us as security practitioners.

The primary point of his presentation is that HTTPS as implemented relies on HTTP, which of course is an insecure protocol.  When a user types paypal.com into their browser, the browser does a GET request for http://paypal.com, and the server returns a 302 redirect to https://www.paypal.com/us.  The initial use of HTTP allows a man in the middle to strip all references to HTTPS from the response to the user - while still acting as a valid HTTPS client to the server.  This reminds me of one of Gene Spafford's famous quotes:

Secure web servers [cryptographically enabled web servers] are the equivalent of heavy armored cars. The problem is, they are being used to transfer rolls of coins and checks written in crayon by people on park benches to merchants doing business in cardboard boxes from beneath highway bridges. Further, the roads are subject to random detours, anyone with a screwdriver can control the traffic lights, and there are no police.

In other words, Moxie presented a technique that exploits the implicit transitive trust between HTTPS and the related protocols that HTTPS is dependant upon.  Not only does this include the clear-text HTTP and DNS protocols, but numerous others such as TCP, IP, ARP, and layer 1-2 protocols such as IEEE 802.3 and 802.11.

Marcus Ranum is one of the outspoken voices in the industry on the effects of transitive trust (and trust issues in general).  He has an interesting post "AfterBites - 160 Illustrations of Transitive Trust" on the Tenable blog that summarizes his views on the subject.  I also highly recommend listening to the Rear Guard podcast that he references in that article.  In it he does a great job of breaking down the idea of trust in Information Security.

Unfortunately there is very little that a site could do to prevent such a MitM attack.  For example, even if a site operator went so far as offering their site as HTTPS only, with no HTTP fallback (never mind the impact that would have on site traffic), it would still be vulnerable as the attacker could still listen for the initial HTTP request from the browser and still send a 302 redirect even though the site doesn't use 302 redirects.

The same thing goes for browsers - defaulting to HTTPS doesn't help, unless they remove the fallback to HTTP.  As long as the browser is willing to fall back, an attacker would DOS the HTTPS connection.  Obviously removing HTTP fallback isn't a viable option.

So what can be done?  Browsers vendors should bring back user interface indicators (positive indicators) that a site is secure.  Of the major browser vendors, only Google Chrome does a decent job at this - the others have actually removed some of the indicators.  Further, Google Chromium offers a SSL-only browsing mode in the latest Chromium releases.  In this mode Chromium only loads HTTPS sites, and only if there are no certificate errors.  It is my hope that when Google releases this feature in the mainstream Chrome browser, they add a second shortcut on installation by default for Chrome (Secure Browsing Mode) to encourage users to take advantage of this feature.

To take that idea one step further, the browser vendors should offer a HTTPS only site opt in list or mechanism, perhaps similar to Safe Browsing extensions, that enforce HTTPS only for sites that desire that behavior.  It wouldn't do any good to deliver this in real-time through DNS, as a MitM attacker would be able to remove or modify DNS responses as well.  Although there have been some calls that DNSSEC would help, until there is universal acceptance and coverage, it won't help at all.

Finally, it is unclear but likely that client-site certificate validation would help.  By validating client side certificates, web servers can be sure that they are communicating with the end browser, and not a MitM.  However, client side certificates come with a whole host of issues that prevent general acceptance including difficulty for end users and MitM attacks against the enrollment process itself.  Perhaps something could be done with these usability issues to make it a more viable option.

(Originally published 2009-02-23)