Why do browsers not give precendence to encrypted (HTTPS) traffic by default?
buffermet opened this issue · 13 comments
Please correct me if I'm wrong, but I don't see why the HSTS preload list is necessary.
Why don't browsers give precedence to encrypted (HTTPS) traffic rather than unencrypted (HTTP) traffic?
In my eyes, HTTPS Everywhere does this job for you, and does it better.
Does it not make sense to first try to perform a successful TLS handshake before switching to an unencrypted protocol?
Thanks
May I add that the answers given to a similar question found on stackexchange are excuses rather than solid reasons.
A single misconfigured website is NOT a reason to default to unencrypted traffic for all websites that are not on the HSTS preload list.
If a website is not configured correctly, that's on them. It should not go at the expense of users' privacy/security.
An initial HTTP request is enough for an attacker to spoof the TLS connection. So whether the user is a first time visitor, or happens to have cleared their browsing history, they are just as vulnerable to phishing attacks. Redirecting HTTP requests to HTTPS just isn't safe, and it requires one to blindly trust all nodes in the route to not tamper with the request/response packets.
There are FAR MORE websites not HSTS preloaded than there are misconfigured TLS servers.
I must correct myself for having suggested that the HSTS preload list is redundant. It is not, it is in fact essential.
I understand that an attacker could simply block HTTPS requests and force the user to downgrade to HTTP, but why not try first anyway? This would make HSTS far more effective, in that a user accessing a site which previously served a Strict-Transport-Security header (with a valid max-age) should no longer be accessible via HTTP unless the user consciously chooses to do so.
If a host is on the HSTS preload list, then the browser should not allow HTTP requests for this host until the max-age timed out. But if the host is not on the preload list, it should first try HTTPS before falling back to HTTP. I think that is basic security hygiene.
Better practice could be to request Certificate Authorities whether there is a valid certificate for a host after failing to start/complete a TLS handshake. If the answer is yes, the user should wait until the requested host's TLS server is back up/not MITMed.
People are thinking about how to default to HTTPS in browsers, but we're still a while away from that.
If a host is on the HSTS preload list, then the browser should not allow HTTP requests for this host until the max-age timed out.
One important feature of HSTS is that the browser must never downgrade to HTTP for an HSTS host.
There has been discussion of an "HSTS lite" mode, but it's probably a better use of effort to try default to HTTPS like in the bug I linked above.
Better practice could be to request Certificate Authorities whether there is a valid certificate for a host after failing to start/complete a TLS handshake. If the answer is yes, the user should wait until the requested host's TLS server is back up/not MITMed.
Unfortunately, there are a few problems with this.
- The browser would need to know whom to contact to know if there is a valid certificate
- It adds extra latency.
- There are all sorts of funky networks that might block these probing connections.
The most performant thing would be to have the data ready on the client side. And since the browser can't know ahead of time which certificate authority has issued a certificate for a site, the simplest would be to store just a bit indicating that the site must have some valid certificate. But that's just the HSTS preload list. ;-)
I did write up a document exploring ways to move some of the preload checks to servers on the web, but that is probably still not worth the extra engineering effort at this point.
I'll close this bug since it's not actionable for the website repository, but you're welcome to start a discussion at https://groups.google.com/a/chromium.org/forum/#!forum/hsts-discuss . I'm also happy to give you more information if you want to know what kinds of approaches have been tried (and why they're not in use).
Hi @lgarron, thanks for your reply.
People are thinking about how to default to HTTPS in browsers, but we're still a while away from that.
I don't think easter egg gestures is the right way to go either, but that is not what I suggested.
One important feature of HSTS is that the browser must never downgrade to HTTP for an HSTS host.
It definitely shouldn't, but unfortunately this is not the case for hosts not on the HSTS preload list when a user clears the browser history (even when the host's HSTS headers are set correctly).
Unfortunately, there are a few problems with this.
- The browser would need to know whom to contact to know if there is a valid certificate
- It adds extra latency.
- There are all sorts of funky networks that might block these probing connections.
- True (see my following comment)
This is already the case. And this is the exact purpose of Certificate Authorities. - I really don't mind if it improves security, I think everyone can agree.
- Simple solution: the browser sends asynchronous requests to multiple different CAs, if one of them says there is a valid cert, then a SSL connection must be established. Otherwise no go. If the CA holds an old/invalid record of a host's certificate, they will be notified if the user can't establish a TLS handshake (so they can update records if necessary). If there is a valid certificate but the TLS handshake is not possible, you can know with confidence that you are either being MITMed, or the SSL server is down. These are very strong reasons not to commence an unencrypted connection.
Thanks again for your response and I am definitely checking out the links you provided.
Just to add to your comment indicating that we don't know beforehand what CA issued the certificate: I am sure these organisations are more than capable of keeping a record of which host has a current certificate or not. But if that's not the case then it is probably for a good reason (hopefully).
Thanks for clarifying.
Certificate Authorities have to be in communication with each other to avoid issuing multiple certificates for the same host. So my previous comment seems to be a necessity.
And simply to account for phishers that are watching (not manipulating) traffic, it seems good practice to first try to establish a TLS handshake. I still think this is the right way to go.
There are a few concerns I could bring up, but I'll focus on these three:
- Creating a system that requires certificate authorities to cooperate is really hard. Certificate transparency is just barely becoming sustainable, after many years of effort.
- Whomever the browser would contact to find the valid certificate would learn your browsing history. This can partially be solved by running the system over DNS, but it also requires being able to authenticate the DNS records. Attempts to build DNS-based systems like this have historically not been successful.
- Latency is a huge issue for many users, and cannot be dismissed without a lot of careful consideration. The latency of an extra round-trip in the average case for a first-world user on a good WiFi connection might be small enough not to notice, but that's only a small number of users some of the time. In addition, if there is a hiccup then the latency might easily be 30 seconds, multiple minutes, or "forever".
However, we can certainly improve on the status quo. I definitely recommend reading up on certificate transparency to learn what aspects it can (and can't) help with.
Also, there are some things you can do if you're willing to inconvenience yourself to limit the risk of HTTP browsing. Here's how I approach it:
- Install HTTPS Everywhere.
- Disable Javascript for all HTTP sites by default.
- Install Ugly HTTP (which I wrote) so that I notice HTTP sites at a glance as soon as they load.
I understand that the internet is a work in progress and I'm glad that measures like the HSTS preload list are in place.
Thanks @lgarron for your time and elaborate responses.
@lgarron I have given this second thought and have come to the conclusion that all the aforementioned excuses not to give precedence (or simply completely abandon HTTP) are bogus.
- Attackers can already block TLS traffic if they like, so allowing HTTP is not a solution to this problem.
- If everyone knew the potential outcome of running injectable code (JavaScript, HTML, CSS, ...) on their machine, on a daily basis, they would quickly vote for a ban on HTTP.
- Latency wouldn't be an issue if everything had TLS to begin with...
It's inexcusable to allow this to happen, if a host is too lazy to implement the bare minimum of security measures (HTTPS), why do they even deserve a single visitor? They sure aren't important websites, and if they are (ie. handling personal information), they should be the last to be served over plaintext.