I’ve been privately talking about the theoretical dangers of HTTPS hacking with the developers of a major web browser since 2006 and earlier last month, I published my warnings about HTTPS web hacking along with a proposed solution. A week later, Google partially implemented some of my recommendations in an early Alpha version of their Chrome 2.0 browser by implementing a client-side list of websites that should only operate in secure HTTPS mode regardless of any redirection trickery. This week at the Black Hat security conference in Washington DC, Moxie Marlinspike released a tool called SSL Strip which exploits the weak manner in which SSL is implemented in HTTPS (PDF presentation from Black Hat) which means the vulnerability is no longer just theoretical. Since this issue is fairly complex, I’ll try to summarize it in a nutshell in this article.

The problems with HTTPS

Web browsers always start off using HTTP which has zero security. No one actually manually types in “HTTPS” or “HTTP” and they generally just type “gmail.com” for example and expect the web browser to magically re-route them to a secure sign-in. Unfortunately, that relies on a mechanism that redirects the user from an insecure HTTP page to a secure HTTPS page. Yet this redirect can easily be blocked by a hostile man-in-the-middle which is exactly what SSL Strip does. This means the user never gets taken to the secure authentication page leaving their username and password in the clear for the hijacker to see and take.

The user could in theory recognize that they were not redirected to a secure website and the web browser could even try to give the user positive feedback about a secure website with icons like a padlock or light up the address bar green or some other color, but nearly all end users ignore these signs. That means in practice, relying on people to ensure their own security and safety will almost always result in failure.

It is time we think outside the box beyond ineffective positive or negative feedback systems and do this seamlessly and automatically for the end user. When we think about all other implementations of SSL such as SSLVPN or Outlook email over SSL, we don’t expect end users to make security decisions on what a digital certificate should look like whether there should be one at all. To do this for the HTTPS web browser implementation of SSL is simply a way of shifting the IT responsibility to the end user which not only poses undue burden on the end user, but almost certainly ensures that the wrong security decision will be made.

How to make HTTPS secure

There needs to be an automated mechanism that ensures the end user’s security which requires zero knowledge or participation from the end user to work. We can create such a secure mechanism with minor changes to DNS and web browsers. First, we use DNS to publish a list of websites that must operate in HTTPS through custom DNS records. Second, the web browser will automatically force a connection to an HTTPS page if instructed to do so by DNS and it will maintain a list of websites that are only to operate in secure HTTPS mode. We do this second part because we cannot always assume that DNS is trustworthy especially in the case of wireless hotspots. The DNS mechanism would only work as a toggle on to force HTTPS for all future web browsing sessions but it would not be permitted to toggle off HTTPS unless it was a trustworthy DNSSEC server. This means that once a user successfully visits a secure website for the first time, they will always remain secure for that website even if they cannot trust the DNS server they’re using on public wireless hotspots.

However, this leaves open the possibility that a user in an untrusted network with a hostile DNS server might connect to a new website they’ve never connected to before in an insecure manner. This is a relatively small vector of attack with a very small window of opportunity for success, but this too could be mitigated to a certain extent. Web browsers could come with a pre-populated list of HTTPS-only websites, but maintaining a list of every website in the world would be difficult. However, we could at least cover all the major sites like Gmail, Hotmail, and every online banking and shopping establishment. We could also mitigate this problem with DNSSEC if the end user was hard coded to a trusted DNSSEC server, but this would be difficult to manage and the mechanism wouldn’t work if the malicious wireless hotspot blocked off all access to external DNS or DNSSEC servers.

The bottom line is that if we can lock down 99% of the secure websites that people are likely to visit, we can minimize the danger of stolen user credentials and security breaches. Now that there is a real and tangible threat to HTTPS in the form of a tool like SSL Strip that hijacks any HTTPS website, the time to act on these recommendations for securing HTTPS is now. We need leadership from Microsoft, Mozilla, Apple, and Google today to secure the most important application on the Internet today. Google has already made some strides with a partial implementation, but we need a full implementation of these recommendations and we need everyone to jump on board.