Your website only has TCP 443 open and has a bulletproof TLS configuration. I hear you scream that I cannot middle your users to exploit them! On the surface of it you are correct. Let me lay out some basics, explain how we got here, and then show you that you are incorrect. We can middle your users (but it is unlikely).

Laying the basics about HTTP and HTTPS

The default port of the Internet is TCP 80 which is where requests prefixed with “http://” will go. This is a plain-text protocol and offers neither confidentiality or integrity of data being sent between the client and server.

The default port for the “https://” protocol is TCP 443. This is an encrypted protocol with the “s” meaning “secure”.

As the Internet matured it became apparent that pretty much every request needed to be secured. An attacker using man-in-the-middle techniques can easily subvert plain-text communication channels. Any personal information being exchanged would be theirs to steal. They would also be able to alter server replies to serve either phishing or malware payloads straight into their victim’s browser.

This opened up a front in the cyber war to force encryption for every connection.

Question: What … all of them?

Answer:

Redirect to secure!

A common strategy has been to leave both TCP 80 and 443 open but to configure a redirect from 80 to 443. Any request over plain-text (http://) is immediately redirected to the secure site (https://).

The problem with this strategy is that the victim’s web browser will issue a plain-text request. If that attacker was there when they did this, then they could still compromise the victim. It only takes a single plain-text request and response to enable them to do so.

Only offer secure

To get around this savvy administrators make no compromises and simply disable TCP port 80. If a web browser attempts an “http://” request the port simply is not open. It cannot establish a TCP session and so will not send the plain-text HTTP request.

The downside of this is that the user might assume the target application is not online. They would go and try and find another domain to buy whatever it was they wanted. This is why redirecting to secure has been such a pervasive strategy. Vendors simply do not want to lose out on important traffic which can drive this quarter’s sales chart.

What is this HTTPS Strict Transport Security (HSTS) stuff?

You can learn more about HSTS here:

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security

My understanding is that HSTS was created to reduce the number of plain-text HTTP requests being issued. There are two modes of operation:

1. A URL is added to a preload list which is then available to modern web browsers.
2. An HTTP header (Strict-Transport-Security) is added to server responses which tells the web browser to redirect all “http://” to “https://” before issuing the request.

When a user types a URL into the address bar and hits enter the browser will check to see if the redirection must happen. Where required the redirect happens in memory on the user’s computer BEFORE the TCP connection is established.

For strategy 1. the target site is in the preload list. A well behaved web browser will never issue a single “http://” request to the target site. The problem of middling the connection has been successfully resolved.

For strategy 2. we are arguably no better than the server redirecting from “http://” to “https://“. A single plain-text request will be issued. If the attacker is middling at that point they can alter the response as desired to exploit users.

However, strategy 2. is likely to lead to fewer plain-text requests overall since the browser will not request via “http://” until after an expiry date. Relying on “redirect to secure” alone will result in a single plain-text request per visit the user makes to the site. This increases the number of opportunities to middle the victim’s connection.

Gap Analysis

The reason for writing this blog was because I had an interesting conversation with a customer. They enabled only TCP 443 (https://). They saw this as sufficient and did not want to enable HSTS as recommended in my report. I was challenged to show an exploit route that could work or they would not bother.

Fortunately the edge case I am about to explain has been public knowledge for a long time. So I didn’t have to think too hard to add it in. I am just adding my voice to bounce that beach ball up again for visibility.

Exploit Steps

The exploit route is like this:

1. An attacker must be able to middle the victim’s traffic.
   • Chances are this is on the same network as the victim.
   • For this reason mass exploitation of users is unlikely and the risk is small as a result.
   • Lets proceed with the steps assuming that this attacker is ABSOLUTELY DETERMINED to exploit this one person.
2. An attacker crafts a link and sends it to the victim to click on.
   • That link is: http://target:443.
3. The victim clicks on the link and their browser dutifully establishes a TCP connection to port 443. Because the browser sees a service it can talk to it fires a plain-text “http://” connection.
4. The server then rejects the connection because it is expecting “https://“. However, the damage had already been done. Our attacker had the single request that they needed for exploitation to occur.

The following screenshot shows the Wireshark capture when this example URL was requested:

URL: http://www.cornerpirate.com:443

The only requirement for this to work is that the targeted TCP port is open. It is most likely that 443 is used but you can do the same thing with any open TCP port.

What is the solution?

The optimal solution is to enable HSTS via the preload method. Even if your website only has HTTPS enabled.

Adding a site to the preload list can done here:

• https://hstspreload.org

All other solutions leave a victim’s web browser issuing at least a single HTTP request.

Unfortunately it takes time for a site to be added to the preload list. Therefore at the same time you should also enable the “Strict-Transport-Security” header as described:

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security

That is the famous belt and braces manoeuvre to reduce the chances of the world seeing you butt.

And you should definitely do as I say and not as I do:

Hope that helps