Home / Blogs

HTTPS Web Hijacking Goes From Theory to Practice

Don't miss a thing – sign up for CircleID Weekly Wrap newsletter delivered to your inbox once a week.
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



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

Sponsored Topics

Promoted Posts

Now Is the Time for .eco

.eco launches globally at 16:00 UTC on April 25, 2017, when domains will be available on a first-come, first-serve basis. .eco is for businesses, non-profits and people committed to positive change for the planet. See list of registrars offering .eco more»

Boston Ivy Gets Competitive With Its TLDs, Offers Registrars New Wholesale Pricing

With a mission to make its top-level domains available to the broadest market possible, Boston Ivy has permanently reduced its registration, renewal and transfer prices for .Broker, .Forex, .Markets and .Trading. more»

Industry Updates – Sponsored Posts

Leading Internet Associations Strengthen Cooperation

Global Domain Name Registrations Reach 329.3 Million, 2.3 Million Growth in Last Quarter of 2016

DeviceAtlas' Deep Device Intelligence Now Addresses Native App Environment

A Look at How the New .SPACE TLD Has Performed Over the Past 2 Years

Verisign Releases Q4 2016 DDoS Trends Report: 167% Increase in Average Peak Attack from 2015 to 2016

Neustar to be Acquired by Private Investment Group Led by Golden Gate Capital

Verisign Q3 2016 DDoS Trends Report: User Datagram Protocol (UDP) Flood Attacks Continue to Dominate

2016 U.S. Election: An Internet Forecast

Government Guidance for Email Authentication Has Arrived in USA and UK

ValiMail Raises $12M for Its Email Authentication Service

Don't Gamble With Your DNS

Why .com is the Venture Capital Community's Power Player

Defending Against Layer 7 DDoS Attacks

Understanding the Risks of the Dark Web

New TLD? Make Sure It's Secure

Verisign Releases Q2 2016 DDoS Trends Report - Layer 7 DDoS Attacks a Growing Trend

Miss.Africa Announces 2016, Round II Seed Funding Tech Initiative for Women in Africa

How Savvy DDoS Attackers Are Using DNSSEC Against Us

Airpush Chooses DeviceAtlas to Provide Device Awareness to Mobile Ad Network

DeviceAtlas Releases Q2 2016 Mobile Web Intelligence Report, Apple Loses Browsing Market Share