5 ms·

The snooping is literally just Chrome saying "I've visited 95 pages, 90 of which were encrypted." None of that violates HTTPS's security guarantees; the fact th

The snooping is literally just Chrome saying "I've visited 95 pages, 90 of which were encrypted." None of that violates HTTPS's security guarantees; the fact that you are using encryption is not a secret in HTTPS. This isn't scaremongering. Go on any kind of public Wi-Fi and see what horrors the network does to your unencrypted traffic (and how those horrors can get cached and persist when you leave the network). It's actually kind of bonkers that we spent a decade treating unsigned HTTPS as less secure than unencrypted HTTP. As for non-commercial sites, we've had Lets Encrypt for almost a decade at this point. It's literally free, and it's really all you need. There is no excuse for any public facing website with a fully-qualified domain name to not have encryption anymore. As far as I'm aware Chrome isn't trying to ban HTTP connections. All they're doing is giving you a warning. Hell, they're actually making things easier on the old web by doing automatic upgrades. So you don't even need to change your old HTML files, you just need to ensure that you have a cert setup in your server configuration.

superkuh 3y ago
No on is advocating for HTTP only. We're saying webservers should be HTTP+HTTPS.
ghusto 3y ago
> As for non-commercial sites, we've had Lets Encrypt for almost a decade at this point Saying there's "no excuse" to not have HTTPS is presuming there's a benefit in 100% of cases to have it in the first place. I don't want my internal sites breaking because a cert couldn't be updated, on something that didn't need it in the first place. There are even external sites I run that I could argue don't need it.
- hsbauauvhabzb 3y ago
  Just imagine 10-year-old-us trying to build a website now, and some megacorp slapping us down and saying ‘No TLS no excuse!’
  - unmole 3y ago
    I'm having a hard time imagining a 10 year old capable of building a website from scratch but incapable of figuring out how to setup Let's Encrypt.
    - hsbauauvhabzb 3y ago
      You realise building a website can be done in notepad, without a web server, or self hosted on loopback, or a variety of other things, right?
      - unmole 3y ago
        You do realise a HTML page in notepad isn't a website, right? TFA is about moving all http:// http:// navigations to https:// https:// and requiring explicit permission to access content over http:// http://. A local file is not served over HTTP.
dahwolf 3y ago
"There is no excuse for any public facing website with a fully-qualified domain name to not have encryption anymore." This is a display of arrogance and lack of empathy matching the Chrome team's article. There is a sizable "old web". Built by amateurs. Think people writing web pages in Microsoft Word and FTP-ing it. They're not web developers or sysadmins and have absolutely no idea what we're talking about when we insist they should just install certbot. Many of the owners may not be reachable anymore or in the worst case, dead. I object to breaking the old web. I object to the assumption that behind every website there is a competent tech team, perpetually upgrading whatever others decide to break from some ivory tower. And whilst I don't need convincing of the security benefits of HTTPs, I worry about the centralizing force that it is. Take out Letsencrypt and Cloudflare and you destroy the internet. We're practically begging for it.
- hsbauauvhabzb 3y ago
  Linux distro repositories commonly use http and gpg verify on the host, as the repository hosting provider may be as grey party. I assume tls overhead on CDNs would be substantial, so if cryptographic verification can be offloaded elsewhere, maybe that is a reasonable solution in some cases.
- insanitybit 3y ago
  > I object to breaking the old web. Just click through the warning.
  - superkuh 3y ago
    Sure, as geeks we're all going to click though. But 99% of people aren't going to. So that makes hosting a visitable website pretty hard.
    - insanitybit 3y ago
      I just think that's significantly different from "breaking" the old web. Nothing is broken.
- 3y ago
slaymaker1907 3y ago
> There is no excuse for any public facing website with a fully-qualified domain name to not have encryption anymore. One really good excuse is for sites like neverssl.com. Its sole purpose is to always be unencrypted so janky WiFi (and truly horrifying ethernet) setups can work.
- Scion9066 3y ago
  That's an edge case made specifically to be MITM'd by the network you're on. It's also a pretty good example of what someone with control of the network can do to any non-encrypted connection.
