Hacker News Reader

Comment by TekMol | Hacker News Reader

Wouldn't it be easier to make the browser use https by default? And then if a domain does norespond to a https request ask the user "There seems to be no secure way to communicate with www.somedomain.com - want to switch to insecure?".

View on HN

Unfortunately, that would break a large number of sites out there. Some serve different content (as in: not what the visitor would be expecting) on HTTPS, many would have mixed content warnings, etc. Just take a look at the ruleset used by the HTTPS Everywhere extension[1] to get a sense for how much of the web would break in weird ways if browsers decided to do this today. This'll happen eventually, but with 50% of page loads using HTTPS, we're not quite there yet.

[1]: https://github.com/EFForg/https-everywhere/tree/master/src/c...

It's tricky: how is a user supposed to distinguish between "this site doesn't support HTTPS at all" and "a MitM is making the HTTPS site slow so I give up and use the HTTP version"?

What if it's their bank and they really need to pay a bill right now? Maybe the HTTPS site is just broken right now.

Users aren't wrong for clicking yes through these dialogs. This kind of UX is setting them up for failure with impossible choices. Its even worse in practice: users (including programmers, as evidenced by the comments in every HN thread about HTTPS) won't understand everything that's in play before making this decision. Assume users always click yes.

HSTS, preloading and restricting new features to HTTPS etc. are ultimately working to deprecate non-HTTP (inside browsers).

Most of what you are saying makes sense, except this bit:

> "Maybe the HTTPS site is just broken right now."

In the case of a bank, it's extremely unlikely that they are falling back to HTTP. It's much more likely that sslstrip is in place if you had this. The cost and hassle of someone having access to your whole bank account, is likely much higher than the fines for a late payment.

I get that, but I most users don't.

Probably won't sit well with website owners. If you attempt to connect over TLS when it isn't supported, there is a performance impact, basically you have to attempt one failed connection for every http request, do that for every request on a page and performance becomes a big problem.

You'll also be going against specs, HTTP should go to port 80( which typically isn't secure.), a browser unilaterally deciding to go against a legitimate user wish is bad form.

When I moved my message board to HTTPS, we had mixed content warnings on avatars. After adding a Content-Security-Policy header to upgrade insecure requests, we found that most sites without HTTPS failed quickly. But five or six people had domains that would "load" for 10+ seconds before finally timing out. Which had the effect of making forum topic pages take 10+ seconds to stop showing the "page loading" animation.

Any site lacking HTTPS should instantly close connection attempts on port 443. But some it seems choose not to respond at all, making the browser unsure if the site is just slow or if an HTTPS service doesn't exist.

Hum... If I explicitly type "http://example.com", then by all means, go to the plaintext site. But everybody just types "example.com" and expects the browser to go to the site - this one should favor the TLS version, not the plaintext one.

Besides, now that most sites run on https, making the http-only ones slower would be a good thing.

I think the current approach of allowing site owners to decide how they're going to support TLS is the right approach, browsers taking it upon themselves to enforce it is a bad idea. Some additional reasons why it is a bad idea have already been mentioned by other folks.

When it comes to security, TLS is crucial to the security infrastructure of the internet as a whole; however most of the current security problems on the internet don't actually involve TLS vulnerabilities, even though those tend to make a lot of news in the technology press.

The bar for exploiting TLS vulnerabilities generally requires setting up a legitimate seeming entity and injecting yourself into the internet traffic routing infrastructure, it is very much possibly (and indeed easy for state actors) but it is a much higher bar for common cyber criminals.

How is defaulting to https instead of http not allowing the site owners to decide?

Currently site owners are not allowed to default into https on first visit. Trying both will give them this choice.

They can decide themselves by 301ing to http and setting some sort of "I'm a crappy website, just use insecure requests" header.

they can't 301 if they don't already support TLS. If you attempt to connect to a site over TLS that doesn't support it, for starters port 443 is not likely to be open. 301 is part of the HTTP protocol, TLS is transport layer.

Reply on news.ycombinator.com