HTTPS and HSTS

Why some (major) HTTPS websites cannot easily intercepted

This Wiki page is intended to answer a question, that is raised with increasing frequency.

The issue

Ettercap has three possiblities to try to sneak into HTTPS secured websites

1. HTTPS interception (should dedicate a Wiki page for that as well)
2. HTTPS stripping (sslstrip plugin)
3. DNS spoofing and redirection to an own webserver

The problem is, that with some (and especially the famous ones) none of those techniques work except if one condition can be satisfied:

>>>> Present the browser with a valid certificate for the requested DNS name! <<<<

But that isn't easy in public, since it may be hard to convince a accepted CA issuing a certificate where you cannot prove that you're not the true owner of the domain and website. An exception to that, are Enterprises that are maintaining an own internal PKI their own clients/browsers (have to) trust.

Background

There are multiple enhancement standards that have been developed and experience a increasing adoption rate, whose target is to make a SSL interception for MITM impossible or at least very hard:

• HTTP Strict Transport Security, a.k.a. HSTS (defined in RFC6797)
• HTTP Public Key Pinning a.k.a. HPKP (defined in RFC7469)
• DNS-based Authentication of Name Entities a.k.a. DANE (RFC6698 and RFC7671)

In this Wiki page, I'm just focussing on the first - HSTS, since this is the most case of the described issue.

The goal of HSTS is, that administrators of a secure webserver have a way to instruct the client (browser) to only use HTTPS for future connections. It provides a way to signal the browser through special HTTP response headers, that for a certain life-time, browsers must apply security (HTTPS). Even when the user types in the addressbar http://www.website.com, the browser internally makes the http:// to https://.

Another important part of the concept is the no-user-recourse. What's meant by that is, that the browser forbids the user to circumvent the security warning in case of a invalid certificate. It will not be possible for the user, to "add" or "accept" a exception. That means, if you cannot provide a valid certificate to the browser that has been instructed for HSTS, TLS handshake won't ever complete.

You may seen two issues with that.

1. The browser must support this standard, but only very old and unpopular browsers do not yet support this.
2. The first attempt using HTTP trying to redirect to HTTPS and signaling the HSTS HTTP header is the weakness. If you are able to intercept this moment, HSTS isn't yet effctive, and user-recourse is still possible.

But there is a little caveat with that:

The most famous browser maintain a build-in list of domain-names that are considered for HSTS by default. You guess what:

• facebook.com
• youtube.com
• google.com
• many others

Conclusion

1. HTTPS interception

If the browser doesn't allow for user-recourse, the browser forbids to proceed (if the intercepted HTTPS stream presents a self-signed or just untrusted certificate). The only way around this is to on-demand sign by a CA-certificate that the browser trusts. This can be provided to ettercap using the --certificate and --private-key parameter.

2. HTTPS stripping

This plugin relies on HTTP connections, to suppress attempts to upgrade to HTTPS through links or redirects. However, once a browser is briefed for HSTS or build-in, the browser never attempts to open a connection using HTTP - it will attempt HTTPS only.

3. DNS spoofing

DNS spoofing acts on a different stage. Spoofing the forged DNS reply most probably works out, but if your fake webserver isn't able to present a certificate that the browser trust, you're back with number 1.

Look ahead

I've not yet found a reliable way to circumvent this. Let me know when you have an idea.