Towards HTTPS by Default(blog.chromium.org)
blog.chromium.org
Towards HTTPS by Default
https://blog.chromium.org/2023/08/towards-https-by-default.html
117 comments
>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?
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?
> How would the alternative work?
It's not an easy problem to solve, but I think it would be possible to extend PKI to make it work for local networks without internet access.
An approach could work as follows:
Dedicate a special TLD for "local-only domains". Such domains are only expected to be valid inside a specific LAN, analogous to 192.168.* IP addresses. (In fact, several TLDs with that kind of intended use already exist [1])
Specify some way how a local network can announce a CA specifically for that network (maybe through a DHCP extension, a special "well-known" hostname or IP address or a field in a wifi beacon message)
When a user navigates to a local-only domain, the site's cert is validated using the network's CA. The CA is only valid for local-only domains and only while connected to that specific network.
This would allow using PKI and encrypted connections inside a LAN, would not require internet access or 3rd party services and would also not compromise the security of domains on the internet.
[1] https://unix.stackexchange.com/questions/92441/whats-the-dif...
It's not an easy problem to solve, but I think it would be possible to extend PKI to make it work for local networks without internet access.
An approach could work as follows:
Dedicate a special TLD for "local-only domains". Such domains are only expected to be valid inside a specific LAN, analogous to 192.168.* IP addresses. (In fact, several TLDs with that kind of intended use already exist [1])
Specify some way how a local network can announce a CA specifically for that network (maybe through a DHCP extension, a special "well-known" hostname or IP address or a field in a wifi beacon message)
When a user navigates to a local-only domain, the site's cert is validated using the network's CA. The CA is only valid for local-only domains and only while connected to that specific network.
This would allow using PKI and encrypted connections inside a LAN, would not require internet access or 3rd party services and would also not compromise the security of domains on the internet.
[1] https://unix.stackexchange.com/questions/92441/whats-the-dif...
Several problems with this proposal:
1. Who defines what the local network is and why should this environment be trusted more? The IP address doesn't guarantee that the packets won't be going round the globe 3 times.
2. You are proposing a whole new, as of yet unresearched verification mechanism to TLS, which won't be supported by a whole lot of devices for a long time. I just had to downgrade a server of mine to TLS 1.2 because a high profile software couldn't deal with 1.3.
3. DHCP is inherently insecure and setting up a rogue AP is also not too difficult outside of an enterprise environment where certificate rollout is already not a problem. Ideal for hijacking an intranet connection covertly.
4. The proposed CA would not have the benefit of public transparency logs, so it would not meet the minimum requirements currently set forth by the browsers to trust a CA.
5. What happens if you are connected to more than one network at a time? Which one gets authority over the special TLD?
6. Who guarantees that the connected client uses the mandated DNS servers to resolve the special domain?
This is not a viable proposal for more than a handful of cases, but makes it a lot less secure for everyone else.
1. Who defines what the local network is and why should this environment be trusted more? The IP address doesn't guarantee that the packets won't be going round the globe 3 times.
2. You are proposing a whole new, as of yet unresearched verification mechanism to TLS, which won't be supported by a whole lot of devices for a long time. I just had to downgrade a server of mine to TLS 1.2 because a high profile software couldn't deal with 1.3.
3. DHCP is inherently insecure and setting up a rogue AP is also not too difficult outside of an enterprise environment where certificate rollout is already not a problem. Ideal for hijacking an intranet connection covertly.
4. The proposed CA would not have the benefit of public transparency logs, so it would not meet the minimum requirements currently set forth by the browsers to trust a CA.
5. What happens if you are connected to more than one network at a time? Which one gets authority over the special TLD?
6. Who guarantees that the connected client uses the mandated DNS servers to resolve the special domain?
This is not a viable proposal for more than a handful of cases, but makes it a lot less secure for everyone else.
1 + 3:
DHCP, wifi identification or what you can reach with a broadcast would be examples. If that's too insecure, out-of-band identification would also be possible, i.e. a QR code that contains a SSID, a hostname/IP address where the CA cert can be downloaded and a hash of the cert.
I don't see why it's important how the packet is actually routed as long as you have established a root of trust.
2: Yeah. So?
The worst that can happen to a device that doesn't have support is that it sees an invalid certificate.
I don't think widespread support would be necessary. The only software where support would be essential would be browsers.
4: Neither is a local root CA today. The entire point of the proposal is that it doesn't require any third parties. To make up for this, the CA is only valid for local domains, so you can't generate rogue certificates for google.com anyway.
5: That's a good point, but strictly speaking, the problem already exists today: what happens if you're connected to two networks which route the same IP address range? Or which reuse the same hostnames?
One option would be to add some sort of network identifier to the hostnames to make them unique. This might make the domains unwieldy to use though.
6: The same thing that "guarantees" that the client uses the network's CA for validation: The client itself, that hopefully correctly implements the spec.
You have the same problem with the "split DNS + LE with DNS validation" approach: If a client has 1.1.1.1 hardwired for DNS resolution and you only serve A/AAAA records inside the network, the client won't see your server. That's why even DoH will fall back to the network's DNS servers if it can't resolve a domain over the DoH server.
> This is not a viable proposal for more than a handful of cases, but makes it a lot less secure for everyone else.
Local-only hosts may be less secure than internet hosts, granted - but how would this reduce the security of everyone else?
DHCP, wifi identification or what you can reach with a broadcast would be examples. If that's too insecure, out-of-band identification would also be possible, i.e. a QR code that contains a SSID, a hostname/IP address where the CA cert can be downloaded and a hash of the cert.
I don't see why it's important how the packet is actually routed as long as you have established a root of trust.
2: Yeah. So?
The worst that can happen to a device that doesn't have support is that it sees an invalid certificate.
I don't think widespread support would be necessary. The only software where support would be essential would be browsers.
4: Neither is a local root CA today. The entire point of the proposal is that it doesn't require any third parties. To make up for this, the CA is only valid for local domains, so you can't generate rogue certificates for google.com anyway.
5: That's a good point, but strictly speaking, the problem already exists today: what happens if you're connected to two networks which route the same IP address range? Or which reuse the same hostnames?
One option would be to add some sort of network identifier to the hostnames to make them unique. This might make the domains unwieldy to use though.
6: The same thing that "guarantees" that the client uses the network's CA for validation: The client itself, that hopefully correctly implements the spec.
You have the same problem with the "split DNS + LE with DNS validation" approach: If a client has 1.1.1.1 hardwired for DNS resolution and you only serve A/AAAA records inside the network, the client won't see your server. That's why even DoH will fall back to the network's DNS servers if it can't resolve a domain over the DoH server.
> This is not a viable proposal for more than a handful of cases, but makes it a lot less secure for everyone else.
Local-only hosts may be less secure than internet hosts, granted - but how would this reduce the security of everyone else?
You are making excellent points for using globally resolvable DNS + Letsencrypt. :) None of these problems exist with that solution. Unless you enable AXFR, your hostnames won't be easily visible to the outside world and wildcard certificates are a thing too.
Specifically:
1,3,4,6: You want a seamless experience for the user and are assuming that the user is capable of making the decision to trust a network operator. This is not a decision an average user can make. Say, I set up a rogue AP for your university network which uses this special TLD. You connect to my AP, log in to your uni account on the special TLD, and now I have your credentials because you went through my reverse proxy. Very easy to pull off, almost impossible to reconstruct after the fact. QR codes, etc don't offer any protection here.
5. AFAIK the problem doesn't exist as far as domain names are concerned, search domains work across multiple networks. mDNS can also work across multiple networks to resolve host names. For IP addresses this is a problem, which the abundance of possible locally admininstered addresses with IPv6 will hopefully solve (ULA address ranges).
If you want to have full control over your local network environment, that's another thing, but you can't then expect everyone else's devices to automatically trust your environment. You'll have to jump through the hoops of making that environment trusted on the endpoint devices too. Any attempts of making peer to peer trust a thing have failed miserably over the last decades and nobody really seems to put any effort into writing, implementing and proving these standards anymore. It's too easily abused and determining trust is beyond the capabilities of the layperson, heck it often trips up experts too.
Specifically:
1,3,4,6: You want a seamless experience for the user and are assuming that the user is capable of making the decision to trust a network operator. This is not a decision an average user can make. Say, I set up a rogue AP for your university network which uses this special TLD. You connect to my AP, log in to your uni account on the special TLD, and now I have your credentials because you went through my reverse proxy. Very easy to pull off, almost impossible to reconstruct after the fact. QR codes, etc don't offer any protection here.
5. AFAIK the problem doesn't exist as far as domain names are concerned, search domains work across multiple networks. mDNS can also work across multiple networks to resolve host names. For IP addresses this is a problem, which the abundance of possible locally admininstered addresses with IPv6 will hopefully solve (ULA address ranges).
If you want to have full control over your local network environment, that's another thing, but you can't then expect everyone else's devices to automatically trust your environment. You'll have to jump through the hoops of making that environment trusted on the endpoint devices too. Any attempts of making peer to peer trust a thing have failed miserably over the last decades and nobody really seems to put any effort into writing, implementing and proving these standards anymore. It's too easily abused and determining trust is beyond the capabilities of the layperson, heck it often trips up experts too.
Yeah, you have a point. The fundamental problem is always: How can I keep an adversary from cloning/proxying a legitimate site then trickung users into visiting it. It's a hard problem even if there is a centralized authority and pretty much still open for decentralized systems.
I still think however that there are some properties of local networks that make this less risky:
- an attacker needs to be physically close to their victims in some way (or at least get devices into physical proximity): The rogue access point has to be located somewhere, someone has to tape over the QR codes, someone has to plug into the local network or connect to WLAN to send spoofed ARP/DHCP/DNS replies, etc. Compare that to phishing/typosquatting attacks on the internet where an attacker can be anywhere on the globe and can make their site look legitimate with a simple LE cert.
- an attacker is more at risk of being exposed. i.e. if someone keeps spoofing the university network, people might start to try and locate the wifi signal and knock on doors. That's a lot more risk than phishing/typosquatting for a lot less reward: Even if the attack works perfectly, you can only impersonate the local-only domains, not internet domains. (In fact, we don't currently live in an HTTPS-only world, so there would actually be some value for an attacker to spoof some campus wifi right now. I haven't heard of any incidents in that regard, so that leads me to believe that the risks are to high compared to the rewards)
- there are lots of situations where spoofing the CA information would require you to do a full supply-chain attack, such if I connect directly to a device using a cable or NFC connection; QR code stickers put directly on the device; if I manually add the device of another person to a wifi network I know, etc. (Those are slightly different use cases than "art installation" etc. I'd say they are still valuable though, e.g. for frictionless setup of local-only IoT devices)
> If you want to have full control over your local network environment, that's another thing, but you can't then expect everyone else's devices to automatically trust your environment
But that's the point, I don't want them to fully trust my environment. It's perfectly reasonable that there is no way to override the CA of say, google.com without an extremely scary security warning.
However, I'd like a way to offer some sort of website from a local network without causing a huge hassle for everyone who wants to use it or having to pretend I it's an internet domain.
I still think however that there are some properties of local networks that make this less risky:
- an attacker needs to be physically close to their victims in some way (or at least get devices into physical proximity): The rogue access point has to be located somewhere, someone has to tape over the QR codes, someone has to plug into the local network or connect to WLAN to send spoofed ARP/DHCP/DNS replies, etc. Compare that to phishing/typosquatting attacks on the internet where an attacker can be anywhere on the globe and can make their site look legitimate with a simple LE cert.
- an attacker is more at risk of being exposed. i.e. if someone keeps spoofing the university network, people might start to try and locate the wifi signal and knock on doors. That's a lot more risk than phishing/typosquatting for a lot less reward: Even if the attack works perfectly, you can only impersonate the local-only domains, not internet domains. (In fact, we don't currently live in an HTTPS-only world, so there would actually be some value for an attacker to spoof some campus wifi right now. I haven't heard of any incidents in that regard, so that leads me to believe that the risks are to high compared to the rewards)
- there are lots of situations where spoofing the CA information would require you to do a full supply-chain attack, such if I connect directly to a device using a cable or NFC connection; QR code stickers put directly on the device; if I manually add the device of another person to a wifi network I know, etc. (Those are slightly different use cases than "art installation" etc. I'd say they are still valuable though, e.g. for frictionless setup of local-only IoT devices)
> If you want to have full control over your local network environment, that's another thing, but you can't then expect everyone else's devices to automatically trust your environment
But that's the point, I don't want them to fully trust my environment. It's perfectly reasonable that there is no way to override the CA of say, google.com without an extremely scary security warning.
However, I'd like a way to offer some sort of website from a local network without causing a huge hassle for everyone who wants to use it or having to pretend I it's an internet domain.
The problem is that even if we assume this (or anything similar) is a good thing, we can't simply wish it into existence. The world is going into a different direction, everything is ever-more connected and apart from a very small minority, most local network admins are fine with Letsencrypt certificates or rolling their own CA.
If someone would want to put in the advocacy and development work, this would need to be written up in a formal fashion, probably in a scientific journal and/or an RFC published. Then there would need to be an implementation for at least one of the major OSes so security researchers can get their hands dirty with it and iron out the bugs. Once all this is done, you still need to convince Microsoft, Apple and Google to ship it in their OS because this is not a browser-only solution and needs OS support. And at this point the thing is probably pretty dead because their big customers are happy to run their own CA infrastructure, which leaves only a tiny minority of sysadmins for small systems that could ask for it. Not enough for these big companies to care because these small customers moving to Linux won't affect their bottom line. I would rather spend my time to advocate for simpler CA management or other verification methods with LE.
Honestly, I think the FQDN and Letsencrypt solution is fine. I've been using FQDNs for server names for a good 15 years now and I never had a problem with it. The people who didn't, however, had a bunch of pain to deal with, from having to merge networks to weird trust issues. I still remember the headless running around when .dev became a TLD and suddenly there was a conflict with oh so many folks' internal hostnames. Nothing about DNS says it has to be on the Internet. If you really want, you can even run a split DNS to make it only available in your own network, you just need to make the Letsencrypt verification work over the Internet.
If someone would want to put in the advocacy and development work, this would need to be written up in a formal fashion, probably in a scientific journal and/or an RFC published. Then there would need to be an implementation for at least one of the major OSes so security researchers can get their hands dirty with it and iron out the bugs. Once all this is done, you still need to convince Microsoft, Apple and Google to ship it in their OS because this is not a browser-only solution and needs OS support. And at this point the thing is probably pretty dead because their big customers are happy to run their own CA infrastructure, which leaves only a tiny minority of sysadmins for small systems that could ask for it. Not enough for these big companies to care because these small customers moving to Linux won't affect their bottom line. I would rather spend my time to advocate for simpler CA management or other verification methods with LE.
Honestly, I think the FQDN and Letsencrypt solution is fine. I've been using FQDNs for server names for a good 15 years now and I never had a problem with it. The people who didn't, however, had a bunch of pain to deal with, from having to merge networks to weird trust issues. I still remember the headless running around when .dev became a TLD and suddenly there was a conflict with oh so many folks' internal hostnames. Nothing about DNS says it has to be on the Internet. If you really want, you can even run a split DNS to make it only available in your own network, you just need to make the Letsencrypt verification work over the Internet.
>out-of-band identification would also be possible, i.e. a QR code
Any out-of-band method of enabling what you are talking about is necessarily going to prompt the user with the same kind of serious-looking security prompt they would see when adding a self-signed cert to the OS certificate store.
Any out-of-band method of enabling what you are talking about is necessarily going to prompt the user with the same kind of serious-looking security prompt they would see when adding a self-signed cert to the OS certificate store.
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.)
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.)
I can. My ex can't. My parents can't. My ex's parents either can. Strangely enough, normal people can't.
And that's the issue.
And what services do these people need to access/run on the local network that can't possibly be encrypted? The average person shouldn't be doing any of these things.
My home router for example always throws up a big scary https warning. I'd also very much prefer it if more smart devices were local network only rather than relying on a vendors website being up in perpetuity.
I'm actually not against browsers pushing HTTPS, I'm all for it. But it is a fair criticism that there are real downsides that there currently isn't a good user friendly solution for.
I'm actually not against browsers pushing HTTPS, I'm all for it. But it is a fair criticism that there are real downsides that there currently isn't a good user friendly solution for.
These days most non-IT people I know log in to their wifi network with the credentials printed on the sticker on the bottom. They wouldn't touch the web interface if their life depended on it.
which just exposes the wifi as an unsecured network, leading to far worse outcomes!
Which is why having secure connections enforced for the typical use case is doubly important. We can't wish a more secure solution into existence, this is how internet providers handle it in a great many places. Make TLS enforcement a very well hidden setting to turn it off/bypass, but don't let the average user anywhere near this.
Use Caddy as your webserver, use the DNS01 challenge, and you're done?
Don't expose your local stuff over the internet without encryption. The ISP doesn't need to see that.
Don't expose your local stuff over the internet without encryption. The ISP doesn't need to see that.
How is your home internet router going to retrieve a certificate from Let's Encrypt before you have logged in and configured it to connect to the internet?
Your preloaded root chain? I mean you can also trust on first use if you really want to.
My point is this.
I'm a consumer. I buy a new router. I need to log into its web interface to enter the PPPoE credentials from my ISP before it can go online. I plug it in, and browse to 192.168.0.1. Chrome says in big letters "PAGE IS NOT SECURE YOU ARE BEING HACKED DON'T VISIT THIS PAGE".
This situation means the router can't go online to generate a trusted certificate, and it's left with either HTTP or a self-signed certificate, both of which Chrome will present as inherently dangerous.
The solution that router manufacturers seem to be going with are "you must own an Apple or Google OS device, pray that we still have our app on the store in your country and support your router, and accept our onerous privacy terms"
> you can also trust on first use if you really want to
That's a totally acceptable solution! But one that Chrome does not seem interested in making look safe to users. They could do it for known-local IP ranges and hit 99% of the use cases (10., 192.168. etc)
I'm a consumer. I buy a new router. I need to log into its web interface to enter the PPPoE credentials from my ISP before it can go online. I plug it in, and browse to 192.168.0.1. Chrome says in big letters "PAGE IS NOT SECURE YOU ARE BEING HACKED DON'T VISIT THIS PAGE".
This situation means the router can't go online to generate a trusted certificate, and it's left with either HTTP or a self-signed certificate, both of which Chrome will present as inherently dangerous.
The solution that router manufacturers seem to be going with are "you must own an Apple or Google OS device, pray that we still have our app on the store in your country and support your router, and accept our onerous privacy terms"
> you can also trust on first use if you really want to
That's a totally acceptable solution! But one that Chrome does not seem interested in making look safe to users. They could do it for known-local IP ranges and hit 99% of the use cases (10., 192.168. etc)
“ This situation means the router can't go online to generate a trusted certificate, and it's left with either HTTP or a self-signed certificate, both of which Chrome will present as inherently dangerous.”
What are you on about? How does the router not having a valid certificate mean it “can’t go online”?
What are you on about? How does the router not having a valid certificate mean it “can’t go online”?
Curious: is this how routers are handled where you live? In Austria and the neighboring countries you typically get a device from the provider preconfigured, even if you don't want one.
Yeah. You're only guaranteed to get a free router if you also sign up for VoIP service which requires it and even then it will probably be wired-only and need a card to upgrade it to WiFi.
Ohwow, that's less than ideal. I wish I could convince my provider to let me use my own router so I can get rid of the double NAT, but I'm probably 1 in 10000.
[deleted]
I consider managing a CA at home to be a _much_ bigger security risk than having HTTP traffic on my home LAN.
Sign a certificate expiring in 2070 and delete the CA key. That's all management you need. And if anyone has access to your disk, it's much easier for them to add you their CA certificate than search for your CA key.
That may be so, but I from the perspective of a few billion people using Chrome, the percentage of people that need to and should access something on the local network without encryption is probably a few magnitudes smaller than the same audience on Hacker News.
This doesn't make sense unless you use the CA for something in addition / more critical for HTTP.
Sure, you could leak said CA, but it's only going to leave you in the same position as HTTP.
Sure, you could leak said CA, but it's only going to leave you in the same position as HTTP.
You can generate CA certs that are only allowed to sign certs for specific domains, but _nothing_ respects that self limitation.
That means that if the CA keys get out, someone could use it to sign their own cert for google.com, [mybank].com, or [mypasswordmanager].com. Every device with my CA cert on it will trust those.
That means that if the CA keys get out, someone could use it to sign their own cert for google.com, [mybank].com, or [mypasswordmanager].com. Every device with my CA cert on it will trust those.
That's a fair point.
Yes, that would work.
It still sucks that if I want a browser on my LAN to talk with a server on the same LAN, I now somehow still need internet access (to renew the cert), need at least two accounts on 3rd part cloud services (the domain registrar and Let's Encrypt) and have to continuously pay for the domain.
Oh, and also have to mess around with the DNS configuration on the router, so the domain is correctly resolved to your LAN IP inside the network, but does not have A/AAAA records on the internet.
Also, this solves this problem for geeks with some knowledge of network protocols, but it still leaves everyone stranded who would like to run a local server but has no deep technical knowledge.
Finally, it's impossible to solve this problem in a large-scale manner, i.e. for devices you want to sell. Which is why the access menus for home routers will probably still stay on plaintext HTTP.
It still sucks that if I want a browser on my LAN to talk with a server on the same LAN, I now somehow still need internet access (to renew the cert), need at least two accounts on 3rd part cloud services (the domain registrar and Let's Encrypt) and have to continuously pay for the domain.
Oh, and also have to mess around with the DNS configuration on the router, so the domain is correctly resolved to your LAN IP inside the network, but does not have A/AAAA records on the internet.
Also, this solves this problem for geeks with some knowledge of network protocols, but it still leaves everyone stranded who would like to run a local server but has no deep technical knowledge.
Finally, it's impossible to solve this problem in a large-scale manner, i.e. for devices you want to sell. Which is why the access menus for home routers will probably still stay on plaintext HTTP.
Funnily enough, some companies managed to solve the router problem. The Unifi Dream Machine is perfectly first-time configurable from a mobile app. Simpler routers don't really need any configuration these days and most people get routers from their provider anyway, whether they like it or not.
When talking about smart home devices, much of these are configured via their own apps, it's not like you are accessing a web interface much. If you are... well, there have been a number of remote code executions in these, so I'm not sure that bypassing a certificate warning is the biggest problem here.
Generally, I believe if someone can't set up a certificate then they don't have any business running web services for other people. The big problem is that it's not trivial for a browser to decide what's on "the local network" and what isn't.
When talking about smart home devices, much of these are configured via their own apps, it's not like you are accessing a web interface much. If you are... well, there have been a number of remote code executions in these, so I'm not sure that bypassing a certificate warning is the biggest problem here.
Generally, I believe if someone can't set up a certificate then they don't have any business running web services for other people. The big problem is that it's not trivial for a browser to decide what's on "the local network" and what isn't.
Yeah, I think the general trend is that all those devices either assume you have an app or only talk to the vendor's cloud service anyway.
It's working, it just ensures that absolutely everything needs internet access.
It's working, it just ensures that absolutely everything needs internet access.
We had a few decades to come up with a viable trust model for the local network. We didn't and it's not like we can install software without internet access anymore, so maybe it's time to move on.
I don't think you need to pay for a domain, nor do you need internet access to renew the certificate. You could either just have the cert point to an IP, or you could have the domain resolve to something at the router level/ configure our DNS however you like so that it resolves to the other device.
Or you can just disable the strict HTTPS settings, which this post addresses?
> 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.
Or you can just disable the strict HTTPS settings, which this post addresses?
> 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.
> I don't think you need to pay for a domain, nor do you need internet access to renew the certificate. You could either just have the cert point to an IP, or you could have the domain resolve to something at the router level/ configure our DNS however you like so that it resolves to the other device.
If I use a custom root CA, I don't need a domain. However, then my local server will only be accessible on devices where I can install the custom CA, i.e. usually, my own devices only.
If I want the server accessible to other people, I need a cert from a real CA - and those are basically forbidden from granting certs for 192.168.* IPs or really anything that is not a properly registered internet domain:
https://www.globalsign.com/en/blog/certificates-for-internal...
> Or you can just disable the strict HTTPS settings, which this post addresses?
That as well works for my own device, but not for devices of other people.
If I use a custom root CA, I don't need a domain. However, then my local server will only be accessible on devices where I can install the custom CA, i.e. usually, my own devices only.
If I want the server accessible to other people, I need a cert from a real CA - and those are basically forbidden from granting certs for 192.168.* IPs or really anything that is not a properly registered internet domain:
https://www.globalsign.com/en/blog/certificates-for-internal...
> Or you can just disable the strict HTTPS settings, which this post addresses?
That as well works for my own device, but not for devices of other people.
So the situation is that someone is in your home with their own device and you don't want them to click through the "HTTP" warning? Seems niche tbh but I can understand that I guess.
The HTTP warning may become progressively harder and more confusing to click through, if chrome continues its strategy as they announced in the OP.
Usecases would be more something like "shared server in a student dorm / local server for family and friends / art installation where people are supposed to connect their phones to / smart device with a local web server for configuration", etc.
Niche indeed compared to the public internet, but still substantial.
Usecases would be more something like "shared server in a student dorm / local server for family and friends / art installation where people are supposed to connect their phones to / smart device with a local web server for configuration", etc.
Niche indeed compared to the public internet, but still substantial.
How substantial are the situations really where you can't afford a 10-15$ domain and running a trivially simple tool to obtain a certificate? What kind of an art installation has the budget to set up a wifi network, set up servers, etc but then doesn't have internet? (Most phones won't even connect to a wifi network without internet if I remember correctly.)
Is there a way to do this for default Chrome installs? The whole point of hosting something for LAN is so family members can use the site on a whim from their iphone.
AFAIK Chrome uses the OS certificate store, so you should just need to provision your CA in the OS itself.
For iPhones you may be able to use configuration profiles, which are also useful if you want to set up stuff like email accounts, etc. However, it's been a while since I made on of those, so I don't know if you can use it for certificates. You may have better luck with Letsencrypt instead.
For iPhones you may be able to use configuration profiles, which are also useful if you want to set up stuff like email accounts, etc. However, it's been a while since I made on of those, so I don't know if you can use it for certificates. You may have better luck with Letsencrypt instead.
You can use it for certificates, it just looks like there's an extra step to say that you really trust it as a root:
https://support.apple.com/en-us/HT204477
That extra step is only required when you deploy the certificates through one of the less secure methods:
> You must manually turn on trust for SSL/TLS when you install a profile that is sent to you via email or downloaded from a website.
The more secure deployment methods do not require this:
> Apple recommends deploying certificates via Apple Configurator or Mobile Device Management (MDM). Certificate payloads are automatically trusted for SSL when installed with Configurator, MDM, or as part of an MDM enrollment profile.
Both of these quotes are from the link you provided.
> You must manually turn on trust for SSL/TLS when you install a profile that is sent to you via email or downloaded from a website.
The more secure deployment methods do not require this:
> Apple recommends deploying certificates via Apple Configurator or Mobile Device Management (MDM). Certificate payloads are automatically trusted for SSL when installed with Configurator, MDM, or as part of an MDM enrollment profile.
Both of these quotes are from the link you provided.
I figured most people looking to do this at home wouldn't have a home MDM solution to deploy it with. You're right though that it could probably be done with Apple Configurator fairly easily.
I’m planning and in process of doing the same. I am trying to figure out how to easily automate it, though.
Pork bun offers automatic ssl, but I’m not sure how that works. My servers would still all need to download a PEM or w/e right? So while support for that sort of feature is neat, I still need to automate pulling the certs. May as well just do it directly from LetsEncrypt and modify the DNS .. maybe.
I dunno, still exploring.
Pork bun offers automatic ssl, but I’m not sure how that works. My servers would still all need to download a PEM or w/e right? So while support for that sort of feature is neat, I still need to automate pulling the certs. May as well just do it directly from LetsEncrypt and modify the DNS .. maybe.
I dunno, still exploring.
Yes, you need a way to distribute the certificate PEM to your servers. The key PEM you have to generate yourself. However, nothing mandates that the server using it needs to have direct internet access, see my explanation here: https://news.ycombinator.com/item?id=37153485
That sounds intriguing, could you please elaborate?
I assume you are interested in the Letsencrypt part. Basically, I'm running an Ansible script on my computer, which creates an account key, the server key and requests a certificate. The server key and the certificate are then distributed to the servers that need them, leaving the original account key only on my machine. The Letsencrypt verification happens via my DNS provider, which happens to have an Ansible module.
Here's the source code: [link redacted]
Here's the source code: [link redacted]
“Not Self-signed” and “on the internet” are not the same thing.
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
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
This is interesting to me. How would the DNS work without touching the internet? Or do you mean to say that only DNS touches the internet and rest of the site would be offline?
If I made some cool security-camera image-recognition project with YOLO and wanted to sell installs to my friends in the area, would I need touch their DNS settings too? Personally: I feel uncomfortable changing settings on other folk's routers. If I could get away with helping them set a static IP without touching anything else, I'd much prefer it.
If I made some cool security-camera image-recognition project with YOLO and wanted to sell installs to my friends in the area, would I need touch their DNS settings too? Personally: I feel uncomfortable changing settings on other folk's routers. If I could get away with helping them set a static IP without touching anything else, I'd much prefer it.
You can have a local DNS server that tells computers on your network where to find intranet-hosted applications. I use my Pihole for that purpose, but you can set up a regular DNS server just as easily.
In my case, my router just has a setting for what DNS server to use, and I point it at my local DNS instead of 1.1.1.1 or whatever.
In my case, my router just has a setting for what DNS server to use, and I point it at my local DNS instead of 1.1.1.1 or whatever.
You can buy a domain, put public NS servers on it for the only purpose of doing Letsencrypt DNS validation. Hint: Create root and wildcard (eg domain.ca and *.domain.ca) so you aren't leaking internal DNS records (not that it matters much).
You run an internal DNS server (Pihole + unbound is my combo of choice) which becomes authoritative for your internal LAN.
You run an internal DNS server (Pihole + unbound is my combo of choice) which becomes authoritative for your internal LAN.
The site can be served only within your local or private networks and use HTTPS. The certificate is issued using a DNS challenge, for a domain that you own.
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.
Check us out: https://www.getlocalcert.net/
Check us out: https://www.getlocalcert.net/
Blog post author here.
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.
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.
You can right click on the address bar and check the option "Always show full URLs" if you want to see the protocol still.
They're making these changes for the average user who doesn't know the difference and who can't tell if a site is secure or not based on the protocol part (or who misinterpret what it means in terms of security vs trustworthiness). The padlock is no longer green in Chrome and will be going away next month too. The states will just be secure (no warnings) or not secure (displaying a warning). It shouldn't be something people have to think about in this day and age unless there is a problem (e.g. cert expired, cert mismatch, not encrypted at all) as sites should just be secure by default.
They're making these changes for the average user who doesn't know the difference and who can't tell if a site is secure or not based on the protocol part (or who misinterpret what it means in terms of security vs trustworthiness). The padlock is no longer green in Chrome and will be going away next month too. The states will just be secure (no warnings) or not secure (displaying a warning). It shouldn't be something people have to think about in this day and age unless there is a problem (e.g. cert expired, cert mismatch, not encrypted at all) as sites should just be secure by default.
[deleted]
If you own a domain it's trivial to request a certificate for it using just DNS. There's no need to expose anything to the internet.
This. Also, plain old http is appropriate for many project is and many websites. Sure, https first, but let's not make it https only.
"HTTPS only" is Google's end goal though. There is already the rule that all new web features are only enabled for https. As they write in the OP, it's possible that plaintext http will even lose features in the future that are still supported currently, like long-lived cookies.
> I DO NOT want to put my family's or my personal-project data on the internet!
Use Firefox?
Use Firefox?
Its not as easy as you think to convince your friends/family to install new web browsers. Websites should just work
Websites do just work, the browser doesn't. "You can't access the internal LAN because your browser is bad" should be a compelling reason for them to change.
A non-technical user doesn’t know that. They just know a site isn’t displaying correctly.
[deleted]
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.
For example something like this: https://arminreiter.com/2022/01/create-your-own-certificate-...
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-...
So somebody who doesn’t know what they’re doing should roll out PKI, which if compromised would result in the ability to inspect encrypted payloads for all websites they visit, including banking. Because there’s no excuse for not TLS. Got it.
Yes, that's nice and all if you only want to access the server from your personal phone/laptop/etc.
It doesn't help at all if you want to show the server to others.
It doesn't help at all if you want to show the server to others.
I think people are missing this:
> 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.
> 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).
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.
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.
"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.
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.
If you're writing HTML directly and SFTPing into a server, you probably are also using a shared hosting platform that offers Lets Encrypt. You don't even need to touch a config file or install certbot in that case, you literally just click a button. If your host does not offer Lets Encrypt there are hundreds that will host bare files and do offer encryption, and migration is as simple as copy-pasting files and transferring the domain.
If the owners are unreachable or dead you have bigger problems to worry about then having to click through to an unencrypted site. Dead people can't pay hosting bills.
I get what you're saying with centralization but LE is not the only central point of failure here. The old web would not survive, say, VeriSign deciding to make .com worse or ICANN deciding to kill DNS. At least we can switch CAs.
If the owners are unreachable or dead you have bigger problems to worry about then having to click through to an unencrypted site. Dead people can't pay hosting bills.
I get what you're saying with centralization but LE is not the only central point of failure here. The old web would not survive, say, VeriSign deciding to make .com worse or ICANN deciding to kill DNS. At least we can switch CAs.
Totally agree. Old forums and personal websites are some of the best resources on the web for many topics outside of current events. Google Search already downranks them in favor of more corporate results, and this Chromium change will hurt that part of the web even more.
It's maddening that so many people in tech seem oblivious to the fact that most people in the world interact with the web totally differently than them and have very different interests. Google in particular can be so hostile to people who couldn't care less about the latest tech trends and just want the stuff they care about to work with minimal fuss.
It's maddening that so many people in tech seem oblivious to the fact that most people in the world interact with the web totally differently than them and have very different interests. Google in particular can be so hostile to people who couldn't care less about the latest tech trends and just want the stuff they care about to work with minimal fuss.
> I object to breaking the old web.
Just click through the warning.
Just click through the warning.
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.
I just think that's significantly different from "breaking" the old web. Nothing is broken.
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.
> 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.
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.
Just imagine 10-year-old-us trying to build a website now, and some megacorp slapping us down and saying ‘No TLS no excuse!’
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.
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?
>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.
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.
No on is advocating for HTTP only. We're saying webservers should be HTTP+HTTPS.
> 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.
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.
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.
> 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).
neverssl.com is a legitimate use case (though the fact that it's even needed is unfortunate).
`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.
The click-through is already cumbersome and hidden by default. I wouldn't be surprised if it was soon deprecated altogether.
> How do they know this?
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
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.
But who am I kidding, given who we're talking about, I doubt that's what's happening.
Chrome is an extension of Googles ad empire, it spies in you.
It is publicly available data from Chrome's non-URL keyed metrics system. https://transparencyreport.google.com/https/overview?hl=en
> How do they know this?
I'd assume through ga.js (and urchin.js).
I'd assume through ga.js (and urchin.js).
> How do they know this? That's frightening.
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.
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.
Is "percentage of sites visited that are HTTP vs HTTPS" "personal" or "sensitive" to you? And if so... how?
Yes, all of my data is sensitive to me. I don't want Google knowing anything about me, including when I use their software.
insanitybit(1)
HTTP is transparent, human-readable, decentralized, locally hostable without extra work, simpler, lighter, and much more widely compatible.
It’s what I’m planning to stick with for the foreseeable future.
It’s what I’m planning to stick with for the foreseeable future.
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)
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.
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.
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.
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.
[deleted]
In a world with WebDRM (aka the Web Environment Integrity BS) if you are modifying the environment like that it should fail the attestation and the web app that wants to exfiltrate data would just refuse you service.
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.
All browser vendors are behind this, even mozilla, this is a global conspiracy to crack down on the open internet.
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!