I got asked a question… this gives me a chance to write an opinion. I have lots of them!
If I redirect my port 80 traffic to another site, do I need to get a TLS cert?
The question here is related to if a bank (or other service) has changed
their name, then do they still need to maintain a TLS site for the old
name? Can’t they just have http://mybank.com send a redirect to https://newbankname.com and be done with it?
Why do we use TLS?
There are a number of reasons that we use TLS connections over the internet (including, but not limited to):
- Confidentiality - the data transferred can’t be seen by any person in the middle because it’s encrypted
- Identity - the TLS certificate tells you that you are talking the website you think you are
- Integrity - the data hasn’t changed in transit.
All of these are good security features. Even supposed “good guys” may abuse non-TLS connections. For example, in 2015, AT&T inserted adverts into traffic through their hotspots. In 2014 Verizon added tracking cookies to their mobile traffic. Both of these took advantage of the lack of Integrity and Confidentiality in the non-TLS connections.
Stub server
So, typically, we don’t serve websites over HTTP on port 80, but use HTTPS on port 443. However there is sometimes a “stub” left on port 80 to redirect. And this stub isn’t always that good.
For example, the browser might say “Hi, I want to go to
http://mybank.com”, and it will make the port 80 connection, and the
server will say “OK, really, go to https://www.mybank.com” or sometimes
even “Yeah, we’ve changed names; go to https://www.newbank.com”.
And now all the traffic is on port 443 and we’re good. Right? Well,
not so much…
Where can this go wrong?
An attacker can look at that initial port 80 request, and change it. Let’s look at those three reasons listed above and see how the bad guy can abuse this
Confidentiality - this isn’t so big a deal. The initial request your browser sends to the server and the response might be visible to the attacker, but they can’t see anything beyond that.
Identity - now we’re getting somewhere. With HTTP you don’t know the server you’re talking to is the server you think you’re talking to. The attacker could have redirected traffic to their own machine. Now when you ask for
http://mybank.comyour browser may get the response “OK, go tohttps://mybankk.com”. Notice the extra k? If you’re not observant then you may not notice anything different. It’ll even be over TLS with a nice certificate, for mybankk.com, so your browser happily puts up the lock icon. So now you’ll enter your bank login details onto a rogue server… and the bad guy steals all your money.Integrity - here’s also a fun one. Your browser sends the initial request and the server sends the response, but the bad guy changes the information so that it, again, reads mybankk. As far as the browser is concerned that’s a good reply and you’ll be redirected to the bad site. (This is basically how AT&T injected their ads, how Verizon added tracking).
How can these attacks happen?
It depends on your situation. Let’s say you’re sitting in Starbucks using their free WiFi… well, are you? Or are you using an attacker’s hotspot that looks like Starbucks, but isn’t. They can steal your unencrypted traffic and so redirect you to their bad site. If you’re at home, is your home router secure? Or has it been broken into? A number of home routers have known weaknesses (backdoors, default passwords, etc) which could let an attacker perform that integrity attack. Or even if your home router is good or you are on a good Starbucks server, the attack may have been able to steal network routes (BGP attack) or hijack DNS so that your browser goes to the bad server. There will be other attack vectors; I just listed a few.
I’ve previously written some blog posts on this:
These aren’t attacks on you; they just looking for traffic going to mybank.com. You just end up being a victim.
So what can we, as the website owner, do about this?
Firstly, if you are using a domain (e.g. www.mybank.com) then you MUST
have a TLS version of the site available. This TLS version must set the
Strict-Transport-Security header on the https connection. Now, after
the first time a person goes to a website the browser will remember “Hey,
I should always go to the HTTPS version” and will not try port 80 again.
This really reduces the scope of the attacks listed because if you’ve
already visited the bank before then your browser already knows to avoid
port 80.
BUT: This only works for the same domain name (and potentially
subdomains), so if you have https://newbank.com set the header then
this will not protect http://mybank.com because it’s a different name.
That means that every name needs to have the https version of the name
also created (with its own Strict-Transport-Security header), and so
have a TLS certificate. Without that the browser will always go to the
port 80 version of the site when requested, and be subject to the attack
scenarios listed.
Even if you, yourself, do not run a port 80 version of your website you still must have the 443 TLS version with this header, because the previously discussed bad guy doesn’t need you to have port 80 open; they can direct traffic to their own server!
Corporate Application Security standards should require the header to be in place and check for it with DAST scans. If you’re not checking this header as a matter of course then start doing so!
Now make sure any redirect you do from http to https stays within
the domain. So if you want to go from http://www.mybank.com to
https://www.newbank.com then you need two steps:
http://www.mybank.comtohttps://www.mybank.comhttps://www.mybank.comtohttps://www.newbank.com
If you miss that middle step then the Strict-Transport-Security header
won’t protect the initial site!
If you want to get more advanced, once you have the TLS certs in place then you can request it gets preloaded into Chrome and other browsers. Basically your URL gets encoded into the browser so when you go to a site then the browser will always try https!
Note that some browsers are experimenting with “https first” designs to help protect people from these types of problems. However, as the website owner you can’t rely on this.
Summary
So to cut a long story short (too late!) that simple redirect on port 80
may be causing more headaches than you think. It definitely opens up
some vulnerabilities which, if exploited, would probably get yourself
into the press. The mitigation listed (Strict-Transport-Security)
requires a TLS certificate for each domain. Even if you close port 80
you’ll still need to have a TLS server on 443.
Yes, keeping www.mybank.com open to redirect to www.newbank.com turns
out to be more complicated than just a simple redirect!
As an aside, from a pure market perspective, if I ever saw my bank do a redirect on port 80 to another domain then I’d close my account ASAP!