CODEWITHSUNDEEP
apachehttpsecurityhttps
Eria
Eria

Reputation: 3172

Redirect HTTP to HTTPS or deny usage of HTTP?

Configuring on Apache HTTPD server, many articles on the web advise to enforce HTTPS protocol by redirecting (permanently) all HTTP request to HTTPS.

Below is what I understand is happening when a user tries to reach a server supporting both HTTP and HTTPS :

  1. Client's user agent (web browser for example, but not only) sends a request to http://my.domain.com.
  2. Server receives request on port 80, and sends a permanent redirection (code 301) to https://my.domain.com.
  3. Client's user agent receives the response. Given the status code, it sends the same request to https://my.domain.com.
  4. Server receives request on port 443 and sends back the wanted content.

So, if the request contains sensitive data, between steps 1 and 2, a man-in-the-middle could recover it, non-ciphered, in the request.

If the client uses a web browser, this browser keeps in cache the 301 redirection, and the next time the client send a request using HTTP, it will automatically send it using HTTPS instead.

But, what if the client clears the cache often ? Or use another user agent than a web browser, which does not store the permanent redirection ? Don't we lose the benefit of HTTPS here ?

A concrete example : a REST API, and the requests contain sensitive data. This API can be called from any HTTP client (online, embed in a software or website, standalone).

In this case, could it be better to just disable HTTP support on server level in order to enforce the use of HTTPS ?

Edit 2017-11-14:

sys0dm1n told me about HSTS below. But the security provided by this mechanism depends entirely on the user agent's compliance to the specification.

Edit 2017-11-15:

I edit my post after the first answers I receive, to precise my concern.

Upvotes: 3

Views: 4294

Answers (2)

Kjartan
Kjartan

Reputation: 19071

"Would disabling http entirely help?"

It probably would. I'm updating and changing my answer from 2017, because as user kamilz points out in the comments below, I was clearly to hasty, and drew the wrong conclusion. To quote Kamilz:

If the destination server is known but it doesn't listen on port 80 (or port 80 is blocked), TCP handshake should fail and still no HTTP data would be sent over the wire. If it listens on 80, it will accept TCP connection and data would be send over the wire in the plaintext.

That makes sense, of course. So why could I see the sensitive data in the pictures below? Kamilz explains that too:

Fiddler acts as a web proxy and that's why it is able to see original request.

That data is simply not sent yet - it was still on my machine, and no DNS lookup had yet been performed. At some point after having passed through Fiddler, the DNS lookup would have been performed, but no valid IP address would have been found1, and since there would be no valid IP, there would be no place to send the content at all.

(1. That is, assuming nobody registers the address http://somefakeurlthatdoesnotexistanywhare.com, with my silly spelling error and all).

Previous, incorrect answer

For context, here's my original answer (who knows, it might even be enlightening, and help others avoid drawing the same false conclusion):

No, I don't think it would, and here`s why: Presumably, your client / browser does not know if a site running http exists before a request is sent. Sure, it will receive an error code like 404 or something similar, but at that point, the original request will already have been sent over the wire, and any "man in the middle" may well have been able to observe that request.

As a simple illustration of the problem, here's a call to a fake http-url, made from Postman, an caught in Fiddler. As you can see, a 502 error is returned, but the original request still contained the sensitive data.

enter image description here

Now just for a comparison, if I do the same, but just change the url to https instead, I get a different result in Fiddler:

enter image description here

This tries to set up a tunnel, and does not reveal any of the post-data.

So in conclusion, your best option is probably to enable HSTS and get your site on the HSTS preload list, which should stop any HTTP-request from being sent to begin with (at least for recent versions of most major browsers).

Upvotes: 3

sys0dm1n
sys0dm1n

Reputation: 879

To make sure always your website is using https for security, one way is to enable HSTS

Automatically turn any insecure links referencing the web application into secure links.

To enable it, you need to add a header in your vHost configuration:

Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains;"

Make sure the Header module is enabled.

You can follow the instruction here and add your domain for inclusion in Chrome's HTTP Strict Transport Security (HSTS) preload list.

This is a list of sites that are hardcoded into Chrome as being HTTPS only.

Upvotes: 4

Related Questions