Slashdot Mirror
Chrome To Force Domains Ending With Dev and Foo To HTTPS Via Preloaded HSTS (ttias.be)
Developer Mattias Geniar writes (condensed and edited for clarity): One of the next versions of Chrome is going to force all domains ending with .dev and .foo to be redirected to HTTPs via a preloaded HTTP Strict Transport Security (HSTS) header. This very interesting commit just landed in Chromium:
Preload HSTS for the .dev gTLD:
This adds the following line to Chromium's preload lists:
{ "name": "dev", "include_subdomains": true, "mode": "force-https" },
{ "name": "foo", "include_subdomains": true, "mode": "force-https" },
It forces any domain on the .dev gTLD to be HTTPs.
What should we [developers] do? With .dev being an official gTLD, we're most likely better of changing our preferred local development suffix from .dev to something else. There's an excellent proposal to add the .localhost domain as a new standard, which would be more appropriate here. It would mean we no longer have site.dev, but site.localhost. And everything at *.localhost would automatically translate to 127.0.0.1, without /etc/hosts or dnsmasq workarounds.
Preload HSTS for the .dev gTLD:
This adds the following line to Chromium's preload lists:
{ "name": "dev", "include_subdomains": true, "mode": "force-https" },
{ "name": "foo", "include_subdomains": true, "mode": "force-https" },
It forces any domain on the .dev gTLD to be HTTPs.
What should we [developers] do? With .dev being an official gTLD, we're most likely better of changing our preferred local development suffix from .dev to something else. There's an excellent proposal to add the .localhost domain as a new standard, which would be more appropriate here. It would mean we no longer have site.dev, but site.localhost. And everything at *.localhost would automatically translate to 127.0.0.1, without /etc/hosts or dnsmasq workarounds.
Maybe use browser other than Chrome??
Light travels faster than sound. This is why some people appear bright until you hear them speak.........
And yet another reason not to use communist-Chrome.
I propose that *.localhost resolve to 127.0.0.1, AND that the Host: header exclude the .localhost portion so I can have identically configured test/production systems, without having to dick around with toggling /etc/hosts, or dick around with ServerName configuration changes when pushing from dev to prod.
Will Firefox be doing this too? Do web designers and devs even use Firefox these days?
.test is an IETF standard for this purpose. .dev never was. Google own .dev, and they own Chrome, so they are perfectly welcome to do this. We could argue as to whether a browser that enforces per-domain protocols is truly adhering to browser standards (and the larger ramifications if every browser coder started doing the same), but accept that you have zero right to use .dev as your personal fiefdom and move on to something that will remain easier for you to maintain.
And everything at *.localhost would automatically translate to 127.0.0.1, without /etc/hosts or dnsmasq workarounds
Cmon, we aren't talking some crazy complicated configuration here. DNSMasq: add "address=/localhost/127.0.0.1" to your config file. Boom. Done.
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
I use the .local domain on my home network. Those IP addresses are definitely not 127.0.0.1. I have no interest in changing to .localhost and/or setting up certificates for my intranet websites.
" we're most likely better OF changing our preferred local development suffix..."
that Google has. They already broke the "-ignore-certificate-errors" flag which was driven by their hate. I often have to change my clock for testing, and Google made the decision that I should not be allowed to use the web. We use Let's Encrypt certs that area also pretty hatefully limited to 90 days so they waste so much of our time having to maintain them, so you can't move your clock that far forward or backward before Google decides you shouldn't be able to work.
Seriously, how is this even an issue? You can get free certs and there's so countless walkthroughs on how to setup TLS for almost any server (with Mozilla's being the best imo). With ISP's consistently showing they have no respect for your content or anyone else's it's hard to justify NOT running TLS on a web server.
Both the problem and the solution have been known for a long time, now. Google hasn't exactly been shy about telling people to stop using *.dev
If you are big enough that this matters to you, then you can afford the minimal cost to register a proper domain. A quick search suggests that you can get a *.top domain for less than $6/year. And it's not as if *.com costs all that much more. If you already have a domain, then you could even continue using "dev", by making it a subdomain for your primary domain name. If your business depends on it, then it would be foolish to not spend this tiny amount of money and to instead rely on a hack. Incidentally, having a proper domain means you can also get free SSL certificates from Letsencrypt. That's important, as a lot of advanced Javascript features are only available for HTTPS protected sites.
On the other hand, if you are 1) a hobbyist, 2) don't need modern browser features and, 3) can afford occasional downtime, then yes, by all means, "invent" some domain name and hope for the best. Usually, the recommendation would be to use something in the *.test TLD which has explicitly been set aside for testing purposes. But there is no guarantee this will continue working. So, you could try experimenting with *.localhost instead and hope for the best.
How about: Don't use a gTLD for your local DNS?
Also, why are you doing web development without HTTPS unless you're planning on never using it? It's not like certificates cost anything. There's also nothing stopping you loading your own CA cert and signing your own certificates too.
Browsers behave differently based on the protocol. Building against one set of rules and deploying against another is just asking for problems.
I've been using ".local" for years. I'd have no problem with ".localhost".
RFCs exist for a reason. .dev and .foo are not intended for use as private TLDs. Consult http://www.faqs.org/rfcs/rfc2606.html
Google has the exclusive rights to two gTLDs, .dev and .foo. Why?! The names are quite generic and have nothing to do with Google explicitly, and they abused their status to claim that they should be able to keep this stake for their own. And now they're tired of other people using these gTLDs internally and are forcing everyone to change with this Chrome update.
They can have .goog and .google and .googleplay and .shitfuck and whatever else, just let us register domains under .dev and .foo.
The .dev tld is widely used for development and should never have been assigned to Google. .... ditch it.
If Chrome causes problems
google's getting a bit too controlling for my tastes
How the fuck are you supposed to use Let's Encrypt for internal/fake domains you haven't registered and don't control, and that aren't running a publicly accessible web server?
Start creating sites that don't break as soon as you start using TLS 1.2.
Seriously are people really using .dev URLs to point to local resources where there could be a name collision with a real TLD? So you have a bunch of links to [].dev that people have stored. And then they switch networks where .dev resolves correctly and they start erroneously sending data to third parties. And we don't all see why that is an awful problem? /. is starting to sound like its the new hangout for Equifax CSO candidates.
Advanced JavaScript features, lul.
You are just realizing this? They've been this way.
We registered a domain name that we use for all internal URLs (i.e. [ou].local.[domain].[tld]). I was under the impression that doing this has been considered a best practice for several years, since it avoids the problem the summary describes.
You don't, you use self-signed certificates and put the CA into /etc/ssl/certs
Custom electronics and digital signage for your business: www.evcircuits.com
We're at the point now where using https is so easy, that there's very little reason to not use it. The biggest stumbling blocks had always been obtaining the certificate and vhost/IP limitations on certificates. But those are now taken care of with Lets Encrypt and recent changes to how certificates are handled.
Given the current technical and political climate, HTTPS should be the default for *everything*, barring very special circumstances.
But it's a real pain for anything that you ship with a web interface, and expect to work unmodified for a long period of time.
Sure, that's a niche use-case, I get that, but not everything that's accessed by a web browser is something easily updated, and why should it be? If I build some device that's intended to be put on my local network, and give it a web interface, - like, say, a home router - will I be required to implement HTTPS on the device, and have it ship with a cert? A cert that expires after a relatively short period of time?
I happen to have an old computer lying around the house, and it can't run anything more modern than Chrome from about eight years ago. This browser is able to access anything on the web, other than newer HTTPS sites, because it doesn't understand their certificate. By building these mechanisms of trust, and then constantly changing them (for instance, change from Common Name to Subject Alternate Name - and whatever it is that old Chrome hates about modern certs), we are locking ourselves out of notions of backwards compatibility, and increasing the rate at which we have to throw away our devices, because we can't afford to release OS updates for old hardware, and can't afford to release browser updates for old OSs.
I get that we're talking about security here, and trust, but I personally see a high cost. Plain HTTP is great. HTTPS is a moving target, and seems like it will remain so.
It seems like once a week I'm given a new reason to be happy that I don't use Chrome.
Web browsers require HTTPS server operators to obtain a fully-qualified domain name and a certificate from a certificate authority trusted by the browser publisher. Though Let's Encrypt makes certificates available without charge to domain owners, the domain itself still requires a recurring payment to a third party. The requirement to own a domain and keep it renewed imposes an extra $15 per year (source: Gandi.net) tax on running a server inside a home LAN.
1) Buy a domain name for a few dollars
And then do what after it has expired?
Chrome doesn't run on iOS either. Instead of Chrome, Google publishes Chrome-for-iOS. The difference between Chrome and Chrome-for-iOS is that while Chrome uses the Blink engine, Chrome-for-iOS uses the same Apple WebKit engine as Safari, as required by the App Store Review Guidelines. This means that if Apple declines to support a particular web API in Safari, it'll be unsupported in Chrome-for-iOS as well.
Then how does one obtain a certificate for a domain in .test and use it on all devices on a home LAN? I thought Android 7 "Nougat" and later didn't trust user-installed root certificates unless a particular app opts into trusting user-installed root certificates through the network security config file in the application's package. Chrome for Android appears to opt in, but Firefox for Android is untested. Using cleartext HTTP is not an option because more sensitive APIs are unavailable outside secure contexts.
As of Android 7 "Nougat", Android apps distrust Android's counterpart to /etc/ssl/certs by default. In addition, I haven't tested all major models of media player appliance that stream from a web server running on one's home NAS, but I imagine some have no user-editable counterpart to /etc/ssl/certs.
Whoever the hell "foobar@example.com" is, they have received a shitload of shit from our team over the years.
Table-ized A.I.
So what should a hobbyist who needs modern browser features do? Or especially a non-technical PC owner who has installed web server software on his home PC and set it up for internal access only, so that visiting friends and family can view videos stored on the home PC that the PC owner has chosen to share?
Also, why are you doing web development without HTTPS
I am developing software that runs on a PC on a home LAN, and I've never seen anyone get HTTPS working with multicast DNS and DNS-SD.
This gives me an idea. gTLD wide HSTS should be done for some other gTLD as well. I'm thinking like *.bank and the like. It just forces any user of that gTLD to be at least somewhat security conscience and adds some good public reputation to those select gTLD. A private company that owns a gTLD could use this to increase the value of their gTLD because it will have a reputation of being more secure.
Modded +5, Informative, but both of its statements are inaccurate. .localhost is reserved for 127.0.0.1 and no other thing. .invalid is reserved for NO use, it should never resolve.
https://tools.ietf.org/html/rf...
Localhost:
Name resolution APIs and libraries SHOULD recognize localhost names as special and SHOULD always return the IP loopback address for address queries and negative responses for all other query types. Name resolution APIs SHOULD NOT send queries for localhost names to their configured caching DNS server(s).
Invalid:
Name resolution APIs and libraries SHOULD recognize "invalid" names as special and SHOULD always return immediate negative responses. Name resolution APIs SHOULD NOT send queries for "invalid" names to their configured caching DNS server(s).
Neither of these are meant for use on a local internet. .localhost is meant to resolve to loopback, and .invalid is meant to never resolve but instead give NXDOMAIN.
Maybe there are domains reserved for private usage, but it ain't these two.
What everyone should have done is register a real domain and use subdomains of it for all of their local needs. This guarantees no collisions or issues ever. Until the end of time. Google isn't to blame for you being shortsighted and lazy.
But all of you were cheap bastards so embrace your karma.
If they demand the use of a TLD - They could use RFC compliant TLDs that cannot be reserved, such as .test. .example, .invalid, .localhost or alternatively, register a domain or TLD for themselves.
Change is certain; progress is not obligatory.
How about not using fake domains in the first place?
You don't need to own a domain for Let's encrypt; controlling a subdomain is enough.
Only if the subdomain is a subdomain of a domain in the Public Suffix List. Let's Encrypt limits how many certificates may be issued per domain per 7 days:
Because afraid.org is not in the Public Suffix List, no more than 20 certificates for subdomains of afraid.org will be issued in one week.
They could use RFC compliant TLDs that cannot be reserved
I agree that the operator of a home NAS should drop Google's TLD in favor of something like .test. But I imagine that visitors to the hobbyist's home are unlikely to successfully complete the process of adding the NAS's private CA's root certificate to their devices.
or alternatively, register a domain or TLD for themselves.
Which inflates the price of a home server appliance by that of a domain registration.
There are really cheap domains, but if that isn't good enough. There are quite a few free subdomain providers out there too, usually offering dyndns options and the like.
Change is certain; progress is not obligatory.
There are quite a few free subdomain providers out there too, usually offering dyndns options and the like.
The problem is that a lot of these free subdomain providers aren't listed on the Public Suffix List. For example, afraid.org is not. And if a domain isn't on the Public Suffix List, Let's Encrypt issues no more than 20 certificates per week for that domain. This means 20 other users of that same domain will probably have already obtained their certificates before you, causing Let's Encrypt to reject your attempt to obtain a certificate with an error message to the effect:
So it appears to be either A. use Let's Encrypt for the certificate and pay for the domain or B. use a free subdomain provider for the domain and pay Namecheap for the certificate.