Hacker News Reader

Comment by CydeWeys | Hacker News Reader

Hey 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.

View on HN

I bet you can't answer the actual most likely question: What are you (Google) planning on doing with .dev domains anyway?

However besides that...just curious: Will Chrome honor a header to disable HSTS for preloaded domains? (e.g. Strict-Transport-Security: max-age=0)? And what is going to happen if I submit my .dev site for removal from https://hstspreload.org/ ?

Also, reading the rules on hstspreload.org, I see the following statement: "Don't request inclusion unless you're sure that you can support HTTPS for your entire site and all its subdomains the long term"

Since you cannot actually guarantee that every .dev site will support HTTPS considering the fact that many developers use it on their LAN...don't you think you're breaking the rules here and possibly causing more problems than solutions?

I would love to be able to answer that first question for you. Unfortunately I have nothing to share yet.

My understanding is that HSTS carveouts are supported by Chrome but not yet other browsers. There's more standardization work to be done there. That said, you can only request entries on the HSTS list for domains that you own, and since no one (yet?) owns any .dev domain names, no one could request such changes. It goes without saying why you can only change security settings for domain names that you own.

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.

> And for the last question: Again, there are no .dev domain names. There never have been. It's never been available for registration.

It is, however, in widespread practical use.

> 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

If taken to its extreme, that recommendation would mean that any kind of internal hostnames - even dotless ones - are subject to potential override unless they are tied to a public DNS entry.

As indeed they actually are. WWW browsers have a search path, that is added on to a second search path mechanism that DNS client libraries have. Domain names with dots in, but that are not fully qualified, suffer from this. Yes, this means that what http://wibble/ is right now is subject to change; and even http://wibble.wobble/ could be, depending from various factors.

* http://jdebp.eu./FGA/web-fully-qualified-domain-name.html

Would that I had recorded the case some while back where, when I pointed this out, someone chimed in to note that xe had worked for a company that had actually taken advantage of this in order to usurp external WWW sites.

And then there was WPAD.

* http://jdebp.eu./FGA/web-browser-auto-proxy-configuration.ht...

This is not taking things to an extreme. This is reality right now and has been for many years.

I wasn't aware of that. Thanks for the info!

Yes. That's why it's recommended to have a subdomain of a domain you own under which all internal names live. (no need for it/them being in public DNS though)

> 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.

I disagree that this is something that Google needs to do on my behalf. If a cybersquatter squats on <my-startup>.dev, I don't consider it broken if I can't access their squat page. If I'm overriding random domains without doing my due diligence, then I get what I deserve (and probably wanted the results anyways). If somebody is spoofing a domain as a method of cyber attacking, the domain owner should have had HSTS if they had dignificant digital assets and they would already be using a non .dev domain.

"If I'm overriding random domains without doing my due diligence, then I get what I deserve."

I mean, that is exactly what is happening here, so it sounds like you get it. We aren't doing things on other people's behalf; HSTS is part of our plans.

An interesting consequence of your last question, is that if Google added .dev and .foo to the HSTS preload list, it means they don't intend to make these domains available for public registration at all. If they did let people register them, they would have no way to enforce that the sites on there honored the hsts requirements.

That doesn't follow. Sites that did not abide by those requirements simply would not work. The requirements are enforced by the browser.

The intention when registering such a domain name would be to follow said requirements, otherwise you wouldn't be able to use the domain name for hosting websites (though you could of course still use it for other services).

Not to defend plaintext HTTP, but what you describe is a DNS registrar that mandates which services can be used with the registered domain... Would you buy a house where you cannot cook, only microwave?

The house analogy doesn't really work as you could always install a stove. A better example would be "Why would you buy a plot of land that is zoned residential if you can't build an office building on it?" The answer is that you know what you're getting into before you buy it, and so you'd only buy it if you were building a house. If the restrictions are known up front then it's all good. I'd also like to point out that HSTS has very real security benefits, and if the entire TLD is already on the list then you don't have to go through the hassle of adding all your domains individually and waiting months for those updates to roll out widely. The expectation is that the pros vastly outweigh the cons.

There are already TLDs that restrict who can buy them or what kind of website you can run on them. How is mandating HTTPS categorically different?

Sorry for the lack of knowledge, but what is actually contained in the preload lists? Just a flag "force TLS and activate HSTS" or also a certificate pin?

I.e., could you actually use your own certificate for a .dev site or would the browser only accept Google's?

We are only use certificate pinning for .google. The only requirement on any of the other TLDs is that you must have an SSL certificate and serve over HTTPS.

One of greatest things about the Web is how easy it is to write HTTP clients and servers. I see why HTTPS everywhere would be helpful, but I also think it would be a shame to lose this simplicity. Has there been any thought put toward simpler alternatives to HTTP+TLS?

It's easy to write a simple HTTP client or server that works for the happy path of the exact software you tested it with. Writing one that follows the RFCs and doesn't allow various security holes when the RFCs are violated is much harder. HTTP is not a simple protocol.

> Has there been any thought put toward simpler alternatives to HTTP+TLS?

Well, many people think that current TLS is too complicated and in part that discussion led to TLS 1.3. While I'm still not entirely happy with the complexity, it is far less complex than TLS 1.2.

TLS 1.3 removes a lot of the options that 1.2 had.

That's way outside my area of expertise. I don't think HTTPS is that bad anymore, not now that certificates are easy to obtain. What are your biggest pain points?

More broadly, I think it's worth incurring some inconvenience for the sake of security. Go too far in the other direction and you end up like Equifax.

I think he's just wistfully hoping for a return to simpler times, when it was easy to construct your own HTTP server, just using sockets APIs.

Security's complicated, is the real answer :/

But you can't exactly just skip it (witness Equifax).

Think of all the time we heard about people stealing passwords from HTTP over wifi networks..

Forcing security at multiple levels and making HTTPS easier is the way forward.

You may want to read up on DANE.

https://tools.ietf.org/html/rfc6698

Not really an alternative to HTTP+TLS, but possibly another way of doing it depending on how it's implemented.

Yeah, 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.

.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.

Do you think this plan might encourage developers to develop using another browser?

What 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.

You never should have been using it, though? It wasn't your domain to begin with or your TLD.

It's like complaining that you're using appname.ycombinatordev.com as a development suffix, then someone registers it and all your stuff breaks, and you want them to fix your problem.

It isn't good practice to use random domains or TLDs that you don't own for testing. At work we have a separate publicly-registered domain, and an internal subdomain with NS records on the primary publicly-registered domain that resolves separately. It's never been a problem..

You should not be using domain names on .dev unless you own them (which no one does .. yet). If you choose to do so it's at your own risk.

So, kill off lan-level caching http proxy servers? (Or force a choice between trust the cache with everything; including email etc - or - no caching of signed software updates and common media resources?)

I'd be less unhappy about this if web browsers (and application updaters) understood x509 ca cert limits, so you could tell a device to trust the lan cache to impersonate Debian.org, windowsupdate.com and BBC.com - but not Gmail.com...

Do you plan on DNSSEC signing subdomains of Google's TLDs?

For example, I see that .dev has a DS record in the root. But nic.dev is not signed.

Do you have a solution for IoT devices that want to serve a webpage with HTTPS? For example my router or an IP camera?

Reply on news.ycombinator.com