Home / Blogs

HTTPS Web Hijacking Goes From Theory to Practice

George Ou

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. More blog posts from George Ou can also be read here.

Related topics: Cyberattack, Cybercrime, DNS, DNS Security, Security, Web, Wireless

WEEKLY WRAP — Get CircleID's Weekly Summary Report by Email:


Repeat "article" jeroen  –  Feb 24, 2009 9:09 AM PDT

Previous post:

and in the mean time nobody cares about it at all anymore anyway:

No big deal. Not so clever. Hamilton  –  Mar 02, 2009 5:02 PM PDT

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,


To post comments, please login or create an account.

Related Blogs

Related News

Explore Topics

Industry Updates – Sponsored Posts

Verisign Q1 2016 DDoS Trends: Attack Activity Increases 111 Percent Year Over Year

Is Your TLD Threat Mitigation Strategy up to Scratch?

Mobile Web Intelligence Report: Bots and Crawlers May Represent up to 50% of Web Traffic

Domain Management Handbook from MarkMonitor

i2Coalition to Host First Ever Smarter Internet Forum

Encrypting Inbound and Outbound Email Connections with PowerMTA

Resilient Cybersecurity: Dealing with On-Premise, Cloud-Based and Hybrid Security Complexities

What Holds Firms Back from Choosing Cloud-Based External DNS?

Verisign Releases Q4 2015 DDoS Trends - DDoS Attack Activity Increasing by 85% Year Over Year

Best Practices from Verizon - Proactively Mitigating Emerging Fraudulent Activities

Neustar Data Identifies Most Popular Times of Year for DDoS Attacks in 2015

The Framework for Resilient Cybersecurity (Webinar)

2015 Trends: Multi-channel, Streaming Media and the Growth of Fraud

DeviceAtlas Brings Device Awareness to HAProxy

Data Volumes and Network Stress to Be Top IoT Concerns

DKIM for ESPs: The Struggle of Living Up to the Ideal

Computerworld Names Afilias' Ram Mohan a Premier 100 Technology Leader

Verisign Mitigates More Attack Activity in Q3 2015 Than Any Other Quarter During Last Two Years

Protect Your Privacy - Opt Out of Public DNS Data Collection

Verisign & Forrester Webinar: Defending Against Cyber Threats in Complex Hybrid-Cloud Environments

Sponsored Topics


DNS Security

Sponsored by


Sponsored by
Afilias - Mobile & Web Services


Sponsored by
Afilias - Mobile & Web Services


Sponsored by