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:

Comments

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

Previous post:
http://www.circleid.com/posts/20090105_problem_with_https_ssl_md5/

and in the mean time nobody cares about it at all anymore anyway:
https://media.blackhat.com/bh-dc-09/video/Marlinspike/blackhat-dc-09-marlinspike-slide.mov

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,

2600@bol.com.br

To post comments, please login or create an account.

Related Blogs

Related News

Topics

Industry Updates – Sponsored Posts

.nyc Goes Public to Brand the Big Apple

3 Questions to Ask Your DNS Host About DDoS

Introducing Our Special Edition Managed DNS Service for Top-Level Domain Operators

Afilias Partners With Internet Society to Sponsor Deploy360 ION Conference Series Through 2016

Neustar to Build Multiple Tbps DDoS Mitigation Platform

Mobile Web Traffic: A Dive Into the Data

The Latest Internet Plague: Random Subdomain Attacks

Digging Deep Into DNS Data Discloses Damaging Domains

New gTLDs and Best Practices for Domain Management Policies (Video)

Nominum Announces Future Ready DNS

New from Verisign Labs - Measuring Privacy Disclosures in URL Query Strings

Four Reasons to Move from .COM to Your .BRAND Domain

DotConnectAfrica Delegates Attend the Kenya Internet Governance Forum

Dot Brand: Why Your Brand Needs Its Own Top-Level Domain

3 Questions to Ask Your DNS Host about Lowering DDoS Risks

Continuing to Work in the Public Interest

Verisign Named to the OTA's 2014 Online Trust Honor Roll

4 Minutes Vs. 4 Hours: A Responder Explains Emergency DDoS Mitigation

Dyn Acquires Internet Intelligence Company, Renesys

Tips to Address New FFIEC DDoS Requirements

Sponsored Topics

Minds + Machines

Top-Level Domains

Sponsored by
Minds + Machines
Afilias

DNS Security

Sponsored by
Afilias
Verisign

Security

Sponsored by
Verisign
dotMobi

Mobile

Sponsored by
dotMobi