cornstalks 3y ago
> There is no excuse for any public facing website with a fully-qualified domain name to not have encryption anymore. neverssl.com is a legitimate use case (though the fact that it's even needed is unfortunate).
- insanitybit 3y ago
  `neverssl.com` will continue to work just fine. It's not like ISPs are blocking HTTP or something, your browser is just going to tell you that the site is HTTP and you'll have to click through.
  - dingaling 3y ago
    The click-through is already cumbersome and hidden by default. I wouldn't be surprised if it was soon deprecated altogether.
noirscape 3y ago
>no excuse Are you sure about that? Yeah if your site has possibly sensitive data or deals with login data, HTTPS matters a lot. Thing is, there's still a sizable portion of the web that runs without HTTPS because for a static blog/site about boring stuff you really get no advantage on HTTPS besides "Chrome won't yell at you" (which to be clear, Chrome Being Annoying About It has been the larger push to HTTPS for this group of site operators). > As far as I'm aware Chrome isn't trying to ban HTTP connections. It's the long-term goal. The link says this specifically. Right now they'll do silent upgrades but the long-term goal is to show the current "insecure connection" interstitial for expired HTTPS certs. Also, as has been stated in other places - intranet is a thing and deploying self-signed certs, especially on consumer intranets (who do need these things for setting up stuff like printers, home cameras and solar panels) is a complete crapshoot. Windows has its own cert store, but so do Chrome and Firefox and you need it in the browser to work (plus adding it is really non-intuitive). Linux has no cert store if memory serves me right so you only need the browsers. Android requires digging in the system settings to add a cert and on iOS you need a provisioning profile to add any certs if I'm not mistaken. No clue about OSX. To be clear there's mitigations - ie. Autotrust the reserved intranet/multicast TLDs (.intranet, .internal, .private, .corp, .home, .lan and .local - this list being taken from RFC6762, which is followed by the IETF even if they've never officially declared it to be in effect) or having a universally signed certificate for those domains that generates no records in the crt.sh log (this is why you can't always issue things for intranets with a public CA - all certificate requests to public SSL hosts like letsencrypt are logged). Both would probably limit security but they're a big hurdle that needs clearing.

superkuh 3y ago

No on is advocating for HTTP only. We're saying webservers should be HTTP+HTTPS.

ghusto 3y ago

> As for non-commercial sites, we've had Lets Encrypt for almost a decade at this point Saying there's "no excuse" to not have HTTPS is presuming there's a benefit in 100% of cases to have it in the first place. I don't want my internal sites breaking because a cert couldn't be updated, on something that didn't need it in the first place. There are even external sites I run that I could argue don't need it.

hsbauauvhabzb 3y ago
Just imagine 10-year-old-us trying to build a website now, and some megacorp slapping us down and saying ‘No TLS no excuse!’
- unmole 3y ago
  I'm having a hard time imagining a 10 year old capable of building a website from scratch but incapable of figuring out how to setup Let's Encrypt.
  - hsbauauvhabzb 3y ago
    You realise building a website can be done in notepad, without a web server, or self hosted on loopback, or a variety of other things, right?
    - unmole 3y ago
      You do realise a HTML page in notepad isn't a website, right? TFA is about moving all http:// http:// navigations to https:// https:// and requiring explicit permission to access content over http:// http://. A local file is not served over HTTP.

dahwolf 3y ago

"There is no excuse for any public facing website with a fully-qualified domain name to not have encryption anymore." This is a display of arrogance and lack of empathy matching the Chrome team's article. There is a sizable "old web". Built by amateurs. Think people writing web pages in Microsoft Word and FTP-ing it. They're not web developers or sysadmins and have absolutely no idea what we're talking about when we insist they should just install certbot. Many of the owners may not be reachable anymore or in the worst case, dead. I object to breaking the old web. I object to the assumption that behind every website there is a competent tech team, perpetually upgrading whatever others decide to break from some ivory tower. And whilst I don't need convincing of the security benefits of HTTPs, I worry about the centralizing force that it is. Take out Letsencrypt and Cloudflare and you destroy the internet. We're practically begging for it.

hsbauauvhabzb 3y ago
Linux distro repositories commonly use http and gpg verify on the host, as the repository hosting provider may be as grey party. I assume tls overhead on CDNs would be substantial, so if cryptographic verification can be offloaded elsewhere, maybe that is a reasonable solution in some cases.
insanitybit 3y ago
> I object to breaking the old web. Just click through the warning.
- superkuh 3y ago
  Sure, as geeks we're all going to click though. But 99% of people aren't going to. So that makes hosting a visitable website pretty hard.
  - insanitybit 3y ago
    I just think that's significantly different from "breaking" the old web. Nothing is broken.
3y ago

slaymaker1907 3y ago

> There is no excuse for any public facing website with a fully-qualified domain name to not have encryption anymore. One really good excuse is for sites like neverssl.com. Its sole purpose is to always be unencrypted so janky WiFi (and truly horrifying ethernet) setups can work.

Scion9066 3y ago
That's an edge case made specifically to be MITM'd by the network you're on. It's also a pretty good example of what someone with control of the network can do to any non-encrypted connection.

cornstalks 3y ago

> There is no excuse for any public facing website with a fully-qualified domain name to not have encryption anymore. neverssl.com is a legitimate use case (though the fact that it's even needed is unfortunate).

insanitybit 3y ago
`neverssl.com` will continue to work just fine. It's not like ISPs are blocking HTTP or something, your browser is just going to tell you that the site is HTTP and you'll have to click through.
- dingaling 3y ago
  The click-through is already cumbersome and hidden by default. I wouldn't be surprised if it was soon deprecated altogether.

noirscape 3y ago

>no excuse Are you sure about that? Yeah if your site has possibly sensitive data or deals with login data, HTTPS matters a lot. Thing is, there's still a sizable portion of the web that runs without HTTPS because for a static blog/site about boring stuff you really get no advantage on HTTPS besides "Chrome won't yell at you" (which to be clear, Chrome Being Annoying About It has been the larger push to HTTPS for this group of site operators). > As far as I'm aware Chrome isn't trying to ban HTTP connections. It's the long-term goal. The link says this specifically. Right now they'll do silent upgrades but the long-term goal is to show the current "insecure connection" interstitial for expired HTTPS certs. Also, as has been stated in other places - intranet is a thing and deploying self-signed certs, especially on consumer intranets (who do need these things for setting up stuff like printers, home cameras and solar panels) is a complete crapshoot. Windows has its own cert store, but so do Chrome and Firefox and you need it in the browser to work (plus adding it is really non-intuitive). Linux has no cert store if memory serves me right so you only need the browsers. Android requires digging in the system settings to add a cert and on iOS you need a provisioning profile to add any certs if I'm not mistaken. No clue about OSX. To be clear there's mitigations - ie. Autotrust the reserved intranet/multicast TLDs (.intranet, .internal, .private, .corp, .home, .lan and .local - this list being taken from RFC6762, which is followed by the IETF even if they've never officially declared it to be in effect) or having a universally signed certificate for those domains that generates no records in the crt.sh log (this is why you can't always issue things for intranets with a public CA - all certificate requests to public SSL hosts like letsencrypt are logged). Both would probably limit security but they're a big hurdle that needs clearing.