Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Chrome Google

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.

Wondering Why Your Internal .dev Web App Has Stopped Working?

Comments Filter:
  • by Anonymous Coward on Thursday November 30, 2017 @12:33PM (#55651363)

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

    • by steveb3210 ( 962811 ) on Thursday November 30, 2017 @12:43PM (#55651445)

      You don't own the .dev tld!

      • by arth1 ( 260657 ) on Thursday November 30, 2017 @01:14PM (#55651713) Homepage Journal

        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.

        • by Junta ( 36770 ) on Thursday November 30, 2017 @01:32PM (#55651857)

          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.

          • by arth1 ( 260657 )

            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.

            • by Junta ( 36770 )

              This is also true, though I'm pretty sure that none of the .dev users are in this boat.

            • by tepples ( 727027 )

              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.

        • 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?

        • Sure, but the standards say you don.t, and the browsers abide by the standards. IF you violate the standards, standard compliant browsers are no longer guaranteed to function properly on your network, and it's your responsibility to keep things working, not theirs.
          • by arth1 ( 260657 )

            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.

      • by Junta ( 36770 )

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

        • by skids ( 119237 )

          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.

    • I keep all my internal dev servers on https, as our developers have tended to hard-code HTTP and then complain about cross-domain forwarding restrictions when I redirect to HTTPS in the production server.
    • Re: (Score:3, Interesting)

      by ripvlan ( 2609033 )

      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

      • by arth1 ( 260657 ) on Thursday November 30, 2017 @01:18PM (#55651739) Homepage Journal

        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.

  • Simple solution (Score:3, Informative)

    by smooth wombat ( 796938 ) on Thursday November 30, 2017 @12:38PM (#55651397) Journal

    Don't use spyware posing as a web browser.

  • If I want to set up a development system on an air-gapped network, I don't really want to deal with the bullshit and the fragility of having certificates up to date. Especially if set air-gapped network is used for controlling machinery or other specialized equipment. Repeat after me: the computer shall do what it's told by its owner, not what some desk jockey in California thinks it should do.
    • 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.

      • That's my point. Doing it wrong is fast and easy. Doing it right is more time-consuming. And that extra work ought not be required when it isn't necessary. But I repeat myself.
  • by oobayly ( 1056050 ) on Thursday November 30, 2017 @12:47PM (#55651497)

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

    • by WaffleMonster ( 969671 ) on Thursday November 30, 2017 @01:32PM (#55651855)

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

      • 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. We need a functioning network. 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.
        • 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

  • As a web developer, this really isn't an issue, always use HTTPS even internally. The only way you'd really be locked out is if you didn't follow smart practices.
  • So if I understand this correctly, I can't use .dev internally even if my local DNS resolves a domain because Chrome will want a cert?

    Okay... I understand using .dev maybe wasn't the best idea. So what's the alternative?
    • .test
    • use my own domain

    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

    • by Kenja ( 541830 )
      The alternative is Firefox. Seems Google doesn't want us using their browser anymore, and who am I to argue with them.
    • by Junta ( 36770 ) on Thursday November 30, 2017 @01:28PM (#55651827)

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

      • Google own Chrome
        Google own .dev

        How is it weird they apply the same policy to both?

        • by Junta ( 36770 )

          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.

          • Because their ownership of '.dev' can be transient. Hypothetically it could be transferred to someone else, or even taken away from Google.

            At which point we would expect them to update Chrome accordingly.

          • 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?

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

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

  • OK, I'll bite. What in the name of Gordon H. Bennett is a sodding code wrangler?

If God had not given us sticky tape, it would have been necessary to invent it.

Working...