Towards HTTPS by Default
blog.chromium.org
blog.chromium.org
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!
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?
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...
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.
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?
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.
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.
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.
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.
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'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.
Don't expose your local stuff over the internet without encryption. The ISP doesn't need to see that.
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)
What are you on about? How does the router not having a valid certificate mean it “can’t go online”?
Sure, you could leak said CA, but it's only going to leave you in the same position as HTTP.
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.
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.
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.
It's working, it just ensures that absolutely everything needs internet access.
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.
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.
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.
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 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.
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.
Here's the source code: [link redacted]
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
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.
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 run an internal DNS server (Pihole + unbound is my combo of choice) which becomes authoritative for your internal LAN.
Check us out: https://www.getlocalcert.net/
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'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.
Use Firefox?
"Because Chrome is enforcing security standards that--"
"I don't care anymore. I'll keep using the internet I use now."
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-...
It doesn't help at all if you want to show the server to others.
> 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.
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).
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 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 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.
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.
Just click through the warning.
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.
TFA is about moving all http:// navigations to https:// and requiring explicit permission to access content over http://.
A local file is not served over HTTP.
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.
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.
neverssl.com is a legitimate use case (though the fact that it's even needed is unfortunate).
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
But who am I kidding, given who we're talking about, I doubt that's what's happening.
I'd assume through ga.js (and urchin.js).
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 what I’m planning to stick with for the foreseeable future.
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)
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.
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.
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.
All browser vendors are behind this, even mozilla, this is a global conspiracy to crack down on the open internet.