This globally-enforced move to HTTPS is killing the security and privacy for home projects and intranet-hosted websites. If Google forces HTTPS everywhere, and refuses to accept "self signed HTTPS certs", then there is no path left for security-camera/home-automation/staticIP-family-websites without being forced into going over the internet. I can't even show my projects to my non-technical friends without looking like some scammer because of these dumb warning messages plastered all over their browsers on my own wifi!
Chrome team: Either start accepting self-signed certs for LAN, or drop forced HTTPS for intranet altogether -- I DO NOT want to put my family's or my personal-project data on the internet!
>I DO NOT want to put my family's or my personal-project data on the internet!
DNS-01 challenges addresses this, the webserver never needs to be exposed to the internet.
>I can't even show my projects to my non-technical friends without looking like some scammer
How would the alternative work? If https enforcement can be disabled server side without a notification to the user, what is the point of https? If it's something that can be set on the user side, how would it be substantively different than the user accepting a self-signed certificate?
Are you saying that you can't create a self-signed CA that Chrome will trust when configured to do so?
Personally, I'm using Letsencrypt with DNS validation for internal projects. A wildcard certificate that needs to be renewed every 3 months for a domain does the trick, the servers themselves don't need to be on the Internet, just have a domain-based name. (I have some Ansible automation behind it.)
This is one of the concerns that lead me to build getlocalcert.net. You don't need to expose your home network to the Internet, you don't need to buy your own domain name, you don't need to convince your friends to install a private CA, and it doesn't cost any money.
I didn't talk about this in the post mostly for brevity, but the challenge of HTTPS on local networks is absolutely on our radar. We're still evaluating what the right strategy is for addressing it, but we definitely _are not_ going to show big scary warnings on all local network access or otherwise make them inaccessible.
They also updated Chrome a long time ago to stop showing which protocol you are using on the address bar, which IMO is a very stupid decision. I want to know if the site I'm accessing has HTTPS by looking at the URL, I never asked someone to hide the protocol part of it. Okay, there's the green padlock, but still, I want my full URL, I don't want my browser to hide my URLs.
If you don't want TLS warnings then just create the certificates from a single (self-signed) root CA and deploy the CA certificate in your local Chrome, Windows, etc.
As an added bonus you get actual security. Since anyone can just recreate your self signed certificates currently because no one bothers to check them.
> We know that enterprises and education networks have unique needs. These features can be turned on early, customized, or turned off entirely via the HttpsOnlyMode, HttpsUpgradesEnabled, HttpAllowlist, and InsecureContentAllowedForUrls policies.
Also a lot of people are talking about internally hosted sites and acting like now you'll have to go pay a CA or something. That is not the case.
The worst case scenario is that your internal site will require a click through. If you want to avoid that just issue a certificate yourself for it, either via IP (if Chrome will support that?) or via a domain that you resolve via your router. Or if you control the browser, just... turn this off.
>For the past several years, more than 90% of Chrome users' navigations have been to HTTPS sites,
How do they know this? That's frightening. I guess that's part of why they're so okay with going to HTTPS only; it apparently doesn't stop them from snooping.
Adding scaremongering annoyance click-throughts for connections to HTTP is bad too. Much like how the megacorp browsers have made HTTPS self-signed sites unvisitable it looks like they're trying to make HTTP sites unvisitable too. This will not be a problem for for-profit and institutional sites but it'll make most of the old, non-commercial web unvisitable for chrome users.
I'm not against HTTPS or HTTPS by default. I think that's a good idea. But stopping people from visiting HTTP sites is something that only makes sense in some contexts. Doing it universally will make the web a much smaller, more profit oriented space (at least for chrome users).
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.
I believe the setting "Make searches and browsing better" (subtitle "Send URLs of pages you visit to google") under chrome://settings/syncSetup is on by default if you don't manually uncheck the send usage data checkbox when installing
Even without snooping on domains (let alone entire URLs), it would be feasible to only observe the protocol part of `window.location` and send it as anonymized telemetry.
But who am I kidding, given who we're talking about, I doubt that's what's happening.
It's very frightening, and it's the end result of opt-out telemetry "to make the product better". There are certain pieces of software that should never have telemetry: your OS, your web browser, your terminal, your email client...
I choose software written by craftspeople with an opinion who don't "need" telemetry, not software that's just a conduit to hoover up my personal and sensitive data.
While I support the cause, HTTPS is the biggest thing obsoleting old devices in my experience.
Currently hitting this with an old eink project that's based on an obsolete ereader. I wonder if there's some kind of proxy I could connect to over HTTP that does the modern HTTPS on my behalf. (I'm aware of the security implications, just want it to get a tweet/weather forecast)
> Chrome will automatically upgrade all http:// navigations to https://, even when you click on a link that explicitly declares http://.
https: and http: authorities are totally unrelated. Here, https: server will receive and reply to requests that were intended by websites to go to http:, which is dangerous if the two servers aren't controlled by the same author. All in all, an insane change.
"However, a stubborn 5-10% of traffic has remained on HTTP, allowing attackers to eavesdrop on or change that data."
How do we stop Google from eavsedropping on us via data exfiltration.
Unfortunately, whether intentional or not, HTTPS assists so-called "tech" companies with exfiltration of data from computer users, which they perform on a mass scale. It inhibits computers users from monitoring the traffic, traffic that is initiated by so-called "tech" companies not the users themselves, from their computers to these so-called "tech" companies such as Google. That's a potential problem for computer users but it's an advantage for Google and other so-called "tech" companies that rely on surveillance and data collection in order to profit from online advertising services.
Many companies MiTM TLS in order to monitor data exfiltration. Today, many employees work from home. Computer users at home should be allowed to monitor the traffic leaving their home computers and travelling over their home networks.
Of the alleged 5-10% of traffic that has remained HTTP it would be useful to know how much is actually being eavesdropped on or changed. How large is this problem in comparison to the problem of data exfiltration.
The only example I know of is the case of an ISP injecting online advertising into web pages. When an ISP attempted to inject ads into HTTP, the public responded. The ISP was caught out, immediately. However with data exfiltration protected from public scrutiny via HTTPS, Google can continue to avoid such public objection.
Whether it is an ISP injecting ads or Google collecting data to provide services to others who want to inject "personalised" ads, the goal is the same: to profit from annoying users with online ads.
Unlike speculative problems of eavesdropping and data manipulation associated with 5-10% of Chrome traffic using HTTP, the amount of useful commercial surveillance data being exiltrated from Chrome is a real and daily occurrence for hundreds of millions of computer users.
Chrome's TLS roadblocks and warnings to prevent any and all computer users from acting as their own certificate authorities in order to monitor the traffic from their computers via Chrome are especially dubious.
Please do not misinterpret this comment. I am not against TLS or HTTPS. I am in favour of respecting the choice of some users to act as their own CAs in certain situations, for certain purposes. I am against "forced delegation of trust". Everyone has a right to trust themselves as opposed to completely delegating all trust to Google and the commercial CA business. This should be a choice made by the computer user, not Google. Trust is a two-way street. If computer users "trust" Google, then Google must trust computer users.
Just a couple weeks ago I wanted to inspect some of the HTTPS traffic that Chrome was sending to Google. All I had to do was set the SSLKEYLOGFILE environment variable, and Chrome wrote the TLS session keys to this file. I told Wireshark the location of this file, and then sniffing the traffic was just as easy as sniffing unencrypted traffic.
It's also possible to add your own CA to Chrome's trust store and MitM the HTTPS traffic from Chrome. I don't know what these "TLS roadblocks and warnings to prevent any and all computer users from acting as their own certificate authorities" are.
It's simply not true that Chrome is erecting roadblocks to monitoring your own traffic. Rather, they're trying to make sure that your traffic cannot be monitored without your consent. If you're in favor of user choice, you should be in favor of this.
Hopefully Chromium starts wanting ipv6 by default as well and starts putting a warning message on websites still using ipv4 in 2023 too. We are almost at 50% ipv6 usage according to Google, time to start pressuring the laggards.
What is even worse is that HTTP is getting deprecated. There are entire swathes of web APIs which are only usable over HTTPS, HTTP/2 and HTTP/3 don't even support unencrypted HTTP, and all browsers scream about self-signed HTTPS certificates, treating them worse than unencrypted HTTP.
All browser vendors are behind this, even mozilla, this is a global conspiracy to crack down on the open internet.
[+] [-] jjkeddo199|2 years ago|reply
Chrome team: Either start accepting self-signed certs for LAN, or drop forced HTTPS for intranet altogether -- I DO NOT want to put my family's or my personal-project data on the internet!
[+] [-] xnyan|2 years ago|reply
DNS-01 challenges addresses this, the webserver never needs to be exposed to the internet.
>I can't even show my projects to my non-technical friends without looking like some scammer
How would the alternative work? If https enforcement can be disabled server side without a notification to the user, what is the point of https? If it's something that can be set on the user side, how would it be substantively different than the user accepting a self-signed certificate?
[+] [-] janosdebugs|2 years ago|reply
Personally, I'm using Letsencrypt with DNS validation for internal projects. A wildcard certificate that needs to be renewed every 3 months for a domain does the trick, the servers themselves don't need to be on the Internet, just have a domain-based name. (I have some Ansible automation behind it.)
[+] [-] andrewxdiamond|2 years ago|reply
You can get a cert for a domain that you only use on your intranet. The only public thing about it is the domain registration.
You can even use Lets Encrypt to get that cert for no cost. You just need to own a domain
[+] [-] 8organicbits|2 years ago|reply
Check us out: https://www.getlocalcert.net/
[+] [-] deblasioj|2 years ago|reply
I didn't talk about this in the post mostly for brevity, but the challenge of HTTPS on local networks is absolutely on our radar. We're still evaluating what the right strategy is for addressing it, but we definitely _are not_ going to show big scary warnings on all local network access or otherwise make them inaccessible.
[+] [-] xinayder|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] Avamander|2 years ago|reply
[+] [-] bradley13|2 years ago|reply
[+] [-] stavros|2 years ago|reply
Use Firefox?
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] jsiepkes|2 years ago|reply
As an added bonus you get actual security. Since anyone can just recreate your self signed certificates currently because no one bothers to check them.
For example something like this: https://arminreiter.com/2022/01/create-your-own-certificate-...
[+] [-] insanitybit|2 years ago|reply
> We know that enterprises and education networks have unique needs. These features can be turned on early, customized, or turned off entirely via the HttpsOnlyMode, HttpsUpgradesEnabled, HttpAllowlist, and InsecureContentAllowedForUrls policies.
Also a lot of people are talking about internally hosted sites and acting like now you'll have to go pay a CA or something. That is not the case.
The worst case scenario is that your internal site will require a click through. If you want to avoid that just issue a certificate yourself for it, either via IP (if Chrome will support that?) or via a domain that you resolve via your router. Or if you control the browser, just... turn this off.
[+] [-] superkuh|2 years ago|reply
How do they know this? That's frightening. I guess that's part of why they're so okay with going to HTTPS only; it apparently doesn't stop them from snooping.
Adding scaremongering annoyance click-throughts for connections to HTTP is bad too. Much like how the megacorp browsers have made HTTPS self-signed sites unvisitable it looks like they're trying to make HTTP sites unvisitable too. This will not be a problem for for-profit and institutional sites but it'll make most of the old, non-commercial web unvisitable for chrome users.
I'm not against HTTPS or HTTPS by default. I think that's a good idea. But stopping people from visiting HTTP sites is something that only makes sense in some contexts. Doing it universally will make the web a much smaller, more profit oriented space (at least for chrome users).
[+] [-] kmeisthax|2 years ago|reply
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.
[+] [-] Lt_Riza_Hawkeye|2 years ago|reply
I believe the setting "Make searches and browsing better" (subtitle "Send URLs of pages you visit to google") under chrome://settings/syncSetup is on by default if you don't manually uncheck the send usage data checkbox when installing
[+] [-] franky47|2 years ago|reply
But who am I kidding, given who we're talking about, I doubt that's what's happening.
[+] [-] kuratkull|2 years ago|reply
[+] [-] dadrian|2 years ago|reply
[+] [-] CharlesW|2 years ago|reply
I'd assume through ga.js (and urchin.js).
[+] [-] bluefishinit|2 years ago|reply
It's very frightening, and it's the end result of opt-out telemetry "to make the product better". There are certain pieces of software that should never have telemetry: your OS, your web browser, your terminal, your email client...
I choose software written by craftspeople with an opinion who don't "need" telemetry, not software that's just a conduit to hoover up my personal and sensitive data.
[+] [-] forgotmypw17|2 years ago|reply
It’s what I’m planning to stick with for the foreseeable future.
[+] [-] joerick|2 years ago|reply
Currently hitting this with an old eink project that's based on an obsolete ereader. I wonder if there's some kind of proxy I could connect to over HTTP that does the modern HTTPS on my behalf. (I'm aware of the security implications, just want it to get a tweet/weather forecast)
[+] [-] chromoblob|2 years ago|reply
https: and http: authorities are totally unrelated. Here, https: server will receive and reply to requests that were intended by websites to go to http:, which is dangerous if the two servers aren't controlled by the same author. All in all, an insane change.
[+] [-] 1vuio0pswjnm7|2 years ago|reply
How do we stop Google from eavsedropping on us via data exfiltration.
Unfortunately, whether intentional or not, HTTPS assists so-called "tech" companies with exfiltration of data from computer users, which they perform on a mass scale. It inhibits computers users from monitoring the traffic, traffic that is initiated by so-called "tech" companies not the users themselves, from their computers to these so-called "tech" companies such as Google. That's a potential problem for computer users but it's an advantage for Google and other so-called "tech" companies that rely on surveillance and data collection in order to profit from online advertising services.
Many companies MiTM TLS in order to monitor data exfiltration. Today, many employees work from home. Computer users at home should be allowed to monitor the traffic leaving their home computers and travelling over their home networks.
Of the alleged 5-10% of traffic that has remained HTTP it would be useful to know how much is actually being eavesdropped on or changed. How large is this problem in comparison to the problem of data exfiltration.
The only example I know of is the case of an ISP injecting online advertising into web pages. When an ISP attempted to inject ads into HTTP, the public responded. The ISP was caught out, immediately. However with data exfiltration protected from public scrutiny via HTTPS, Google can continue to avoid such public objection.
Whether it is an ISP injecting ads or Google collecting data to provide services to others who want to inject "personalised" ads, the goal is the same: to profit from annoying users with online ads.
Unlike speculative problems of eavesdropping and data manipulation associated with 5-10% of Chrome traffic using HTTP, the amount of useful commercial surveillance data being exiltrated from Chrome is a real and daily occurrence for hundreds of millions of computer users.
Chrome's TLS roadblocks and warnings to prevent any and all computer users from acting as their own certificate authorities in order to monitor the traffic from their computers via Chrome are especially dubious.
Please do not misinterpret this comment. I am not against TLS or HTTPS. I am in favour of respecting the choice of some users to act as their own CAs in certain situations, for certain purposes. I am against "forced delegation of trust". Everyone has a right to trust themselves as opposed to completely delegating all trust to Google and the commercial CA business. This should be a choice made by the computer user, not Google. Trust is a two-way street. If computer users "trust" Google, then Google must trust computer users.
[+] [-] agwa|2 years ago|reply
It's also possible to add your own CA to Chrome's trust store and MitM the HTTPS traffic from Chrome. I don't know what these "TLS roadblocks and warnings to prevent any and all computer users from acting as their own certificate authorities" are.
It's simply not true that Chrome is erecting roadblocks to monitoring your own traffic. Rather, they're trying to make sure that your traffic cannot be monitored without your consent. If you're in favor of user choice, you should be in favor of this.
[+] [-] 1vuio0pswjnm7|2 years ago|reply
https://httptoolkit.tech/blog/chrome-android-certificate-tra...
https://news.ycombinator.com/item?id=31341997
[+] [-] xacky|2 years ago|reply
[+] [-] p1mrx|2 years ago|reply
[+] [-] Pannoniae|2 years ago|reply
All browser vendors are behind this, even mozilla, this is a global conspiracy to crack down on the open internet.