"For sites that don’t yet support HTTPS, Chrome will fall back to HTTP when the HTTPS attempt fails."

MITM is still an issue. At some point I hope browsers can switch to "you have to type http:// if you want HTTP", and this is a step in that direction.

(Disclosure: I work for Google, speaking only for myself)

I'm curious if that includes falling back to HTTP when HTTPS has worked in the past.

I only ask because I'm curious what this will do with captive portal nonsense.

I've found http://neverssl.com very helpful for captive portals. It does what you'd expect - hosts a HTTP-only page that allows captive portals to work correctly.

Since it's only ever HTTP, it sidesteps the certificate errors or HTTP downgrades that normal sites are hit with during captive portal interception.

I am curious what happens to captive portals as HTTPS adoption rises. Some OS's (Android, OSX) already detect captive portals and launch a lightweight webview.

Yep, I use neverssl.com, when I remember it. Though, mostly I use example.com, since that works without SSL as well. I guess now I'll need to remember to type http://example.com .

Based off my experience, more and more captive portals appear to be letting the requests the OS makes to captive.apple.com or whatever through but still try to present a captive portal to the user. I can guess as to the motivation, but as a user it's danged annoying.

Thanks for this. I never can remember URLs like this but I always remember chicken.com. It's sad day to see it go away.

I'm French-Canadian I use http://perdu.com [1] (Perdu is lost in French).

It's a light funny page i've found about 10+ years ago but it's HTTP and helpfull for captive portals.

[1] https://fr.wikipedia.org/wiki/Perdu.com

It has been a long time since I've seen a captive portal that doesn't trigger the "this connection needs authentication" message on my phone.

HSTS takes care of that. It's an HTTP header to indicate not to connect without TLS in the future.

It makes sense to keep falling back to HTTP if that header is not set.

It might still be an issue, but this is still a huge improvement. If the browser is going to pick a protocol on behalf of the user, it ought choose a stronger protocol first.

If the browser chooses the stronger protocol it should force the user to opt-in to any fallback behavior which might downgrade security. The current behavior of the browser in most cases is if you enter an 'https' url and the request fails or the cert is invalid you get a failure or warning message. I'd like to see this behavior kept in this case. It communicates what the browser is doing instead of silently downgrading the protocol based upon fuzzy failure signals.

That would be ideal

> "you have to type http:// if you want HTTP"

That makes sense only to programmers, who make a small fraction of users. Browsers are mainstream; we need to be more thoughtful.

Long term, to normal users, there should be only HTTPS.

Its a shame but I wish the insecure protocol name was not a prefix of the secure protocol name. Its so easy to miss the 's' and for things to just work for the wrong reason. I guess we have Netscape and Microsoft to blame for this one.

https://en.m.wikipedia.org/wiki/Secure_Hypertext_Transfer_Pr...

I really don’t get this opinion. The internet isn’t secure — the public internet is by definition an untrusted network assumed to be malicious and openly hostile. There is no safe way to use unencrypted connections on the public internet. None. Doesn’t matter if you are a good admin on your local network, doesn’t matter if you have a good ISP, you have zero guarantee the network path your packets will take and who has the opportunity to observe and modify them.

Look I get it. It’s no fun when the whole class is punished because because bad actors exist. And it’s no fun when someone pressures you into doing something for the benefit of others but not yourself. But the internet is really really different from 20 years ago.

This is actually one of the utilities of a heavy industry player: they can adopt a best practice to impose it on smaller players.

... and HTTPS on the public internet is a best practice. Your ISP should have no business sniffing your web traffic.

While there are a finite number of trust providers in the HTTPS signed certificate model, "Let's Encrypt" isn't the only one.

But, yes, HTTPS is a trust-rooted security model. It's hypothetically possible to have every cert provider decide you're not trusted. That's kind of in the category of "It's hypothetically possible to have every DNS provider decide you're not trusted" though.

If this is a concern, the solution is probably to come up with an HTTPS modification that allows for decentralized trust, not to set up the average use case of the web to "The user is trusting every machine between their client and the server to be reading their traffic and not acting maliciously on it." Tradeoffs, right?

> What happens when the site I type in the URL bar doesn't support HTTPS?

The article says: "For sites that don’t yet support HTTPS, Chrome will fall back to HTTP when the HTTPS attempt fails."

Yes, a MITM could block this access. This would be an active attack and thus detectable, which is fine if you're the Great Firewall and your existence is government policy but likely to be a problem for some other types of attacker.

In the passive attack case this is strictly better (previously a passive on-path attacker gets to see all the unprefixed URLs typed into a Google that didn't match an HSTS rule it knew, and with this change they do not) in an active attack nothing changes.

> For sites that don’t yet support HTTPS, Chrome will fall back to HTTP when the HTTPS attempt fails.

It's in the article!

From the article: "For sites that don’t yet support HTTPS, Chrome will fall back to HTTP when the HTTPS attempt fails."

It's in the article:

"For sites that don’t yet support HTTPS, Chrome will fall back to HTTP when the HTTPS attempt fails."

I hope the slippery slope stops here though and HTTP will not be eradicated in browsers (in which case one would need corporate permission and approval to publish anything).

s_client or curl are not a suitable workarounds for the masses ...

Next steps could be

1) Rather than auto-redirect, ask the user if they want to redirect

2) Force the user to type http://server/ to visit the server on http

Neither of those eradicates http.

At the end it states it will then fall back to http.