12 ms·
Chrome to force .dev domains to HTTPS via preloaded HSTS
- tscs37 9y agoJust as a note; .dev is not yet an official TLD, it's on the status "proposed" which means that google is basically the highest priority on the waiting list. .foo is delegated and thusly a full TLD, yes. On the other hand, you should not be using .localhost if the target is not running on your loopback interface, resolving localhost to anything but loopback is considered harmful. I find .test or .intranet to be more useful for such installations, they are either designated as "cannot be a TLD" or are very very unlikely to become a TLD, respectively.
- mikl 9y ago> should not be using .localhost if the target is not running on your loopback interface, resolving localhost to anything but loopback is considered harmful. I have heard this before, but not really seen any great arguments as to why. Sure, `localhost` should not be bound to anything other than loopback, but I don’t see the harm in remapping `whatever.localhost` to the IP address of the Vagrant box running on your local machine.
- tscs37 9y agohttps://tools.ietf.org/html/draft-west-let-localhost-be-localhost-04 https://tools.ietf.org/html/draft-west-let-localhost-be-loca... The problem is that while the loopback addresses can be mapped as a secure context, even without HTTPS, .localhost. cannot since it might not be a loopback context. You can literally use anything else to map to your vagrant box including "whatever.i-dont-care" and "whatever.whatever". Remapping .localhost. destroys the implicit assumption of many developers that a .localhost. means loopback and rightfully the above draft proposes to force any resolve to either fail or resolve to loopback.
- mikl 9y agoWhich developers? I’ve never heard of anyone using whatever.localhost in their code, assuming it will map to loopback? Sane developers use localhost, or localhost.localdomain in some cases.
- tscs37 9y agoit's usually not in the code but in testing or dev environments. Makes developing multi-server apps a bit easier since I can point it all to loopback without worry. (Plus using multiple loopback addresses helps)
- lamby 9y ago> I find .test or .intranet to be more useful for such installations, Or, making a tradeoff from "accuracy" to "less magical" - ".chrome-hsts"
- tscs37 9y agoIf you really want to go down that rabbit holy: ".no-hsts" is still not taken, I believe so you can probably set it up as a private TLD in your hosts file.
- CydeWeys 9y agoUse one of the four TLDs from RFC 2606 that are guaranteed to never be delegated. Picking another random TLD that hasn't been delegated yet (but may be in the future) isn't a good idea.
- tscs37 9y agoTrue, but ".no-hsts" is unlikely to get HSTS enabled.
- CydeWeys 9y agoThat is far from the worst potential problem with using it, though. The biggest problem is if it does get delegated and you do not end up owning the actual "domain names" that you are using. You are now leaking web traffic to some unknown third party.
- wut42 9y agoI think you are wrong: * DEV is listed on the "delegated strings" page of ICANN[0] * `dig dev. ns +short` returns a couple of nameservers, the one of Charleston Road Registry: Google's registry. [0]: https://newgtlds.icann.org/en/program-status/delegated-strings https://newgtlds.icann.org/en/program-status/delegated-strin...
- tscs37 9y agohttps://icannwiki.org/.dev https://icannwiki.org/.dev The ICANN Wiki specifically lists the .dev domain as proposed, not delegated. Which means they can also just kill it and Google won't have it.
- wereHamster 9y agoWho do you want to trust more, the DNS root servers or a wiki (which might be outdated, because "This page was last modified on 1 August 2014, at 10:04"). Is the wiki even ran by ICANN, given it's on a separate domain, or by a separate entity or volunteers?
- dannyw 9y agoThe ICANN wiki is unofficial.
- wut42 9y agoI don't think this is up-to-date: * On https://www.icann.org/resources/agreement/dev-2014-10-16-en https://www.icann.org/resources/agreement/dev-2014-10-16-en you can see the agreement between ICANN and Charleston Road Registry to operate the TLD for 10 years * other pages on the wiki for TLDs that you can already register now still shows "proposed"
- noinsight 9y ago.test is an official IANA reserved special-use domain name that will never be delegated out. Use it. Problem solved. I don't know why people thought they could start using random TLD's on their own, there was always the risk they could be delegated officially. https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml https://www.iana.org/assignments/special-use-domain-names/sp...
- M4v3R 9y agoI always use .local when I have an app running on my machine locally. It's one of IANA's reserved special-use domains as well.
- okket 9y ago.local might be used for mDNS, mostly with Apple hardware.
- technion 9y agoAnd an issue most sysadmins would be familiar with unfortunately. For years, Microsoft's own guidelines suggested using .local for internal AD domains. Then one day, Apple started using it on mDNS, and Microsoft advice was suddenly "never use .local". But renaming an AD domain is painful and in many scenarios not supported at all, and people with domains more than a few years old are regularly pointed at Microsoft's recommendations and forced to explain the situation.
- snuxoll 9y agoAs far back as I can remember the domain creation wizard has yelled at you for using a non-delegated zone, .local was a stupid default they put into SBS and unfortunately it led them into a mess of saying “yes, this is OK” and “no, don’t do this” at the same time...
- quasse 9y agoUgh, our AD domain at work isn't even that old but was set up by some local consulting company and of course they used .local. It causes all sorts of grief when shared SMB drives won't resolve on linux, or you can't tell at first blush whether the DNS server is working properly or you just happen to have mDNS correctly resolving something for you on one machine (but not on another).
- andrewaylett 9y agoFor my development needs, I try to either: * Publish mDNS records to give myself extra `.local` names, or * Get a wildcard published in the organisation's internal DNS If you can't do either of those, _please_ use `.test` as your test TLD, as it's explicitly set aside for that purpose so you know you're never going to collide with anyone. https://tools.ietf.org/html/rfc2606#page-2 https://tools.ietf.org/html/rfc2606#page-2
- the_mitsuhiko 9y agoI would recommend against funky things on .local. It’s not a great idea either. I recommend just using a subdomain on a TLD you control.
- jwilk 9y agoWhat's funky about .local? It's an officially-registered special-use domain: https://tools.ietf.org/html/rfc6762 https://tools.ietf.org/html/rfc6762
- okket 9y agoThe .local TLD is reserved for mDNS requests, as the RFC states?
- the_mitsuhiko 9y agoFor the purpose of that RFC you linked.
- X-Istence 9y agoIf you use mDNS to publish things into .local then you are using it for what it was designed for. I wrote such a tool: https://github.com/bertjwregeer/mdns-announce https://github.com/bertjwregeer/mdns-announce It allows you to easily announce CNAME's in mDNS to do the sort of dev testing locally that requires alternate domains, without the possibility of leaking them outside of your own local network.
- X-Istence 9y ago
- noway421 9y agoWith .test thrown around a lot, would there be any complementary support from browser vendors for that TLD to be specifically a development tld? localhost is recognised to be one by chrome for example, that's the only domain where html5 geo api works without https, and "your passwords are transferred via plain text" is not displayed. In order to help shift to .test google might alter it's heuristics to recognise .test as a common tld used for development.
- jwilk 9y agoFrom https://tools.ietf.org/html/rfc6761#section-6.2 https://tools.ietf.org/html/rfc6761#section-6.2 : Application software SHOULD NOT recognize test names as special, and SHOULD use test names as they would other domain names.
- frik 9y agoI test with HTTP, locally. This forcing of opinionated things goes on my nerves. How about develop the browser, and let the mass decide what they use. Amazon was 100% HTTP for 20 years (except the single login page) - it worked very well.
- waibelp 9y agoSame here. Time to check out firefox :)
- pfg 9y agoMozilla uses Chrome's HSTS preload list. (Microsoft too.)
- waibelp 9y agoThanks for giving that hint!
- SquareWheel 9y agoI've never quite understood the preload list. Is its only job to save the initial 301 redirect from http > https on first load? Also, wouldn't bundling (tens of) thousands of domains start to add up, and slow down first page load for regular browser use? I'm sure I must be missing something, because this doesn't seem very logical to me.
- daenney 9y agoIn a way yes, it's trying to avoid the initial redirect. But not in order to save you from the potential latency of the initial redirect: > These sites do not depend on the issuing of the HSTS response header to enforce the policy, instead the browser is aleady aware that the host requires the use of SSL/TLS before any connection or communication even takes place. This removes the opportunity an attacker has to intercept and tamper with redirects that take place over HTTP. Read this: https://scotthelme.co.uk/hsts-preloading/ https://scotthelme.co.uk/hsts-preloading/ > Also, wouldn't bundling (tens of) thousands of domains start to add up, and slow down first page load for regular browser use? Why would it? Checking in a data structure if the domain the user requested should be loaded over HTTPS can be done in a perfectly efficient way. A hash table would give you O(1) lookup times on average and there's other things you can use to mitigate the worst case lookup of O(n).
- 0x0 9y agoWith all the hacks that people have put in place for using .dev locally, who in their right mind would want to even register and use a .dev domain? :P
- lucb1e 9y agoAs a developer, I never used .dev for development and I don't know anyone who does. The number of developers around the world is a small percentage of all users, let alone if not all of them have this redirect. And those who do probably use /etc/hosts, so your specific host needs to be in there (since the hosts file does, unfortunately, not do wildcards)... yeah, I think people are not going to have any second thoughts registering .dev domains.
- corobo 9y agoI use .dev via dnsmasq resolving *.dev to 127.0.0.1. I wouldn't register any dev domains though these are supposed to be throwaways based on the project (my "serve" script takes the folder name and uses that plus .dev as a domain) I'll just switch to .test as recommended elsewhere
- evolve2k 9y agoBasecamps open source project POW (http://pow.cx http://pow.cx), specifically configures rails projects to be automatically available at projectname.dev From the homepage "That’s it! Your app will be up and running at http://myapp.dev/ http://myapp.dev/. See the user’s manual for more information." I'm sure basecamp won't love this change and I'd guess many rails devs won't like this either.
- dbbk 9y agoAs does the popular Laravel Valet (https://laravel.com/docs/5.5/valet https://laravel.com/docs/5.5/valet) service in the PHP world.
- spiralganglion 9y agoLet's hope this issue gets some traction: https://github.com/basecamp/pow/issues/545 https://github.com/basecamp/pow/issues/545 It's a bit unnerving that the project hasn't seen an update since 2014, and has 100 open issues.
- Kipters 9y agoAnother option is not using Chrome as the main dev browser. Firefox replaces it just fine.
- onion2k 9y agoWeb developers test their code in all the browsers their audience use. Switching to a different browser isn't a solution. This isn't about what we use for personal web use.
- josteink 9y ago> Web developers test their code in all the browsers their audience use. If only. Those days are long gone. These days the majority of web-developers I see exclusively use Chrome and test in nothing else. Google seems to be encouraging this behaviour too, with web-pages promoting people use unfinalized APIs found only in Chrome for production websites. It's the new MSIE, for sure.
- Kipters 9y agoThis is why I said main. Most webdevs don't continously test in each browser they target, they usually just use Chrome and then check if things break in other browsers. And some don't even check at all.
- onion2k 9y agoIt makes me a little sad that there are still devs who haven't discovered the magic of https://www.browsersync.io/ https://www.browsersync.io/
- jwilk 9y agoFirefox imports Chrome's HSTS preload list. Sooner or later it'll enforce HTTPS on .dev, too.
- onion2k 9y agoI don't really see this as a problem. In fact, I wish Chrome would do that for every gTLD, but obviously that's not going to happen any time soon. Secure by default would be great. The real issue (for me at least) is that it's far too much of a pain to run an SSL secured site locally. It can be done, but doesn't work well across teams given you need to register your certificates locally. Being able to serve a site from a Vagrant box or a Docker container over https in a way that a browser will accept (or even just pretend to accept) would be immensely helpful. I'm sure web developers and browser vendors are trying to resolve the problem already, but it can't come soon enough in my opinion.
- deleted 9y ago[deleted]
- captainmuon 9y agoThey should do the opposite. There should be a .insecure domain where browsers accept HTTP or HTTPS with wrong or no certs, and pretend it is HTTPS with all consequences (e.g. loading of HTTPS third party resources). I wouldn't put it on the open net, but rather let people set it up internally for testing.
- hannob 9y agoJust commented over at Matthias' blog, I'll just copy-paste it here: First of all I think this is generally a good move. If people use random TLDs for testing then that’s just bad practice and should be considered broken anyway. But second I think using local host names should be considered a bad practice anyway, whether it’s reserved names like .test or arbitrary ones like .dev. The reason is that you can’t get valid certificates for such domains. This has caused countless instances where people disable certificate validation for test code and then ship that code in production. Alternatively you can have a local CA and ship their root on your test systems, but that’s messy and complicated. Instead best practice IMHO is to have domains like bla.testing.example.com (where example.com is one of your normal domains) and get valid certificates for it. (In the case where you don’t want to expose your local hostnames you can also use bla-testing.example.com and get a wildcard cert for *.example.com. Although ultimately I’d say you just shouldn’t consider hostnames to be a secret.)
- okket 9y agoThis is IMHO a very good practice and it will be even easier with the upcoming wildcard certificates from Let's Encrypt: https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html https://letsencrypt.org/2017/07/06/wildcard-certificates-com...
- user5994461 9y agoCompanies run their own CA. They can generate as many certificates for internal domains as they want.
- hannob 9y agoSome companies do, many don't. I don't recommend running your own CA unless you have a very good reason to do so. It's complicated and it introduces additional security risks.
- ehPReth 9y agoIf one absolutely must regardless please use name/IP constraints! Client support isn't super awesome from what I understand but it's much better than having an unconstrained root ('keys to the internet') on >1 client - especially if you can't go the nines to protect said key.
- hartror 9y agoUse .localhost pointing at 127.0.0.1 for local development. It is reserved for this purpose and obvious to everyone unlike .test. For reference your options are: .test .example .invalid .localhost https://tools.ietf.org/html/rfc2606 https://tools.ietf.org/html/rfc2606 With only .localhost fitting the purpose of most people's usage of .dev.
- tomjen3 9y agoSo what if I want to test a website under development from my phone? .test is more correct.
- chairmanwow 9y agoThis sounds like a really useful thing to do. How do you set something like this up in a dev environment?
- deleted 9y ago[deleted]
- TwelveNights 9y agoIf you use Chrome and have an Android device which also has Chrome installed, you could check out this tutorial: https://developers.google.com/web/tools/chrome-devtools/remote-debugging/ https://developers.google.com/web/tools/chrome-devtools/remo...
- hartror 9y agoIf you are sharing DNS on a private network then the convention is .local. https://en.wikipedia.org/wiki/.local https://en.wikipedia.org/wiki/.local
- michaelsbradley 9y agoFor quick and dirty arbitrary localhost domain names, I setup localhost.dog. Try: dig any localhost.dog dig any thing.localhost.dog dig any you.want.localhost.dog I find it useful, though its uses are admittedly limited. TTL is 30 days, but some resolvers (e.g. Google's 8.8.8.8, 8.8.4.4) dial it back to 1 day.
- kuschku 9y agoThe most annoying part here is that Google isn’t even using .dev as public TLD – they purely use it for internal testing, and all registered .dev domains resolve to 127.x.x.x addresses. .dev should have been entirely reserved, or made available publicly. Registering a TLD just for your own internal testing, and forcing everyone to switch away, is the most user unfriendly move you can do.
- CydeWeys 9y agoWe're not using it for internal testing. And specifically, the wildcard DNS entry for 127.0.53.53 is for ICANN's Controlled Interruption process. See here: https://www.icann.org/resources/pages/name-collision-ro-faqs-2014-08-01-en https://www.icann.org/resources/pages/name-collision-ro-faqs...
- kuschku 9y agoSo, why is this not documented with the TLD, or in any of the informational material? (And why is Google in the TLD market at all? Google’s already far too large as company – impossible to democratically control, any further growth of Google should be immediately and forcefully stopped).
- donatj 9y agoWe have always used local.{site}.com as a sub domain rather than tld. Makes CORS rules simpler, and we actually have a real dns record pointing to 127.0.0.1 so we don't have to bother with HOSTS
- CydeWeys 9y agoHey everyone. I'm the Tech Lead of Google Registry and I'm the one behind this (and likely future) additions to the HSTS preload list. I might be able to answer some questions people have. But to pre-emptively answer the most likely question: We see HTTPS everywhere as being fundamental to improving security of the Web. Ideally all websites everywhere would use HTTPS, but there's decades of inertia of that not being the case. HSTS is one tool to help nudge things towards an HTTPS everywhere future, which has really only become possible in the last few years thanks to the likes of Let's Encrypt.
- drivingmenuts 9y agoYeah, that's awesome, but many of us do test on our local machines where https would just be an extra layer of annoyance and having to use .localhost TLD would be icing on that annoying cake. Since it appears that .dev is a Google internal TLD, would you consider not forcing that rule outside of Google? Effectively, we're getting all the stick and none of the carrot. Alternately, announce your plans for .dev so as to bring some transparency to the process OR purchase maybe the .vm TLD and mark it for developer local testing in place of/addition to .localhost.
- CydeWeys 9y ago.dev is not an internal Google TLD. It is delegated but not yet launched (i.e. made available for registration). We don't use it for anything internally. You should not be using globally delegated TLDs for local testing. See RFC 2606. I don't see how using .localhost or .test is any more of an inconvenience than using .dev. Indeed it is less of an inconvenience because it will work without DNS shenanigans. The last round of gTLD expansion occurred in 2012 and there's still many years left until a potential future round. Additionally, .vm is not a valid gTLD because all two letter combinations are reserved for ccTLDs (countries). And I would love to have some plans to announce. Maybe soon.
- thawkins 9y agoWhat about providing a config switch in chrome etc to disable the new behaviour, so those of us that use .dev in our workflow can turn off the redirection.
- apatheticonion 9y ago*.localhost is a cool idea, would be cool if it allowed self-signed certificates as valid, or even have the browser do some magic and pretended it had an ssl certificate.
- ComputerGuru 9y agoI’ve never used .dev - but going back five or six years we set up a .dev sub domain of our domain and use that exclusively for development. dev.ourdomain.net is a web-accessible server on our local network, configured as the dns server for that sub domain and is our internal CA trusted to issue the certs we use for development.
- ramses0 9y agoSorry for top-leveling a grand-child comment, but reading between the lines, this is the attack vector: > And for the last question: Again, there are no .dev domain > names. There never have been. It's never been available for > registration. The recommendation for a long time has been to > only use either (a) domain names that you actually own, or (b) > domain names that are reserved for testing and are guaranteed > never to exist a la RFC 2606. Using domain names for testing > that don't yet exist but could in the future is a huge security > hole that you must fix now. Do it now while the domain names > still fail to resolve. Once they resolve, and you don't own > them, then your security situation gets a lot worse. Google is concerned with nation-state attacks. This means they have to assume ninja-assassin-scuba-divers have tapped all their cables underground. They're also concerned about ninja-assassin-usb-stick-droppers, and all kinds of other use cases. What they're doing is: 1) Requiring *.dev to match PRE-LOADED HSTS certs. This allows google to "safely" boot up a computer from scratch. Just so long as "clone-a-computer-from-scratch.dev" matches the public/private handshake for HSTS/HTTPS then google knows that no MITM, no nation state DNS takeover, etc. is possible. So long as the VERY FIRST CONTACT WITH THE INTERNET is a *.dev domain, then that computer can be "as secure as possibly known". 2) Forcing people to bounce "off" of invalid TLD's as a network administration method. Remember, google is concerned about nation states. Remember wanna-cry? How it was disabled by some random researcher registering xyz-abc-123.com? That attack costs $15. Now imagine a nation-state, intentionally registering a gTLD of "\*.haha-now-your-company-infra-is-pwnd" which they somehow glean is the gTLD your developers use for local development / testing / intranet portal. If you could spoof IBM's intranet by doing something like: "http://www.welcome.ibm" or "https://www.welcome.ibm" (b/c the *.ibm wasn't cert-pinned.....) then you could trivially cause *.ibm to resolve to some sort of spoofed site to collect passwords. Or what if they're catching `mysql -uroot -pxyz staging.product.ibm`? Whoops. Or... perhaps another gTLD we'll see google register is "*.go" or maybe their internal builds of chrome already do cert-pinning on that. (Reason is I've seen/heard they allow 'http://go/my-internal-shortlink' ... I know that other tech companies have had similar setups). Same attack vector. You control the DNS, you control ALL responses. And when somebody types www.microsoft.com, it may be _impossible_ to know if that "Down for Maintenance" banner is real or fake if their DNS is controlled by somebody who really is your enemy.
- hobarrera 9y agoThis is perfect and great. I'd love to see gradually (yes, GRADUALLY, without breaking anything!) all TLDs do this. ".localhost" has existed and been popular for local development for MANY years. I've no idea why somebody would use `.dev, but now that it's a registered TLD, using it locally is just asking for trouble. Also, you can just use 127.0.0.1, 127.0.0.2, 127.0.0.3, etc.
- scott_karana 9y agoYou can't show your app build to other people on the same LAN if you use .localhost. (Well technically you can, but it would be confusing ;)
- bpicolo 9y agoThe main issue here is how much of a PITA it is to work with HTTPS locally (totally true that .dev is the wrong thing to use for dev boxes here). Self signing certs and forcing /etc/resolver/ configs is only half of it. Then you run into trouble with mobile emulators, proxying, etcetc. We have an automated setup of it for devs, but it's out of necessity rather than anything else. It's a pain to deal with.
- xg15 9y agoThe article mentions as workaround: That means your local development machine needs to; - Be able to serve HTTPs - Have self-signed certificates in place to handle that - You'll have to click through the annoying unsecure site window every time Such fun. Part of HSTS is the requirement that certificate warnings become unskippable. So the above wouldn't work - you'll need an actual CA-signed certificate that is accepted by the browser, otherwise, you won't be able to access the site.