HTTP redirects are a common technique to ensure website visitors see the same content when they type different, yet related, domains in the URL bar of their browser. HTTP redirects are also used for transitioning from a standard HTTP site to a secure site using HTTP over Transport Layer Security (TLS), also known as HTTPs. But any connection to an HTTP site comes with risk.
It's generally understood that the difference between HTTP and HTTPs is that the latter encrypts the connection between the browser and the server. However, because HTTPs relies on a chain of trust (known as Public Key Infrastructure, or PKI), it's also used to positively identify the intended website. Identification is as important as encryption, because there's no sense in encrypting data to a website when you don't trust it.
Trust is a critical concept in understanding the redirect chain. With plain HTTP an attacker may be able to trick the user into visiting their malicious website using tactics such as typo-squatting and DNS cache poisoning. In DNS cache poisoning, the attacker takes advantage of vulnerabilities in a DNS server used by the victim to inject a resource record that resolves to the IP address of their own server rather than the server owned by the victim's intended destination.
The victim has no way to validate that the site they arrive at is owned by the intended destination organization, particularly if the fake website does a good job of duplicating the content from the real one. One of the dangers is account takeover, in which the fake site presents a login screen, captures the entered credentials, then passes the connection on to the real site. The victim believes they're interacting directly with the legitimate site, while in reality the attacker is in the communication path—or a Man In The Middle (MITM)—and now has the victim's credentials to the real site. The credentials can be used for several purposes, such as:
- Transferring money, in the case of a banking or cash app site
- Making purchases charged to the victim, in the case of a shopping site
- Reading sensitive emails
- Creating misleading social posts
- Controlling IoT or industrial equipment
TLS mitigates this risk by requiring that a certificate identifying the site is installed on the site itself. The certificate contains the DNS names that are valid for the site, such as bitsight.com, www.bitsight.com, and blog.bitsight.com. The browser compares these names—known as Subject Name and Subject Alternate Names, or SAN—against what was entered in the URL bar and issues a warning to the user if none match. Redirects change the name in the URL bar, and each site along the redirect path that supports HTTPs must match what's currently in the URL bar.
When organizations redirect HTTPs to HTTP, even when there's a second redirection back to an HTTPs site, the client gets a false sense of security that their communication has been encrypted from the initial request through to the final destination. In truth, their connection was routed through a site with no positive identification. This intermediate site is an opportunity for an attacker to become a MITM.
While there is a direct risk—or exposure—to the client in this scenario, it's also a signal about the controlling organization's practices. The first is a lack of understanding of the risk; the second is that there's no good reason to have a double redirect through an intermediate non-TLS site. Both show a gap in governance: a lack of a standard policy, the processes and procedures that support it, as well as assurance that the policy is being followed consistently and universally.
The solution is to avoid HTTP altogether, if possible. While it's understood that redirects are a common practice for transitioning from HTTP to HTTPs sites, organizations should configure redirects from the requested HTTPs site directly to the destination HTTPs site without going through an intermediate non-TLS site. DNS CNAME records can also be used for this purpose, with some situational nuances that are beyond the scope of this explanation. Also note that the technique of redirecting from HTTP to HTTPs will become obsolete once all browsers support HTTPs-First, meaning if a user simply types www.bitsight.com, for example, the browser will first attempt to connect to https://www.bitsight.com and fall back to HTTP if the site doesn't support HTTPs.