Wondering Why Your Internal .dev Web App Has Stopped Working? (theregister.co.uk)
311
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.
Fuck off with this security bullshit. (Score:5, Interesting)
We got hit by this, and promptly rolled back our browser versions. They're internal fucking development systems for fuck's sake, they're allowed to be insecure if **WE** want them to be.
I'm so sick and tired of dealing with this fucking nanny state of modern day technology where some dipshit developer thinks they know best, and they're just going to outright disable a feature that worked perfectly fine before.
So on behalf of all the developers at my company, fuck you Google. Keep it up, and we'll actually be inclined to go out of our way to strip out your shit and replace it with something else (which I'm told we're probably doing, given the lack of options to override this behaviour).
Re:Fuck off with this security bullshit. (Score:5, Insightful)
You don't own the .dev tld!
Re:Fuck off with this security bullshit. (Score:4, Insightful)
You don't own the .dev tld!
On a private network, yes, you do.
You don't own it on the Internet, but on your own network, you own every domain and TLD.
Re:Fuck off with this security bullshit. (Score:5, Insightful)
This is of course true, but bad practice. I disagree with the idea of baking in this sort of thing into the browser software, however whenever you stray from officially reserved values, you can land in a world of pain.
For example, you use '.dev' for your internal sites. Sure, you control DNS and you can do that. Suddenly, a workstation needs access to something google is hosting on .dev. Suddenly, you have a self-inflicted wound because you didn't stick to private use reserved values, and you don't have a clean way out of reconciling this.
Re: (Score:2)
For example, you use '.dev' for your internal sites. Sure, you control DNS and you can do that. Suddenly, a workstation needs access to something google is hosting on .dev. Suddenly, you have a self-inflicted wound because you didn't stick to private use reserved values, and you don't have a clean way out of reconciling this.
Another common use case is that you as a company might want to present a different view of a site to your employees. Or do things like ensuring that new systems that by default access pool*.ntp.org don't actually go there, but to your own NTP servers.
Re: (Score:2)
This is also true, though I'm pretty sure that none of the .dev users are in this boat.
Re: (Score:2)
Another common use case is that you as a company might want to present a different view of a site to your employees.
This is best done with authentication. Present the public view until the user has logged in as an employee. That way, even telecommuting employees will get the employee view.
Re: (Score:2)
You don't own the .dev tld!
On a private network, yes, you do. You don't own it on the Internet, but on your own network, you own every domain and TLD.
OK, that's a valid view. But then why is your DNS server resolving those via the public root?
Re: (Score:2)
Re: (Score:2)
A browser that assumes that it's on Internet when it isn't is at fault, not those who run their own network.
And don't forget Postel's law. This is not being liberal in what you accept.
Re: Fuck off with this security bullshit. (Score:2)
Re: Fuck off with this security bullshit. (Score:2)
Re: (Score:2)
It costs $15 to generate a new internal domain (source: Gandi.net), and $15 per year to keep it. Generate one in advance.
Re: (Score:3)
This is accurate, but it's also damn peculiar for google to go in and declare policy for domains independent of the HSTS headers and such. They own .dev today, tomorrow, they might not.
It's bad policy to hard bake assumptions about what company owns what domain into a browser.
But to all people making internal sites, the answers are your own domain or .test (.invalid and .example would work too).
Re: (Score:3)
FWIW, .invalid should not work, and you should not make it work. If it does, this is nonstandard behavior. See RFC 6761 section 6.4. Anything ending in .invalid should be guaranteed to result in either an API failure, or an NX response.
Re: (Score:2)
Re: (Score:3, Interesting)
Sorry but my sympathy is thin on this topic -- this is DNS 101. This isn't Google forcing you to be secure. Don't use a domain name you don't own.
I think most of us know about the IP block 10.x and 192.168.x.x --- and I know not to use somebody else's IP range (e.g. don't use 3.x.x.x) And I knew enough about DNS not to make domains up - we had the same need years ago, private domain for testing, and I was stumped until somebody showed me that .local was reserved for this purpose so we built out a QA l
Re:Fuck off with this security bullshit. (Score:5, Insightful)
This isn't Google forcing you to be secure. Don't use a domain name you don't own.
On your own private network, you do own any domain name you want.
The name resolution protocols specifically allow this, and for good reasons.
Re: (Score:2)
only if you take the extra step to also redirect any and all dns queries on your private network to your own dns server(s) (or drop them if not destined for your dns server).
what will you do if sally from accounting has put 8.8.8.8 as their first resolver?!
On a private network, you control not only the DNS results, but also routing and address space. That's what makes it a private network.
It's not uncommon to block every outgoing request that isn't proxied.
Sally's DNS requests won't work, but her web access still will, because it's the proxy server that looks up the addresses, from the DNS servers the proxy server is configured to use. So her request for http://www.sar.com/ [sar.com] may do what she thinks, but her request for http://www.gimpoutfits.biz/ [gimpoutfits.biz] may lead her
Re: (Score:2)
So, how do you configure HP switches to accept a wildcard certificate? I haven't been able to figure it out. Wireless routers - yes. HP switches no.
Re: Fuck off with this security bullshit. (Score:2)
Re: (Score:2)
Guess I'm missing something in your answer. I mean install a wildcard certificate on an HP switch so it identifies itself correctly via https when directly addressed.
"Use a proxy." explained (Score:2)
Let me state my understanding of Z__K's answer: Don't directly address the switch. Instead of directly addressing the switch, indirectly address the switch. Set up a server that addresses the switch's management interface and identifies itself correctly via https when the server is directly addressed, and address that server instead of the switch.
Re: (Score:3)
No, it's not. For one, the ludicrously short expiration times on free certs is just silly, especially for a damned INTERNAL only system. Two, the verification process doesn't actually work when the INTRERNAL ONLY server cannot be accessed externally.
Why not let the user decide? At least let the user decide that self-signed certs are OK without some crazy procedure akin to reciting the pledge of allegiance backwards while hopping on one foot, rubbing your belly and patting your head at the same time.
I'm not
Re: (Score:2)
LetsEncrypt doesn't need to access your internal server - you can use the DNS version instead..
Re: (Score:2)
Not every DNS zone is publicly accessible. Some test servers don't even have DNS names.
Re: Fuck off with this security bullshit. (Score:2)
Re: (Score:2)
I agree with you that the specific issue of HSTS .dev is a non-issue for internal servers not in .dev.
But the larger issue of unavailability of browser-recognized certificates for internal TLS servers is an issue for internal servers not in .dev. I don't see most home users as willing to spend $15 per year on registering a domain in a public zone just to be able to use HTTPS over the LAN. Using cleartext HTTP becomes less of an option over time as more HTTP elements and JavaScript APIs become unavailable ou
Re: (Score:2)
That's just another variation on exposing an internal only test environment to the outside. That is, a REDUCTION in security. More flaming hoops for the wonder dog to jump through.
Re: (Score:2)
You're just being difficult now.
You just need to have a box sitting somewhere doing the DNS request and getting the test cert for ya and copy it into test periodically. We use a docker container and a NFS mount to accomplish this in my environment but theres plenty of ways to make it happen..
Re: (Score:2)
No, the browser is just being difficult now. I have a perfectly good setup that works as long as I avoid updating the browser. There's a reason none of the tools in my toolbox are Playskool brand.
Re: Fuck off with this security bullshit. (Score:2)
Re: (Score:2)
You did make sure to run that comment by legal, HR, and the political officer first right? You wouldn't want to violate PC standards, would you?
Re: (Score:3)
Re: Fuck off with this security bullshit. (Score:2)
Re: (Score:2)
Yes, as long as the server is exposed to the outside world with an actual registered domain. The topic of this thread is internal only servers that are firewalled at least or possibly air-gapped.
Re: Fuck off with this security bullshit. (Score:2)
Re: (Score:2)
There are any number of private .dev based environment's that predate ICAN'T opening up .dev. There is a case to be made for an internal air-gapped server having the exact same domain name as the public production server but not being accessible to the public. I've also seen enterprises that do the same thing for production servers where the internal enterprise.com includes staff only material as well as the public pages.
It's like I named all of the rooms in my house after real addreses and I'm complaining
Re: (Score:2)
Re: (Score:2)
They might, but if they bothered to click advanced options, "I understand the risks", and then "accept certificate", they have nobody but themselves to blame. They could at least give me a checkbox in about:config to enable that. As I said, there's a reason the tools in my toolbox aren't Playskool brand.
Re: (Score:2)
Yeah, that is a work around. As you say it's obnoxious and shouldn't be necessary. For all of that, pinning is still not a thing even though that would make public SSL easier, cheaper, and more secure all at the same time.
Re: (Score:2)
If you understood networks a little better, you'd understand that everything has a local name, and most VPNs have a non-internet-routable TLD. That is normal, expected, and predates the public internet.
It isn't "false" in any way as long as it is known to your DNS server, or otherwise provisioned for routing.
You might even find that machines not connected to a network often have a network address of localhost.localdomain.
Re:Fuck off with this security bullshit. (Score:5, Informative)
And CERT has warned against using your own internal made-up top level domains...
https://isc.sans.edu/forums/di... [sans.edu] ...which is why there's an RFC listing reserved top level domains you can safely use:
https://tools.ietf.org/html/rf... [ietf.org]
Re: Fuck off with this security bullshit. (Score:4, Insightful)
Re: (Score:2)
My company uses an HTTPS proxy and only pushes their public key to the OS certificate store. So anything that doesn't use the certificates trusted by the OS fails.
Luckily IE and Chrome are sane like that.
What's also lucky is I'm not too retarded to figure out I can export that certificate and load it in to any application that refuses to use the OS certs.
Re: (Score:2)
We have a product that embeds MapQuest. But MapQuest doesn't allow HTTPS so when the customer connects to our product using HTTPS the stupid fucking browser goes fucking nuts.
So like he said, you're part of the problem.
Simple solution (Score:3, Informative)
Don't use spyware posing as a web browser.
More make-work, less productivity (Score:2)
Re: (Score:2)
bullshit and the fragility of having certificates up to date
If it actually is bullshit and fragility then you're doing it wrong. Especially considering this is your controlled machines on an internal network you're doing it VERY WRONG.
Re: (Score:2)
Wondering Why Your Internal .dev Web App Has Stopp (Score:4, Informative)
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:Wondering Why Your Internal .dev Web App Has St (Score:5, Insightful)
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...
While there are times where I would tend to agree this is not one of them. Responsibility is bidirectional.
Opening the TLD floodgates was a predictable, preventable disaster done entirely for selfish reasons at the expense of the network and all its users.
Allowing TLDs like ".dev" to be handed out in the first place was much worse. They knew or should have known how this was being widely used at the time and what the global implications would be yet like TLD floodgates $$$ wins the day.
Then Google was like...hey we own this TLD and we own a web browser so we'll just leverage our verticals to enforce arbitrary rules over what we own anyway that suits our specific needs.
This is a shining example of what happens when $$$ is allowed to trump reason and why allowing monopolies to get too powerful and start exerting ownership over more and more of the stack is a bad idea. They can and will do whatever they want simply because they can. They can't help themselves nor can they even understand that their needs and goals are not representative of the rest of the world.
Today it is HSTS tomorrow it is waking up to find browsers doing UDP with user land congestion algorithms configured to be twice as aggressive as TCP...oh wait.. that already happened...
Re: (Score:3)
Re: (Score:3)
This is a shining example of why, if we disagree, we should participate in the RFC process rather than go off on our own. And if we don't get our wishes in the RFC process, we shouldn't stage a rebellion.
I've participated in IETF lists and made it to a few meetings when in country. ICANN is not the IETF. ICANN is driven by money not consensus. A rebellion is exactly what I advocate and very much hope to see happen.
Either "throw the bums out" or raise pain felt by entry of new TLDs by having more operators not blindly delegating everything to root servers.
We need a functioning network.
Which is why it is not ok for bags of slime to intentionally break shit in order to enrich themselves.
Four TLDs are reserved for this. .test, .example, .invalid, and .localhost. If .dev should have been a reserved TLD, there were 15 years to get it added from the time RFC2606 was published until .dev became a TLD.
Half the RFCs worth implementing don't even work i
Not an issue (Score:2)
Whats the alternative? (Score:2)
Okay... I understand using
Is using .test a drop in replacement? Basically I'd like something that can't accidentally leak requests on the Internet. And I *DO NOT* want to use HTTPS/certs internally for development because it's a pain in situations where I'd currently resort to Wireshark to
Re: (Score:3)
Re:Whats the alternative? (Score:5, Insightful)
.test is a better replacement, strictly speaking, since IETF has reserved that TLV (as well .example and .invalid).
Of course, it's pretty damn weird for a browser to hard bake assumption about TLD ownership and policy.
Re: (Score:2)
Google own Chrome .dev
Google own
How is it weird they apply the same policy to both?
Re: (Score:2)
Because their ownership of '.dev' can be transient. Hypothetically it could be transferred to someone else, or even taken away from Google.
The point is we have a DNS infrastructure explicitly designed to designate *current* ownership without forever commiting the current owner to be the future owner.
Re: (Score:2)
At which point we would expect them to update Chrome accordingly.
Re: (Score:2)
Hypothetically they could remove .dev from the HSTS preload list.
The same could be said for any domain in the list
https://cs.chromium.org/chromi... [chromium.org]
What if the ownership of one of the 40,000 entries in that list changes?
Re: (Score:2)
Wireshark is fine with TLS if you give it the private key.
What's not fine is how a browser handles a webapp with mixed HTTP and HTTPS requests.
If you're going to deploy it with HTTPS, you should build and test with it too.
Wondering why? (Score:2)
Because you're doing it wrong. .dev is a gTLD, it's idiotic to use it for an internal service.
Use a domain you own.
code wranglers (Score:2)
OK, I'll bite. What in the name of Gordon H. Bennett is a sodding code wrangler?
Re: Did the cool-aid taste good? (Score:3, Interesting)
Re: (Score:3)
I think there's another reason at play here. Google are enforcing strict HTTPS on all their domains. This means browsers should always be using HTTPS to access any site under a google owned tld, including .dev.
Chrome, by enforcing this at the code level, is enabling another level of security for customers; preventing third party operators trying to downgrade or degrade what should always be a secure connection.
The only people being burned are those folk who used a valid domain name for their internal dev en
Re: Did the cool-aid taste good? (Score:3)
Re: (Score:3)
Says the AC who has no credibility to trade on.
Re: Did the cool-aid taste good? (Score:4, Informative)
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: (Score:2)
I am not rightly able to apprehend what kind of confusion of ideas could provoke such a statement.
HTTP is plain-text, and easy to read in-flight. There are fewer browser restrictions around cross-domain access to HTTP. Tracking HTTP is easy.
HTTPS is encrypted, and has a lot of browser restrictions to prevent cross-domain access. It's harder to make embedded IFrame tracking bugs work with HTTPS.
Re: (Score:2)
It's harder to make embedded IFrame tracking bugs work with HTTPS.
Sorry, that is not really plausible.
What has HTTP/HTTPS to do with HTML?
Re: (Score:2)
What has HTTP/HTTPS to do with HTML?
"HT"?
Re: (Score:2)
You can request the content of an IFrame or send an action out of an IFrame to its parent in JavaScript. This allows you to do cross-site request forgery or to inject additional script into a site into which a user has logged. The browser disallows some of these things if the domains don't match; it disallows more of these things if one or both ends are loaded via HTTPS.
Re: (Score:2)
I am not rightly able to apprehend what kind of confusion of ideas could provoke such a statement.
HTTP is plain-text, and easy to read in-flight. There are fewer browser restrictions around cross-domain access to HTTP. Tracking HTTP is easy.
HTTPS is encrypted, and has a lot of browser restrictions to prevent cross-domain access. It's harder to make embedded IFrame tracking bugs work with HTTPS.
There are arguments on both sides. Encryption like most technology is a double edged sword with upsides and downsides.
One of those downsides WRT tracking specifically is ability to exploit properties of layers below HTTP. Session resumption in TLS uses session identifiers sent in the clear allowing third parties to correlate separate requests by user/browser before HTTP is even in the picture and isolate traffic between multiple users sharing the same system/network address.
Given most sites are public the
Re: Did the cool-aid taste good? (Score:2)
Re: (Score:2)
I really never thought I'd never see the day when Slashdot would deteriorate so far that your posts on this subject wouldn't be nodded down to oblivion immediately. Do you even really believe the bullshit you are spewing in this thread or are you trolling?
Given that (a) I actually said why, and all that you do is spewing "You're wrong na-na-na-na bullshit" with no explanation whatsoever, and (b) far more people have marked you as a foe on Slashdot than me, I think this speaks for itself.
Most people here are able to judge posts based on what information or interesting points the posts provide, and not just who shouts the loudest.
Re: Did the cool-aid taste good? (Score:2)
Re: (Score:2)
Don't forget all the commercial tools that allow enterprises to snoop on traffic using TLS, e.g., WebSense
Re: (Score:2)
Re: (Score:2)
If you can hide something from the client in HTTPS, you can also hide it in HTTP.
The problem isn't someone hiding something from the client - it's the ability (or lack thereof) to hide things from the server.
HTTPS largely ensures a 1:1 session with a known identifier.
HTTP can be served from cache, or modified on the fly to hide information from the server.
These days, the server is your enemy - they're the ones collecting, aggregating and selling information on you. Google's (and the TLAs) goal is to make this information gathering more comprehensive and trustworthy. That's why they wa
Re: (Score:2)
I'm not entirely sure what "hiding who accesses the endpoint from the endpoint itself." means, but please explain how HTTPS doesn't do that.
(Spoiler: you're full of yourself)
Re: (Score:2)
I'm not entirely sure what "hiding who accesses the endpoint from the endpoint itself." means, but please explain how HTTPS doesn't do that.
HTTPS doesn't hide anything from the endpoint. That should be obvious?
However, it does largely defeat the multipathing, proxy caching and rewriting possible with HTTP, all of which helps hide who accesses an endpoint, as well as automatically adding an immutable identifier; the session key.
When I access http://www.fbi.gov/ [fbi.gov] and the proxy I use serve it from cache, the site won't even know that I accessed it. And when I ask for http://ww.cia.gov/page1 [cia.gov] and http://www.cia.gov/page2 [cia.gov] and the request comes from
Re: (Score:2)
Yeah, I gotta say, I support Network Neutrality not Network Doitmyway.
Not everything benefits from HTTPS, some things benefit from caching and broadcast distribution!
Re: Did the cool-aid taste good? (Score:2)
Re: (Score:2)
The #1 reason to use HTTPS everywhere is that it adds a lot of noise, which is non-trivial in relation to thwarting a potential eavesdropper.
The problem is that these days, the eavesdropper sits on the server, and HTTPS does nothing to prevent that. It only provides the eavesdropper on the server with unique session information so they can log who accessed content.
It also largely[*] defeats proxy caching so they can easier enforce that it is accessed individually by each user -- all in order to better monitor users.
That is a much bigger problem than eavesdropping. You can (to some degree) choose your ISP, or use VPNs, but you cannot excise gr
Re: Did the cool-aid taste good? (Score:2)
Re: (Score:2)
Truth is most compromises start as a phishing email. Will HTTPS stop the email? No. Will HTTPS stop a network email scanner from detecting malicious links in the email? Yes. Will HTTPS stop a malware scanner from analyzing a mali
Re: Did the cool-aid taste good? (Score:2)
Re: (Score:2)
Web proxies that MITM TLS connections are way worse than proxies that outright refuse to do HTTPS.
(That said, this is about mail.)
Re: (Score:2)
First, a network email scanner would be on the mail server itself, looking out for suspicious links. The suspicious link scanner can easily visit websites to make sure they're safe for the reader, especially if it's a site that's not previously indexed by Google.
If you use a corporate computer (especially one for a large company), there'
Re: (Score:2)
Certain proxy servers can be configured to intercept HTTPS traffic, and emulate a legitimate security certificate. This allows corporations to MITM their own employees and spy on their own HTTPS connections.
Blah, there's nothing being "emulated" (and nothing legitimate about it). It's just another predeployed trusted CA cert on the employee's computer, if the employee cares to check, they can easily tell they're being MITM'd
Re: (Score:2)
Will HTTPS stop the email? No. Will HTTPS stop a network email scanner from detecting malicious links in the email? Yes. Will HTTPS stop a malware scanner from analyzing a malicious payload in the email? Yes.
Uh, none of that will or will not stop any email because emails are transmitted via SMTP or SMTPS, geez. Your uid is low enough that you ought to know this.
Now, are you arguing for using SMTP instead of SMTPS? Yeah didn't think so.
Re: (Score:2)
I'm in a corporate environment right now.
All HTTPS traffic is inspected. All downloads get virus scanned.
All HTTPS traffic is decrypted by the proxy, scanned and re-encrypted with a certificate signed by the companies CA.
It's a non-issue for a corporate environment. Since you've got control of all the machines on the network, it's not hard to have them all trust your own CA.
The only time it's a pain in the ass is when you try to access an HTTPS site with an invalid certificate. The proxy refuses to allow it
Re: Did the cool-aid taste good? (Score:2)
Re: Did the cool-aid taste good? (Score:2)
Re: (Score:3)
They aren't being evil
They manage the .dev gTLD and one of the rules for using a .dev domain is HSTS
Re: (Score:3)
They shouldn't have been given any authority to manage .dev, period. .dev has been used for years for local like .local*/.test et al. Since I don't use crappy Chrome I don't have an issue, besides anyone dumb enough to trust public DNS servers before their own deserves this nice FU from them. I'm sorry if I seem a bit jaded but this is another example of why this 800lb gorilla needs to be broken up.
Oh yeah, before I forget.
Fuck Google, fuck *their* rules, period.
Re: (Score:2)
Perhaps someone should have thought to put it in RFC2606, like they did with .test, .example, .invalid and .localhost
Re: Just buy local... (Score:2)