Wondering Why Your Internal .dev Web App Has Stopped Working? (theregister.co.uk)

Kieren McCarthy, writing for The Register: Network admins, code wranglers and other techies have hit an unusual problem this week: their test and development environments have vanished. Rather than connecting to private stuff on an internal .dev domain to pick up where they left off, a number of engineers and sysadmins are facing an error message in their web browser complaining it is "unable to provide a secure connection." How come? It's thanks to a recent commit to Chromium that has been included in the latest version of Google Chrome. As developers update their browsers, they may find themselves booted out their own systems. Under the commit, Chrome forces connections to all domains ending in .dev (as well as .foo) to use HTTPS via a HTTP Strict Transport Security (HSTS) header. This is part of Google's larger and welcome push for HTTPS to be used everywhere for greater security.

Comments

Simple solution

[smooth wombat]

Don't use spyware posing as a web browser.

Wondering Why Your Internal .dev Web App Has Stopp

[oobayly]

Because you didn't use a reserved TLD you numpty. The same people probably use non-private subnets for their internal networks and then wonder why some websites that had the audacity to use that IP don't work...

Re: Did the cool-aid taste good?

[fisted]

While I'm not a fan of Zero__Kelvin, he is right. Client authentication is extremely rare in https connections. (And the average technological understanding on /. is absolutely shit)

In case you don't understand what that means: The client neither has nor supplies any cert in the TLS handshake, therefore there is no cert that can act as a cookie of whatever kind.

Re:Fuck off with this security bullshit.

[metamatic]

And CERT has warned against using your own internal made-up top level domains...

https://isc.sans.edu/forums/di... ...which is why there's an RFC listing reserved top level domains you can safely use:

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