0

Typically, HTTPS redirection happens like this:

  1. The user clicks or types an HTTP link, e.g. http://example.com/url.
  2. If the browser has seen a Permanent (301) redirect to HTTPS for that exact URL, it follows it, skipping steps 4 and 5.
  3. The browser does a DNS lookup for example.com (if not already cached).
  4. The browser connects to example.com's on port 80, and requests /url over HTTP.
  5. The example.com HTTP server responds with a redirect to https://example.com/url
  6. The browser connects to example.com on port 443 and requests the /url again over HTTPS.

Steps 4 and 5 are not only inefficient, but pose at least two security problems:

  1. The user's request is sent in cleartext, and easily viewable by any intermediate parties
  2. A man in the middle can easily spoof the example.com HTTP server, and could force a permanent redirect to a malicious site, or just serve malicious content over the HTTP - e.g. a form that harvests login details.

If there were a mechanism on the DNS level, then the typical process could look like this:

  1. The user clicks or types an HTTP link, e.g. http://example.com/url.
  2. If not already cached, the browser does a DNS lookup for the IP address of example.com, and also checks a DNS record to discover that the domain has identified as HTTPS only.
  3. The browser connects to example.com on port 443 and requests /url over HTTPS.

You could imagine the DNS record itself could be something quite powerful that perhaps blacklists/whitelists particular paths, or it could just be a simple yes/no flag.

(Browser support would of course not be universal to start with, so for some time the HTTP server would still be needed to continue serving redirects.)

This new method might still be subject to any DNS vulnerabilities, but a DNS lookup is still needed for the IP address, which is the bigger vulnerability. So I would consider this method to be strongly more secure than the current method.

To my knowledge, there has been no initiative on the part of big web companies or browser manufacturers to support such a mechanism.

Why is this? Or if there has been, what became of it?

7
  • DNSSEC and DANE come close to solving this. See my conversation with Steffen Ullrich at security.stackexchange.com/questions/179122/… about this. – mti2935 Oct 3 '20 at 12:50
  • 3
    HSTS preload lists are another way of solving this problem. If a site is on the list, and the user requests the site via http, the browser will automatically upgrade the protocol to https. This eliminates the initial http request by the browser, followed by the site responding with a 301 or 302 redirect to https, and therefore eliminates the possibility of the attacker intercepting the initial http request by the browser. Most modern browsers support HSTS preload lists nowadays. See hstspreload.org. – mti2935 Oct 3 '20 at 13:32
  • 2
    Why do you insist that the mechanism should be on the DNS level? Other ways would be to default to HTTPS instead of HTTP in the browser. – Steffen Ullrich Oct 3 '20 at 15:38
  • 2
    @KamilKurzynowski: DNSSEC doesn't offer any privacy: it's for integrity and authenticity of the records. – Esa Jokinen Oct 3 '20 at 19:22
  • 1
    Unsecured DNS lookup of the address is not vulnerable (except denial) if you use SSL/TLS (e.g. HSTS preload) correctly (including cert validation) and CAs issue certs properly. Tampered DNS can send your TCP to the wrong host, and even secure DNS can do so if IP routing is hacked which it often is (see BGP), but in both cases SSL/TLS prevents any failure of confidentiality or integrity. – dave_thompson_085 Oct 4 '20 at 3:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.