Home / Blogs

HTTPS Web Hijacking Goes From Theory to Practice

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.

By George Ou, Policy Director - Digital Society

Filed Under


Repeat "article" jeroen  –  Feb 24, 2009 4:09 PM
No big deal. Not so clever. Hamilton  –  Mar 3, 2009 12:02 AM

Not an original ideia of Moxie Marlinspike himself. Actually you can implement the same trick using a Reverse Proxy (locally) and launching your MITM attack using ARP spoof to fool the victims machine into thinking you are the local gateway.

Keep in touch,

.(JavaScript must be enabled to view this email address)

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



Brand Protection

Sponsored byCSC

Threat Intelligence

Sponsored byWhoisXML API


Sponsored byDNIB.com

IPv4 Markets

Sponsored byIPv4.Global

New TLDs

Sponsored byRadix

Domain Names

Sponsored byVerisign


Sponsored byVerisign