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

FuckinA yes, yes, I do!

[Anonymous Coward]

So I will just become a republican so I can fuck anyone anytime!

Not really, no

[Anonymous Coward]

It's old news, it's been planned for some time. What I was wondering is that way back when Google first snatched the .dev TLD our developers started using another unregistered TLD and ran the risk of screwing up again. Can anyone explain that?

Did the cool-aid taste good?

[arth1]

This is part of Google's larger and welcome push for HTTPS to be used everywhere for greater security.

I think you mean "unwelcome" and "for greater tracking accuracy".

There is little reason for HTTPS to be used for much if not most of the content on the internet. There are reasons to use caching and defeat endpoint trackers, though.

Re: Did the cool-aid taste good?

[Zero__Kelvin]

Bullshit. There is plenty of reason to use HTTPS and eschew HTTP. For one thing it eliminates the need to explain to laypersons, which is most people, how to tell the difference. This reason alone justified it. Worries about snooping and government spying are just icing on the cake.

Re:Did the cool-aid taste good?

[Anonymous Coward]

ISP's are about to get the right to manipulated data on the fly. Remember 3rd party banner ads injected into the Apple store? Those are coming back next year. HTTPS ensures that ISPs will only have the right to throttle connections based on IP pairings, not based on content directly, and that they will be unable to manipulate data on the wire. No more injected ads, no more verizion super cookie, etc. Google is in the right here, though perhaps not with local development environments.

Re: Did the cool-aid taste good?

[Anonymous Coward]

Wrong, its much more insidious. All websites must register and pay a Google approved registrar to be on the internet. Of course, they must also be apple and Microsoft approved. We couldn't have you going to unapproved websites.

Re:Did the cool-aid taste good?

[bluefoxlucid]

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:Did the cool-aid taste good?

[NicknameUnavailable]

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. If you know anything encrypted is worth snooping on (as it was years ago and still is to some degree) then you know where to focus your efforts. On the other hand, if EVERYTHING is encrypted at all times then you have to have some foreknowledge of what you are looking for in order to start looking. A fully encrypted web is inherently a much more secure web, if nothing else it means the NSA has to save every single packet going over the wire until someone cracks the algorithms encrypting it, which itself is probably at least a few decades away.

Re: Did the cool-aid taste good?

[Anonymous Coward]

Down boy... and you're wrong. Fuck off.

Re:Did the cool-aid taste good?

[arth1]

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 hides what is sent from middle men.
HTTP allows hiding who accesses the endpoint from the endpoint itself.

These days, the endpoints being monitored and users tracked, quite often by Google (and thus by extension TLAs with access to Google), is a hell of a lot bigger problem than man-in-the-middle.

Re: Did the cool-aid taste good?

[Anonymous Coward]

For one thing it eliminates the need to explain to laypersons, which is most people, how to tell the difference

That's one of the stupidest things ever. The point is that HTTPS is to make tracking easier and more convenient. Your "cert" is a cookie. It identifies you and your machine and location. Whatever added "security" there might be, it's not there for the user.

And there is also a lot of connection problems due to botched certificates. Even happens here when somebody's server clock isn't set right.

HTTPS is bullshit snake oil, just like DRM, and frankly is just as undesirable. The GP should not have been modded down for speaking the truth.

Re:Did the cool-aid taste good?

[arth1]

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 greedy marketers who treat you as a product and overreaching three letter agencies who treat you as a criminal from the servers you talk to.

[*]: Average Joe won't be able to set up a proxy server with a local CA and import its CA cert into all clients. And Power Joe won't do it because it hides the endpoint certificate from his view.

Re: Did the cool-aid taste good?

[Anonymous Coward]

Wut. I mean... wut?! "My cert is a cookie"?! Care to explain how that works?

Re:Did the cool-aid taste good?

[xanthos]

In the larger scheme, this HTTPS everywhere BS is an anti-Security measure. In a corporate environment it totally nullifies the ability of many anti-malware tools to analyze packet contents for malicious code and behavior in an attempt to stop the exceedingly rare MITM attack.

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 malicious payload in the email? Yes.

As others have commented, this has more to do with Google protecting its revenue stream than protecting the end user.

Re:Did the cool-aid taste good?

[angel'o'sphere]

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:Did the cool-aid taste good?

[Anonymous Coward]

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.

That is THE key point that so many people are missing now.

HTTPS allows for more accurate tracking and privacy destruction. The problem is not in the transport, the problem is embedded deeply into the endpoints.

Re:Did the cool-aid taste good?

[Aighearach]

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?

[Zero__Kelvin]

The sad thing is that these days on Slashdot there are many people with such little understanding of technology that they will actually think what you say makes sense.

Re: Did the cool-aid taste good?

[Zero__Kelvin]

Someone should invent proxies.

Re: Did the cool-aid taste good?

[Aighearach]

For one thing it eliminates the need to explain to laypersons, which is most people, how to tell the difference. This reason alone justified it.

Wait, you're saying that because you believe there to be a bunch of ignorant people in the world, that means you should tell me what network technologies to use? Fuck that!

Re: Did the cool-aid taste good?

[Anonymous Coward]

The sad thing is that Google shill accounts like yours have any credibility in the /. community.

Re:Did the cool-aid taste good?

[Anonymous Coward]

I've always done my development on domains named development.mydomain.tld... seems to work okay. Where I have more than one project it is: dev-project1.mydomain.tld.

An added advantage is that as the project matures, DNS and forwards can be added to allow for real-world testing (read as over the Internet) can take place.

Re:Did the cool-aid taste good?

[Anonymous Coward]

head meet sand. the feds can already look at https. why the fuck do you think they haven't thrown a tantrum over the https movement?

Re:Did the cool-aid taste good?

[the_other_chewey]

What has HTTP/HTTPS to do with HTML?

"HT"?

Re: Did the cool-aid taste good?

[geekprime]

Says the AC who has no credibility to trade on.

Re:Did the cool-aid taste good?

[Sigma 7]

Will HTTPS stop a network email scanner from detecting malicious links in the email?

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.

Will HTTPS stop a malware scanner from analyzing a malicious payload in the email? Yes.

If you use a corporate computer (especially one for a large company), there's likely to be an internal security certificate deployed on those machines. They're also likely to have browsers configured to use a proxy server, to reduce the load of commonly accessed websites.

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. Thus an enterprise-grade network/malware scanner can break through these limitations.

As others have commented, this has more to do with Google protecting its revenue stream than protecting the end user.

Or it could be paranoia. Instead of making browsers secure by design, they instead chase after security theaters that sufficiently skilled hackers know how to bypass.

Re: Did the cool-aid taste good?

[Zero__Kelvin]

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?

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: Did the cool-aid taste good?

[Anonymous Coward]

No, sites are not issuing you a unique cert, those things cost money.

What does happen is that HTTPS clearly identifies the sites you are visiting with a cert rather than making a tracker guess, but once they have the info, they can't delve much deeper as they can with HTTP.

HTTPS is fine, the cert system could use an overhaul, however.

Re: Did the cool-aid taste good?

[Anonymous Coward]

You can use whatever network technology you want, just not on Chrome...

So go find another platform and gtfo

Re: Did the cool-aid taste good?

[Zero__Kelvin]

Right, but minor correction. The dev TLD is an ICANN issued TLD, so this has nothing to do with local / intranet traffic. Just as you should not use .com for internal machines you should not use .dev or you are violating standards.

Re:Did the cool-aid taste good?

[Virtucon]

Don't forget all the commercial tools that allow enterprises to snoop on traffic using TLS, e.g., WebSense

Re: Did the cool-aid taste good?

[Zero__Kelvin]

That is the weakest troll I have seen in a long time, unless you believe that, in which case you are an idiot.

Re:Did the cool-aid taste good?

[fisted]

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: Did the cool-aid taste good?

[fisted]

Web proxies that MITM TLS connections are way worse than proxies that outright refuse to do HTTPS.

(That said, this is about mail.)

Re: Did the cool-aid taste good?

[Zero__Kelvin]

HTTPS adds nothing to the ability of endpoints to identify you. They can already do that just fine, and the client negotiates a unique key per transaction, so your apparent belief that there is some master key that acts as a global identifying fingerprint stems from complete ignorance of how TLS works.

Re:Did the cool-aid taste good?

[fisted]

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:Did the cool-aid taste good?

[bluefoxlucid]

The middle-men must have the appropriate secret key known to the endpoint. Both endpoints can see what is written in an encrypted stream. If you can hide something from the client in HTTPS, you can also hide it in HTTP.

Re:Did the cool-aid taste good?

[bluefoxlucid]

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:Did the cool-aid taste good?

[fisted]

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:Did the cool-aid taste good?

[WaffleMonster]

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 fact they are encrypted does very little to mask activities of users. With an analysis of payload size and timing it has been shown unencrypted URLs can be recovered with high accuracy.

In my view the two biggest issues with HTTPS is lack of transparency and visibility by people that may value these things above message integrity and privacy. With everything encrypted E2E it is more difficult to reason and make value judgments about data even by people who happen to be sitting at one or both ends.

The other issue is having to seek permission/approval by more entities with those with power over you. With http I all I need is an IP address or at least a TCP port on a shared address. With HTTPs I need a DNS name and a certificate. I now have to establish relationships and get permission from two more entities to participate in the network. More entities with the power to shut me up or worse divert my traffic without my users being any wiser if they don't like what I have to say (Thanks to Google's unilateral decision to get rid of PKP)

There are others currently that hopefully will be widely resolved in the future such as burning a round trip on resumption and worries of increased attack surface due to implementation bugs in todays non-trivial TLS stacks.

I personally prefer HTTPS and think on balance it's better than nothing. Yet there are others with different needs and different value judgments for which HTTPS may well be deemed unnecessary or even harmful.

Re: Did the cool-aid taste good?

[arth1]

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?

[arth1]

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 want HTTPS/SPDY/HSTS - don't for a second think that they have your best interest at heart. That's only how they sell it to the unwashed masses.

Re: Did the cool-aid taste good?

[Zero__Kelvin]

At least I finally figured out *WHY* you have been saying all these ridiculous things. Newsflash, there is no *client* certificate in an HTTPS transaction. All these conspiracy theories you have concocted are based on a fundamental ignorance of HTTPS and how it works.

Re:Did the cool-aid taste good?

[viperidaenz]

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?

[Zero__Kelvin]

This has literally nothing to do with Network Neutrality, *except* that HTTPS makes violating it more difficult.

Re:Did the cool-aid taste good?

[arth1]

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/ 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 and http://www.cia.gov/page2 and the request comes from two different IPs, the site doesn't know that it's the same client accessing both pages. And when I access http://www.inflatableunicorns.... and my proxy deletes tracking information from the header (including IP address and browser fingerprints), they don't know that I'm the same person who visited last week. And they won't know that I looked at adcampaign.jpg either, because it can be served from a cache.

Now enter HTTPS, and how it changes this by trying to ensure a 1:1 connection.

Then consider what Google's business is, and whether it's in their interest to obtain as much accurate information as possible about who visits and who sees which ads, and how to aggregate and sell that data. That they push hard for the technology that helps their business model should not come as a surprise, nor should it be taken as them having your best interest in mind.

And consider the interest of the three letter agencies who sit at the endpoints and sees all the HTTPS data and metadata after it has been decrypted by the server. Do you think they want more accurate tracking capabilities or not?

Re: Did the cool-aid taste good?

[Albanach]

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 environments, and have continued to do so for 2 1/2 years after Google took ownership of the TLD. I imagine it's those very developers, slow to respond to change, that Google wants to nudge more strongly towards site-wide encryption.

Re: Did the cool-aid taste good?

[F.Ultra]

Well the subject was corporate network so a MITM proxy is usually the norm anyway.

Re:Did the cool-aid taste good?

[bluefoxlucid]

Caches don't cache elements which may change frequently. Also, the server frequently modifies elements when they're updated or altered, which breaks caching. Caches mostly work on static elements such as scripts or images and, for example, the client will receive JavaScript constructed such that blocking the script dumps a comment--an image--into the page. That image will be something like a.jpg?1948475898775, looking unique or tied to your session, thus the cache won't have that exact match and will fetch the URI (and get thousands of copies of the zero-pixel image in its cache).

HTTPS can serve from browser cache, and I even used Squid for a while as an HTTPS cache. It can't serve as public cache, however.

All of this is also irrelevant when you log into a Web site (a big part of "cannot be cached" as well).

Re: Did the cool-aid taste good?

[F.Ultra]

And exactly what is this client identifier that you are talking about? You do realise that there is no client cert ala ssh and that the client generates a new random key for every connection right, right?

Re:Did the cool-aid taste good?

[skids]

So tweak your browser to use a fresh SSL session with a new key for every request. It'll break a few sites, but you are free to do so, as long as you use an open source browser or one that uses open source system libraries.

Also, if you think MITM is a small problem, you haven't been paying attention to just how bad home wifi/router security is these days. Anyone who isn't putting the time into keeping an OpenWRT system freshly updated, which is pretty much everyone, is liable to having an embedded agent running on their router, and if their browser chews on any script sent by HTTP, they are liable to run whatever that embedded agent decided to insert into that script.

Re: Did the cool-aid taste good?

[F.Ultra]

The SSL Session ID is deleted once you close the browser. And I'm quite sure that you can disable it altogether (atleast in Firefox).

Re: Did the cool-aid taste good?

[arth1]

Newsflash, there is no *client* certificate in an HTTPS transaction

I never said that there is, so you're attempting to whack a strawman again here.

But you're also wrong - there is a session key[*] pair, which is established at connection time. Look up "Diffie-Hellman" and "forward secrecy". Without that, but just server keys, anyone could just replay any traffic and be able to decrypt anything the server sends with the server's public key. The session keys not only prevent replay eavesdropping, but uniquely identifies the client for as long as the session lasts. If a client sends a request for resourceA from one IP and for resourceB from another IP, the server knows it's the same client. If a client strips all cookies or other identifiable headers, it still knows it's the same client.

[*]: A certificate is just a key with a signature.

Re:Did the cool-aid taste good?

[NicknameUnavailable]

There is a massive eavesdropping system at the ISP level. Endpoints are an issue, but that is not where the bulk of data is collected by any stretch of the imagination.

Re:Did the cool-aid taste good?

[arth1]

Caches don't cache elements which may change frequently.

They cache whatever you set them to cache.
I know, strange concept, that the server isn't in control. That's what I like about http.

Re:Did the cool-aid taste good?

[tepples]

Average Joe won't be able to set up a proxy server with a local CA and import its CA cert into all clients. And Power Joe won't do it because it hides the endpoint certificate from his view.

Can't the server certificate generated and presented by the proxy include the origin server's certificate as a "comment" of some sort?

Re:Did the cool-aid taste good?

[Anonymous Coward]

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

If you are using a company-owned computer using the company's Internet connection, then the company has every right to MITM your traffic with the intent of protecting their network and computers from malware attacks. You may have even agreed to let this happen if you did not read your employment contract carefully.

Re: Did the cool-aid taste good?

[BronsCon]

There's nothing wrong with using .com for internal machines, provided your internal hostnames don't overlap with your public hostnames. It's actually a common (I'd say standard) practice and would be fine with .dev as well if Google wasn't doing this (or if you don't use Chrome).

Re:Did the cool-aid taste good?

[bluefoxlucid]

If you control the cache, you can use it to cache https.

Re: Did the cool-aid taste good?

[BronsCon]

Established at connection time = different for each connection = not persistent = not a viable method of tracking. Follow?

Re: Did the cool-aid taste good?

[arth1]

Established at connection time = different for each connection = not persistent = not a viable method of tracking. Follow?

HSTS (and SPDY and HTTP/2.0) add persistency and allow for supercookies as a viable method of tracking, but only when using HTTPS. Follow?

Re: Did the cool-aid taste good?

[BronsCon]

There's nothing stopping your browser from establishing a new connection/session for each request. Follow?

Re:Did the cool-aid taste good?

[arth1]

If you control the cache, you can use it to cache https.

Not with HSTS (see TFA). Well, you can cache it, but it won't be valid for the client. That makes Google happy.

Re: Did the cool-aid taste good?

[arth1]

Supercookies survive new requests. You have to not just establish a new connection, but disable/clear/enable HSTS for the site between each request. Which browser lets you do that?

No, thanks, I prefer HTTP for all traffic where I don't log in or access or submit something that isn't public knowledge. For most of what I access, I don't mind if others get the data; I only mind whether the can tie the connections to me and aggregate and/or sell data.

Re: Did the cool-aid taste good?

[BronsCon]

I only mind whether the can tie the connections to me and aggregate and/or sell data.

Why do you care? And what makes you think your proxy provider isn't doing just that?

Re:Did the cool-aid taste good?

[unrtst]

WTF are you talking about? In a corporate environment, they're already setup to push private certs to all their clients, and can easily MITM SSL via a proxy. The corporate environment is the one place where this stuff is easy to enforce.

Will HTTPS stop a network email scanner from detecting malicious links in the email? Yes.

How's that? We're talking about a corporate environment, so their email is on a corporate server (or some cloud provider), right? And those links are still just links, and they can scan away.

Will HTTPS stop a malware scanner from analyzing a malicious payload in the email? Yes.

How? Email has almost nothing to do with HTTPS in this regard, unless you're talking about webmail. Normal corporate email clients will connect to exchange or an IMAPS server, and the client can do all the scanning it like with the content client side, and the server can do it server side. If you're talking about webmail, server based and/or browser based malware scan, or an appropriate SSL proxy will all work.

The only legit think that I can think of that it does break is cloud based anonymous proxies. Those only break if you don't trust them to decrypt all your traffic and re-encrypt it back out. If you're fine with HTTP though, then this shouldn't be an issue for you, and you can exclude your bank/etc if you want to keep it private.

Re: Did the cool-aid taste good?

[Anonymous Coward]

FFS, just google it or click this link: https://en.wikipedia.org/wiki/...

Re: Did the cool-aid taste good?

[Anonymous Coward]

On a private network this point is moot. The same is to be said about any network that is configured to use a DNS root that's not maintained by IANA.

The real answer here was simple: "Don't bake a HSTS header for any domain into an application if you want it to work properly." Google could have just as easily put the header on the server like they were supposed to, and not had this issue. Nor would any private domains using the dev TLD been affected. (Assuming they didn't blanket the entire TLD and that the browser in question would rightfully reject such a request.)

Google decided their "security" (read: preference) trumped the preferences of their users. Hence the problem. Google can just as easily fix this issue as well. Or are we just going to start mandating that everyone must implement whatever security standards app-developer-of-the-day demands, Damn anyone who says (or needs) different?

Re: Did the cool-aid taste good?

[Anonymous Coward]

You know what's cool, it's that snake oil salesmen get you to do all the advertising and propaganda for them!

HTTPS has been hacked. Only some of the hacks are publicly known. So now, its only purpose is to track you and hide malware servers with a "valid" certificate. It is a useless waste of computing resources and electricity.

Re:Did the cool-aid taste good?

[Frobnicator]

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

It is fully legitimate: The computers belong to the company, the network access is the company's, the employee's work belongs to the company, the time is being paid for by the company. What may have been implied in old employment agreements about employers providing tools is now often explicitly stated, that workers have no right to privacy on their network communications.

Organizational MitM has been part of the protocol since the very beginning. It was there in the first implementation in Netscape, and was almost immediately implemented in organizational proxy tools. When discussions were made to eliminate it just a few months later, there were many businesses, schools, and government agencies who saw the security implications for virus scanners and the very high cost of losing their proxy functionality, and they told the implementers they needed the MitM feature in place if they didn't want the newly-blossoming products blocked banned. Organizational MitM has been an intentional feature in SSL, and TLS ever since.

These proxy tools do "emulate" as described. They create a new certificate signed by the organization, but showing the "issued to" and other fields matching the original. Hence they emulate the original certificate, even though the fingerprints and keys are different.

Re: Did the cool-aid taste good?

[arth1]

Why do you care? And what makes you think your proxy provider isn't doing just that?

Privacy is a bigger thing for me than security.
And I have met my proxy provider, and I am he.

Re: Did the cool-aid taste good?

[BronsCon]

And I have met my proxy provider, and I am he.

I don't think that means what you think it means

proxy
präks/
noun
noun: proxy
1. the authority to represent someone else, especially in voting.

By definition, you can not proxy for yourself. If you own the proxies, the proxies are you and you gain no privacy through them; everything they do on your behalf, you are doing because you own them.

Or you're just a shit-tier troll. That actually makes more sense in this context, so I'd just roll with that explanation if I were you.

Re: Did the cool-aid taste good?

[arth1]

The SSL Session ID is deleted once you close the browser.

You've never heard of TLS Session Resumption nor supercookies?
With Chrome, it's hard to avoid either.

Re:Did the cool-aid taste good?

[Anonymous Coward]

Except where it's not their right :-P
(Probably would not stop them anyways)

Re: Did the cool-aid taste good?

[Anonymous Coward]

I agree, but just to add, if you "own" the example.com, you can add pretty much any subdomain you want under it, e.g., thegibson.dev.example.com. That aside, I haven't check, but I think they should keep a buried-deep-in-menus off switch for power-users, just-in-case.

Re: Did the cool-aid taste good?

[Anonymous Coward]

That's a valid point, but that's rather different from "the cert being the cookie".

Re:Did the cool-aid taste good?

[Anonymous Coward]

The concept of a certificate trust list has always bugged me. If I use Chrome, Google has decided what authorities are trustworthy. However, if I was ever defrauded by a fraudulent certificate issued by one of these authorities, I doubt Google would find themselves culpable.

Re: Did the cool-aid taste good?

[twokay]

The IANA provide reserved names for testing to avoid this type of situation. https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml

.test should be fine even if you are pedantic about naming a dev domain. There is .example and example.com/org/net as well.

Re: Did the cool-aid taste good?

[jeremyp]

Wait a minute. Are you suggesting that the proxy in the corporation in which I work is able to decrypt the traffic I send to https://google.com? Because I say bullshit. My browser would flag the invalid certificate that it presents to me.

Re: Did the cool-aid taste good?

[Zero__Kelvin]

There is nothing wrong with connecting to the internet and then violating the standard? Ok. When you do that there is nothing wrong with getting bit by your own stupidity either. The .com and .dev TLDs are controlled by ICANN, who issues them and ties them to a public IP address. If you then fuck up your internal DNS, that's on you chumley.

Re: Did the cool-aid taste good?

[BronsCon]

If your internal hostnames don't overlap with any public hostnames, you are not violating the standard. If you own the domain in question, you can guarantee that. What's the problem? Don't put *.dev.yourdomain.com in public END and you're golden.

Google, in this case, is wrong for assuming Chrome is connected to the internet and enforcing internet rules in-browser. There is no reason for that on, say, an air-gapped LAN, where Chrome will happily run.

Re: Did the cool-aid taste good?

[BronsCon]

Autocorrect... END == DNS

Re:Did the cool-aid taste good?

[bluefoxlucid]

You have to add your CA certificate (with the proper attribute CA: True) to your browser, and configure your proxy server to use client-first TLS bumping so it doesn't generate a new certificate every day. Then your caching proxy will work with HSTS sites.

Re: Did the cool-aid taste good?

[Zero__Kelvin]

That is not correct. All ICANN assigned TILes are for public hostnames, and should never resolve to hosts in the private IP range. You violate the standard at your own peril.

Re: Did the cool-aid taste good?

[BronsCon]

You care to link to a standards document that backs you up?

Re: Did the cool-aid taste good?

[BronsCon]

I agree, but just to add, if you "own" the example.com, you can add pretty much any subdomain you want under it, e.g., thegibson.dev.example.com.

Bingo.

Re:Did the cool-aid taste good?

[fisted]

HTTPS doesn't hide anything from the endpoint. That should be obvious?

If you mean the destination web server can decrypt the https traffic, then yes, it's obvious. The only difference between HTTP and HTTPS in this case is that when HTTPS is used only the destination web server can see the plaintext as opposed to every router and every three latter tap on the its path.

However, it does largely defeat the multipathing, proxy caching and rewriting possible with HTTP, all of which helps hide who accesses an endpoint

All of which also helps mess with the traffic and watch and filter the traffic on its way. That said, caching and rewriting are things that could be done locally.

as well as automatically adding an immutable identifier; the session key.

The session key is not immutable, it isn't called session key for nothing. It's about as immutable as the address+port 4-tuple that identifies a particular TCP connection.

When I access http://www.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 and http://www.cia.gov/page2 and the request comes from two different IPs, the site doesn't know that it's the same client accessing both pages. And when I access http://www.inflatableunicorns.... and my proxy deletes tracking information from the header (including IP address and browser fingerprints), they don't know that I'm the same person who visited last week. And they won't know that I looked at adcampaign.jpg either, because it can be served from a cache.

I get it, you like proxies and the ability to mess with and inspect your traffic on the way. It's ridiculous that you're oh-so-concerned about preventing three letter agencies from tracking you that you're opening them every door to get much better information - your payloads as opposed only your metadata. And obviously they're free to add their malware to your every download.

Now enter HTTPS, and how it changes this by trying to ensure a 1:1 connection.

Changes it mostly in a positive way, as pointed out.

the three letter agencies [] sit at the endpoints

For every endpoint where such an agency is actually sitting, there are 10 regular midway taps such an agency is operating.

I am, however, glad that you at least dropped the notion that https used client certificates. One step at a time.

Re: Did the cool-aid taste good?

[Zero__Kelvin]

I'm not going to do all your homework but you can start here. I hate posting links from a phone which is all I have to post with at the moment, but this should give you reason to suspect I might know about this issue enough for you to want to research it for yourself.

Re:Did the cool-aid taste good?

[Sigma 7]

The concept of a certificate trust list has always bugged me.

True, but you have to start somewhere. I'm not sure on the specifics, but there's likely something in place that allows companies to trust who writes those root certificates.

If I use Chrome, Google has decided what authorities are trustworthy.

Chrome uses the security certificate store found in the operating system. As such, it's either Microsoft, Apple, Google, or a random Linux distro that determines who is trustworthy depending on who wrote the device.

Mozilla uses it's own certificate store, although you can still modify it as needed.

Re: Did the cool-aid taste good?

[Zero__Kelvin]

No it wouldn't because your corporate CA would be installed as a trusted CA.

Re: Did the cool-aid taste good?

[BronsCon]

All that says is that Comodo won't issue certificates for non-routable IPs and non-registerable TLDs, which is a reasonable position for them to take and also a damn good reason to use a domain that you own (e.g. a registerable TLD) for your internal services -- it's the only way to get a properly signed certificate for those services.

Did you even read that before you linked to it? It pretty much explains exactly why you're wrong.

Re: Did the cool-aid taste good?

[Zero__Kelvin]

Are you on drugs? The .dev TLD is not available. They won't issue you a cert for it. If they have done so in the past they will revoke it. You CAN'T use .dev as an internal TLD legitimately. This is well known, was announced a long time ago, and it is the fault of any organization if they do so now. This shit isn't complicated. It is no different than if you try to tie a .com address to a local address. If you do it your shit is broken and you can fix it or leave it broken and cry like a little girl that things work the way they are supposed to today instead of the way they used to before the change.

Re: Did the cool-aid taste good?

[BronsCon]

Are you on drugs?

At the moment, Aleve. Does that count?

The .dev TLD is not available.

I never said it was; many others, however, are.

They won't issue you a cert for it.

Because you don't own whatever domain you're using.

If they have done so in the past they will revoke it.

And rightly so, as you don't own a .dev domain.

You CAN'T use .dev as an internal TLD legitimately.

I never said you could. I said you could use a domain that you own.

This is well known, was announced a long time ago, and it is the fault of any organization if they do so now.

Indeed it is.

This shit isn't complicated.

Indeed it is not.

It is no different than if you try to tie a .com address to a local address.

Almost. If you own the .com domain you're using, you're in the clear. The difference, of course, is that you can own a .com domain without being Google, which is a requirement for .dev.

If you do it your shit is broken and you can fix it or leave it broken and cry like a little girl that things work the way they are supposed to today instead of the way they used to before the change.

Actually, your shit's only broken if you use a domain someone else owns, or if you reuse public FQDNs for a domain you own on your private network. Even then, it's only broken if the end result is not what you intended; for example, if you want to display something different for those hostnames when accessed from your internal network, and that's the effect you achieve, you can hardly call it broken.

You still haven't pointed to any specification that disagrees with the above. What you have done, however, is made it very clear that you misunderstood what I wrote.

Re: Did the cool-aid taste good?

[Zero__Kelvin]

You just confirmed that .dev isn't available and so you can't use it. That was the topic, and that was the point. Have a nice day.

Re: Did the cool-aid taste good?

[BronsCon]

My first comment in this thread was:

There's nothing wrong with using .com for internal machines, provided your internal hostnames don't overlap with your public hostnames.

So, basically, what you're saying is I wasn't wrong the first time, yet you chose to argue with me anyway.

Re:Did the cool-aid taste good?

[110010001000]

You have hit on the truth, but most people are too ignorant to believe you. The fact is that the monitoring is done not by cracking HTTPS, but at THE ENDPOINT. The major companies are opening up their endpoints to whatever groups want to snoop on you. This is where the data collection occurs. If you use HTTPS it makes no difference because the endpoints are unencrypted. Mass surveillance is done not by snooping traffic, but tapping into the endpoints.

Re:Did the cool-aid taste good?

[110010001000]

Baloney. The bulk of data is collected at the endpoints. You cannot monitor that much packet traffic. There is just too much. If you don't believe me, there are companies that sell packet traffic monitors. Google, MS, Apple, etc open up their ENDPOINTS.

Re: Did the cool-aid taste good?

[Aighearach]

I didn't say, "this has to do with network neutrality." Try reading it again backwards.

Re: Did the cool-aid taste good?

[Zero__Kelvin]

You are big on making up your own rules aren't you. Read it backwards instead of forwards, ignore the standards and do it my way. Which reminds me that you absolutely do support "doitmyway", you just want the rest of the world to do it the way you want to rather than the way it is supposed to be done. Google owns the .dev TLD, just as they own *.google.com. If they want to force HTTPS on their domains they have every right to do so. You seem to have serious trouble grasping this simple concept.

Re: Did the cool-aid taste good?

[Zero__Kelvin]

No, I'm saying you still don't grasp what is going on. Google owns *.dev and *.google.com. Using any of those for your internal network named is wrong. For domains you own, so a VERY limited subset of .com, you can do that, but for 99.99999% of the cases using .com is wrong. I think you get that and we just got our signals crossed.

Re: Did the cool-aid taste good?

[BronsCon]

So, which is it? I don't get what is going or, or we got our signals crossed? Because I was responding to your remark:

Just as you should not use .com for internal machines you should not use .dev or you are violating standards.

That is why I mentioned .com... because you claimed it was a violation of standards. The whole while, all I was trying to do was point out that it is fine to use a domain you own. Look at it another way: it is fine cor Google to use .dev, because they own it. Right?

The only one here who got anything crossed is you. I read back through our conversation and i made it pretty clear from the start that I was talking about domains you own.

Re: Did the cool-aid taste good?

[Zero__Kelvin]

OK buddy. You clearly said. com for domains you own, even though you didn't say "for domains you own", and in that case it isn't limited to .com but you were specific about .com. You are a master communicator and there is no way anyone could have interpreted your statement any other way than how you meant it even though that's not how you said it. Good for you. Enjoy living in your own little world!

Re: Did the cool-aid taste good?

[BronsCon]

Okay, you really want to do this? Alright, then, here we go...

OK buddy. You clearly said. com for domains you own, even though you didn't say "for domains you own"

What part of "provided your internal hostnames don't overlap with your public hostnames" was unclear? The only way you get public hostnames on a domain is if you own it, right? Right.

Further, you claim:

The .com and .dev TLDs are controlled by ICANN, who issues them and ties them to a public IP address.

That's just flat-out wrong. DNS, which ICANN has nothing at all to do with, is what "ties [a domain] to a public [or private] IP address", or to none at all, as you can simply register a domain and never configure NS records for it. And it's more like pointing than tying; you can change your NS records to point to a different set of DNS servers -- and it's certainly not to a (single) IP address, either; you can have any number of hosts under a single domain, each of which may have its own IP, or even multiple IPs per host. I own, let's just say more than a handful of domains, and several have no NS records whatsoever; they are not tied to any IP address, by ICANN or by anyone else; they will be, when the projects they were bought for are ready to start using them, but, then, they'll be pointed (not tied) to dozens of IP addresses, possibly hundreds or thousands for some.

My very next comment further clarified that I was talking about domains you own:

If your internal hostnames don't overlap with any public hostnames, you are not violating the standard. If you own the domain in question, you can guarantee that. What's the problem? Don't put *.dev.yourdomain.com in public END and you're golden.

So, I made it clear in my first comment; I made it absolutely clear in my second... yet, you didn't realize that's what I was talking about until 12 comments in? So you're claim, then, is that you can't follow a conversation? Sorry, I'm not buying that. Here's why:

Your reply to my second comment was:

That is not correct. All ICANN assigned TILes are for public hostnames, and should never resolve to hosts in the private IP range. You violate the standard at your own peril.

That, right there, makes it very clear to me that you understand that I am talking about domains that you own or, at the very least, domains other than .dev (such as .com); yet, a handful of posts later, you're still on about .dev as though that's what I was talking about. It's also wrong; you can use a registered domain internally and, in fact, as you so aptly pointed out, if you want to use a widely trusted certificate internally, you must use a registered domain (which you own), or nobody in the default trust group of the major browsers will sign it.

Oh, wait, maybe you can't follow a conversation. Just remember, this is Slashdot and there is a text record of hte conversation just above the post you're reading, then maybe you won't lose these details anymore.

and in that case it isn't limited to .com but you were specific about .com

You specifically said .com, actually. I did mention .com in my first post, because it's the goalpost you propped up, but I later (in my very next post) said:

If you own the domain in question, you can guarantee that.

Where do I limit it to .com? Of course, 5 posts later you think I'm talking about .dev again (but remember, you literally, just above this very post that you are reading right now, said I limited it to .com):

Are you on drugs? The

Re: Did the cool-aid taste good?

[BronsCon]

(2/3) Slashdot doesn't like posts with a lot of quotes, so I have to break this up more than I thought I would...

You are a master communicator and there is no way anyone could have interpreted your statement any other way than how you meant it even though that's not how you said it.

I wouldn't quite say I'm a master but yes, I've studied both inter- and intra-personal communication, as well as human psychology. I know how to recognize a clearly-made point, even when I don't necessarily agree with or understand the point. I also (quite often, mind you -- as, again, I'm certainly no master) can recognize when, in retrospect, perhaps I was not so clear; this, my friend, is not one of those instances. You, however, have changed your position several times throughout this debate. To wit, direct quotes from each of your posts in this discussion, in order and with commentary:

Just as you should not use .com for internal machines you should not use .dev or you are violating standards.

You originally claim (incorrectly) that .com should not be used internally; in truth, domains you don't own (regardless of TLD) should not be used; domains you do own are fair game.

The .com and .dev TLDs are controlled by ICANN, who issues them and ties them to a public IP address.

You still limit the discussion to .com and .dev (something you later accused me of doing) and make an incorrect statement about tying to public IP addresses.

All ICANN assigned TILes are for public hostnames, and should never resolve to hosts in the private IP range.

I'll forgive the typo, as we all make them; we're human, after all. However, I cannot forgive the incorrectness of this statement, which is why I asked you to back it up by linking to the standard you claim to be referencing. I asked for this because I've never seen such a standard; because one does not exist. I was asking to be proven wrong, here, and would have accepted that I was wrong if you had done so; hell, if you do so now I'll still accept it. I won't hold my breath, though; I've been doing this for over two decades, I'm more than passingly familiar with the standards at play.

Re: Did the cool-aid taste good?

[BronsCon]

(3/3)

I'm not going to do all your homework but you can start here. [comodo.com]

And, of course, you link to a completely unrelated document detailing one company's policy regarding issuing certificates. That page does link to a couple of standards documents (ratified RFCs), but neither of them support your position. Of course, I point this out, hoping that you simply linked the wrong URL and still might educate me further on this issue. In the end, I'm disappointed, of course.

The .dev TLD is not available. [...] It is no different than if you try to tie a .com address to a local address.

You go on about .dev although I've not mentioned .dev once at this point. You also continue limiting to .dev and .com and make yet another incorrect statement regarding tying (pointing) a domain to a local address. Still waiting on the standards document that disallows this.

You just confirmed that .dev isn't available and so you can't use it.

I never claimed otherwise; but you confirmed, there, that you thought I had. How, exactly? Since you read and understand perfectly what people write (even if they're not writing what they think they are), as you imply in the post you just wrote, surely you noticed that I hadn't mentioned .dev at all until just then. Clearly, I wasn't arguing anything relating to .dev.

No, I'm saying you still don't grasp what is going on. [...] For domains you own, so a VERY limited subset of .com, you can do that [...] I think you get that and we just got our signals crossed.

I don't grasp what is going on? Oh, no, I've gotten that you're a Slashdot troll since way before this particular conversation started. You've missed that I enjoy baiting the trolls here, it keeps me sharp. You also just changed your position yet again; remember when you said "you should not use .com for internal machines", "The .com and .dev TLDs are controlled by ICANN, who issues them and ties them to a public IP address", "All ICANN assigned TILes are for public hostnames, and should never resolve to hosts in the private IP range", and "It is no different than if you try to tie a .com address to a local address"? Now you're admitting that all of those statements are false and expecting me to carry on as though you never said them and I was the one who was wrong this whole time? No. Admit you were wrong, it's a learning experience and it's good for you. I do it all the time (though, less and less on Slashdot, lately); it's actually the first step in correcting an incorrect understanding of a subject. You can't very well let go of incorrect beliefs, even if you acknowledge the beliefs someone else expounds are in fact correct, if you can't admit that your beliefs are incorrect. You've just contradicted everything else you've said to this point so, clearly, one set of beliefs you are expressing is incorrect. Decide which it is and admit it.

And of course I get it, it's what I've been saying this whole time. Thus, I didn't get anything crossed; but you, very clearly, did.

As for the standards, see RFC 1035: DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. Specifically, note the complete lack of restriction on where a domain may be used, whether or not it is ICANN-managed and whether or not you own it. Read all 25 updates if you want to be extra sure, and go ahead and read all the updates to those, and so on, and so forth.

If I'm missing something, well, I've been asking you to point it out for the last 5 posts. 6 if you count this one. Which ratified RFC describes the standard you were previously claiming exists?

Re: Did the cool-aid taste good?

[Aighearach]

No, my sport is chess and nobody cares about your rules. Nobody cares if you claim your proposed rule really is used in your neighborhood.

Why would you be making rules about what I say, anyways? Surely I would make my own rules.

You say a bunch of weird words, but they only underscore that you did not comprehend the comment you were replying to. Try again next time! (I know you will!)

Google doesn't own shit on people's private networks, that's just you not comprehending the contexts where a standard applies, and the contexts where their ownership of imaginary property exists.

Re: Did the cool-aid taste good?

[Zero__Kelvin]

If you create a server called anything ending in a domain owned by someone else you are a moron. Check mate. Off you go now ...

Re: Did the cool-aid taste good?

[Aighearach]

Oh, snap, OK.

You're right on that; if you say I'm a moron, you did say I'm a moron!

You've succeeded in proving you choose your words, you haven't presented any evidence of ownership over somebody else's private network.

I don't think any side of the debate really cares about what insults neckbeards spew.

Re: Did the cool-aid taste good?

[F.Ultra]

TLS Session Resumption even on Chrome is only possible if you do not close the browser since the TLS Session ID is not stored to disk. Cookies is a whole other mess that have nothing to do with TLS and works just as fine (for the trackers) if not better on plain HTTP.

Fuck off with this security bullshit.

[Anonymous Coward]

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.

[Anonymous Coward]

what kind of idiot would invent their own false tld to make this a problem?!

Re:Fuck off with this security bullshit.

[steveb3210]

You don't own the .dev tld!

Re:Fuck off with this security bullshit.

[steveb3210]

That, and its really fucking easy and free to configure SSL everywhere these days. Stop whining.

Re:Fuck off with this security bullshit.

[bluefoxlucid]

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: Fuck off with this security bullshit.

[Anonymous Coward]

I agree, and I've found FF to be even worse. They've made it almost impossible to use extensions you've written yourself with the stable release. The last time I tried to write an extension I would have had to get it reviewed and signed by Mozilla, or I would have had to use the beta-quality FF Developer Edition and even then I could only install my extension temporarily. I wrote this extension myself and I want to use it on my own computer! I shouldn't have to get it reviewed and signed by Mozilla just to use it! I know it isn't malicious because I created it! I went back to Chrome because as much as I dislike Chrome, at least it allowed me to easily use an extension I wrote for myself. FF has effectively become a high-walled garden, except unlike Apple's walled garden the FF 'garden' is more like a cess pool with bloated and stinky turds floating all over the place.

Re:Fuck off with this security bullshit.

[hierofalcon]

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.

[ripvlan]

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 lab using it. Along with 10.x addresses (some of which are internally routable by some companies -- make sure to check on that too- this would be internal IT strategy).

Seriously - it would be like attempting to create a subdomain under mypc.xxx.microsoft.com It might work for a bit but shouldn't.... so don't do it.

Okay - maybe the .dev was unassigned until a few years ago. You should plan on migrating to a reserved entry.

Re:Fuck off with this security bullshit.

[sjames]

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 a trick performing dog, I just want to pull HTML down from an HTTP server.

Re:Fuck off with this security bullshit.

[arth1]

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.

[thegarbz]

So on behalf of all the developers at my company, fuck you Google. Keep it up

On behalf of all the developers outside your company, great work Google. Keep it up.

Nanny states develop in an attempt to shield idiots from themselves. If you were affected by this there's a good chance you're part of the problem.

Re:Fuck off with this security bullshit.

[Anonymous Coward]

My company uses an HTTPS proxy and only pushes their public key to the major browsers. So anything else that uses HTTPS and refuses to accept an invalid certificate fails.

As a developer, that's fucking irritating.

Re:Fuck off with this security bullshit.

[steveb3210]

LetsEncrypt doesn't need to access your internal server - you can use the DNS version instead..

Re:Fuck off with this security bullshit.

[arth1]

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:Fuck off with this security bullshit.

[flink]

Not every DNS zone is publicly accessible. Some test servers don't even have DNS names.

Re:Fuck off with this security bullshit.

[Aighearach]

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.

[Junta]

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:Fuck off with this security bullshit.

[Junta]

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:Fuck off with this security bullshit.

[Anonymous Coward]

Cause shitty internal security practices become shitty external security practices.

Shit heads like you are why this happened.

Re:Fuck off with this security bullshit.

[sjames]

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:Fuck off with this security bullshit.

[the_other_chewey]

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:Fuck off with this security bullshit.

[steveb3210]

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:Fuck off with this security bullshit.

[cdu13a]

.local is big a pain in the ass, that Is not recommended to use in most cases.

Re:Fuck off with this security bullshit.

[The MAZZTer]

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.

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

Re:Fuck off with this security bullshit.

[sjames]

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.

[arth1]

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:Fuck off with this security bullshit.

[Anonymous Coward]

uh maybe you need to understand dns/networking better... if your going to make up something for dev make third and forth level domains and keep your company branding instead of a false tld so along lines: host.dev.company.tld instead of idiotic bs

Re: Fuck off with this security bullshit.

[Anonymous Coward]

Fuck cert. It's my network I'll do what I want.

Re:Fuck off with this security bullshit.

[Anonymous Coward]

So you have idiot developers. Fire them.

Re: Fuck off with this security bullshit.

[Zero__Kelvin]

And if *you* understood you would know .dev is a valid ICANN assigned TOLD not available for your internal use. You don't get to violate standards and then cry foul because the rest of the world follows them.

Re:Fuck off with this security bullshit.

[Anonymous Coward]

This is why I use Firefox.

Re: Fuck off with this security bullshit.

[Zero__Kelvin]

No. You don't.

Re: Fuck off with this security bullshit.

[Zero__Kelvin]

Use a proxy.

Re: Fuck off with this security bullshit.

[Zero__Kelvin]

It is very easy to setup up automatic renewal.

Re:Fuck off with this security bullshit.

[Anonymous Coward]

It has nothing to do with DNS. If I've registered MyBallsAreHuge.dev and it's publicly accessible, google should not be forcing me to use https on the domain if I choose not to.

Re:Fuck off with this security bullshit.

[The MAZZTer]

Users will always decide for convenience over security and complain about the lack of security when they get hacked.

Re: Fuck off with this security bullshit.

[sjames]

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.

[Anonymous Coward]

So you're saying organisations are supposed to regularly monitor the internet to see if their internal domain becomes a real one and if it does generate a new one that somehow doesn't clash with existing ones?

Re:Fuck off with this security bullshit.

[arth1]

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.

[Anonymous Coward]

You can create your own internal CA, which is what I ended up doing thanks to earlier developments with Chrome stepping up restrictions such that I could no longer access internal dev sites using self-signed certificates. There are software packages to do it for you, but you can also just use OpenSSL's command line tools to do it by hand.

It's fucking obnoxious and should be unnecessary, but it's doable.

All I want from Google is the ability to designate certain servers "development" and then not have to deal with setting up proper SSL environments on them. I'm not going to deal with buying certificates for them and since they're not on the public Internet I'm not going to deal with Let's Encrypt or whatever.

Sure, they might not be "secure", but for fuck's sake let me trust a certificate I myself made. It's easier than jumping through hoops for no damned reason. I don't care that it's not set up 100% correctly, as long as it's enough to test the site when inside an SSL environment.

Sadly it's clear Google is going in the opposite direction.

Re: Fuck off with this security bullshit.

[Anonymous Coward]

Wait, what? Now a standards committee owns my private network?

Re:Fuck off with this security bullshit.

[Anonymous Coward]

You don't own the .dev tld!

Of course, when most of these systems went live, no one owned the .dev TLD. Because there wasn't one. And if they migrate to something else (which better not be .foo), then they better hope that doesn't become a TLD later, too, or they'll have to repeat the whole exercise. Yet another fun and interesting arbitrary TLD timebomb.

Re:Fuck off with this security bullshit.

[Junta]

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

Re:Fuck off with this security bullshit.

[viperidaenz]

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:Fuck off with this security bullshit.

[Anonymous Coward]

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

Re: Fuck off with this security bullshit.

[Zero__Kelvin]

I'm saying that as standards evolve we are all required to adapt. Nobody needed to "monitor the internet" on this one. It was widely announced and Slashdot has covered it many times. If you don't have anyone in your company who keeps up on current events in the industry that is on your company, not the industry.

Re: Fuck off with this security bullshit.

[Zero__Kelvin]

So this is a non-issue for those servers then, isn't it?

Re:Fuck off with this security bullshit.

[sjames]

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: Fuck off with this security bullshit.

[Zero__Kelvin]

Your sandbox is filled with faux sand. I'm sorry you are not standards compliant, but that isn't Google's fault now is it?

Re: Fuck off with this security bullshit.

[Zero__Kelvin]

No it isn't, because those servers don't have a domain name ending in .dev, as that is an ICANN assigned TLD. This is what you aren't grasping. It is like you are labeling all the rooms in your house with street addresses and then complaining that the post office keeps delivering letters to another house instead of your living room or kitchen.

Re:Fuck off with this security bullshit.

[sjames]

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: Fuck off with this security bullshit.

[hierofalcon]

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.

Re: Fuck off with this security bullshit.

[sjames]

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:Fuck off with this security bullshit.

[arth1]

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/ may do what she thinks, but her request for http://www.gimpoutfits.biz/ may lead her to a different site altogether.

Re:Fuck off with this security bullshit.

[Anonymous Coward]

"on the internet" means nothing.

Re: Fuck off with this security bullshit.

[sjames]

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 that envelopes are now rigged to self-destruct if I try to take them into my house. The kids just wanted to play post-office, not actually deliver the mail to outsiders.

Re:Fuck off with this security bullshit.

[skids]

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:Fuck off with this security bullshit.

[tepples]

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: Fuck off with this security bullshit.

[tepples]

It costs $15 to generate a new internal domain (source: Gandi.net), and $15 per year to keep it. Generate one in advance.

Re: Fuck off with this security bullshit.

[tepples]

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 outside secure contexts.

Re: Fuck off with this security bullshit.

[tepples]

Then for what name outside .dev should the operator of a private server on a home LAN obtain a certificate?

Re:Fuck off with this security bullshit.

[tepples]

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.

True. But you don't control the set of certificate authorities (CAs) recognized by the operating systems installed on devices brought by guests invited to your private network.

Re:Fuck off with this security bullshit.

[evileeyore]

.dev has been used for local development for a LONG time. almsot every dev tha ti know has a local enviornment of some kind that uses .dev. In my opinion the real issue here is that ICANN let anyone register the .dev tld. Just because google put a bid in for it doesn't mean that i should be required to access my Localhost webserver over https....

Re: Fuck off with this security bullshit.

[WaffleMonster]

I'm saying that as standards evolve we are all required to adapt.

What was really hard to intuit or predict is that someone who happened to own a browser would take ownership of a TLD and hard code bogus rules for that TLD into their browser.

People with properly configured DNS who have explicitly delegated .dev namespace to themselves for Internal use rather than Internet use and have better things to do than read Slashdot could not have reasonably predicted something like this would creep up. It's a left field thing that isn't the developers fault to be blindsided by.

The primary sin is an invalid assumption by Google incorrectly equating all names resolved by operating systems name resolution facilities to Internet names. This simply is not a valid assumption to make. There is no standard that declares global Internet owns the whole frigging namespace and everything else is subservient to the Internet or even assumes DNS itself is only to be used in conjunction with the global Internet.

Re:Fuck off with this security bullshit.

[tepples]

Is your company's IT department aware that use of most HTTPS proxies will "reduce connection security and [...] introduce severe vulnerabilities"?[1]

[1] Zakir Durumeric, Zane Ma, Drew Springall, Richard Barnes, Nick Sullivan, Elie Bursztein, Michael Bailey, J. Alex Halderman, and Vern Paxson. "The Security Impact of HTTPS Interception". Proc. 24th Network and Distributed Systems Symposium (NDSS ’17), 2017-02. Accessed 2017-11-30.

Re:Fuck off with this security bullshit.

[Anonymous Coward]

It's not. It isn't the DNS server, but the BROWSER that is blocking the non-HTTPS connections.

Re:Fuck off with this security bullshit.

[edtice1559]

Apparently neither the OP nor the mods understand how DNS works. If you have internal resources, use the TLDs reserved for this purpose. The RFC was published in 1999! https://tools.ietf.org/html/rf...

Re:Fuck off with this security bullshit.

[edtice1559]

And you will run into "conflict and confusion" if you do this. As I've pointed out already, there was an RFC for this in 1999. The "right" way to do this has been defined for almost two decades. So you can either be self-righteous and declare that it's your local network and you'll do what you want (in which case, you should probably disconnect it from the internet) or you can follow the well-defined standard and avoid difficulty. https://tools.ietf.org/html/rf...

Re: Fuck off with this security bullshit.

[F.Ultra]

Which is why god (Odin) invented the corporate web proxy.

Re: Fuck off with this security bullshit.

[F.Ultra]

So create a self signed cert for .dev and install it in your browser as a ca.

Re:Fuck off with this security bullshit.

[arth1]

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.

Yes, but the site might be an external site. Like if someone internal goes to http://www.dell.com/, they can be sent to an internal site that fetches information from Dell's portal but shows the corporate pricing. Or presents a different www.google.com front page that aggregates google's search with an internal search. Or...

Re: Fuck off with this security bullshit.

[sjames]

Not saying there is no workaround, just that the browser is creating extra hoops to jump through for the purposes of Nerfing the world.

Nerf hammers can be fun, but not if you want to patch the roof.

Re:Fuck off with this security bullshit.

[WaffleMonster]

And you will run into "conflict and confusion" if you do this. As I've pointed out already, there was an RFC for this in 1999. The "right" way to do this has been defined for almost two decades. So you can either be self-righteous and declare that it's your local network and you'll do what you want (in which case, you should probably disconnect it from the internet)

This is the whole point.

People who may not even be connected to the Internet and who run their own .dev namespace separate from the global Internet namespace are being hit with a bug in Chrome that assumes ".dev" must always be an Internet name.

RFC2606 was intended to offer some explicit disambiguation between local and Internet namespaces allowing for both to be utilized concurrently.

This necessarily relies on the underlying assumption an Internet namespace is in play or the operator has not otherwise explicitly designated namespace as non Internet DNS.

Re: Fuck off with this security bullshit.

[Anonymous Coward]

For those of us that do local development on these supercomputers we all carry around, setting up a DNS server when a one line hostfile entry will do is a bit overkill. Just because I have 4 to 8 cores ad 16gb of memory on my lap doesn't mean I want to waste my time setting up a DNS server for a few static docker containers

Re:Fuck off with this security bullshit.

[Strider-]

This is why split horizon DNS was developed. DNS server answers differently depending on where the request came from. Comes from your internal network, or the VPN? answer one way. Comes from the public internet? answer the other.

Re:Fuck off with this security bullshit.

[tepples]

Like if someone internal goes to http://www.dell.com/, they can be sent to an internal site that fetches information from Dell's portal but shows the corporate pricing.

If the user is logged in to his user account on Dell's website, and this account has been configured with permission to show corporate pricing, then the site will show corporate pricing. The client IP address need not enter into it.

Or presents a different www.google.com front page that aggregates google's search with an internal search.

If the user is logged in to his Google Account, and this account has configured with permission to include internal search, then the results will include those of internal search. The client IP address need not enter into it.

Re:Fuck off with this security bullshit.

[Anonymous Coward]

True. But you don't control the set of certificate authorities (CAs) recognized by the operating systems installed on devices brought by guests invited to your private network

BYOD on our private network... sure just connect to our WiFi. We have 23 * 0 access points around the office for maximum coverage. The SSID is "nochanceinhell" /w password "rofl".

Re:Fuck off with this security bullshit.

[Anonymous Coward]

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.

Doesn't matter. It's the netop's job to deal with it. They planned to use that TLD that way, so it's now up to them as to whether or not to change anything. (Easiest thing to do would be to add it to the internal DNS, if it was deemed important enough. But that's the netop's choice.)

This is no different than choosing to use an alternative DNS root. It's the netop's choice. They deal with the consequences of that choice.

Where we do have a problem is Google suddenly breaking the entire TLD because they want to. Case in point: If you are using an alternative DNS root, then that TLD could be used for anything under any circumstance. (It's not bound to IANA, so the RFCs for restricted names need not apply.) With Chrome mandating HTTPS with HSTS, suddenly it doesn't work anymore, because the sites are not configured that way. Worse, if they (Google), are allowed to get away with doing this, what's to stop them from requiring it from every domain? Or what's to stop them from rejecting valid HTTPS if it's cert isn't from an authority that Google approves of? (A.K.A. We won't trust your CA or allow you to add it to the trust chain.)

This is the problem with Google. They constantly change the definition of "secure" and demand that everyone follow suit. Damn be anyone affected by the changes. I've already had to reroll certs twice this year because of Chrome updates. Everything else works fine, but Chrome would refuse to connect. Of course, good luck telling users that they can't use the browser that they want to.

Domain Name Services as defined by IANA may be the defacto standard, but it's not the only one, and DNS itself isn't designed as to be managed by a single entity. Google needs to back off. If your browser malfunctions because it's playing with a non-Google approved Domain Name Service, then the browser is broken, not the Domain Name Service in use. (Typing it out because slashdot's filter won't let me type the abbreviation again.)

Re: Fuck off with this security bullshit.

[dgood]

Then for what name outside .dev should the operator of a private server on a home LAN obtain a certificate?

Just create your own CA then and generate whatever certs you want. Or use self-signed certs.

Re: Fuck off with this security bullshit.

[BronsCon]

Even if you buy myinternaldomain.dev, Chrome will force HTTPS on it.

And really, it costs $0 to generate a new internal domain (source: dnsmasq, bind9, or any other DNS server you can self-host) and $0 per year to keep it. When you pay to register a domain, you're paying for the ability to make it publicly resolvable.

Re:Fuck off with this security bullshit.

[BronsCon]

The thing is, even if you do own the .dev domain you're using, Chrome is going to force the use of HTTPS on it. That's the real problem, here.

Re:Fuck off with this security bullshit.

[Anonymous Coward]

Don't use .local... .test .example .invalid .localhost

Re:Fuck off with this security bullshit.

[c21fb8be87e6]

Do not use an invented TLD. If ICANN were to delegate it, you would be in big trouble. Same thing if you merge with another organization which happens to use the same dummy TLD. That's why globally unique domain names are preferred. The standard, RFC 2606 reserves names for examples, documentation, testing, but nothing for general use, and for good reasons: today, it is so easy and cheap to get a real and unique domain name that there is no good reason to use a dummy one. So, buy megacorp.com and use it to name your devices. https://serverfault.com/questi...

Re: Fuck off with this security bullshit.

[tepples]

it costs $0 to generate a new internal domain (source: dnsmasq, bind9, or any other DNS server you can self-host) and $0 per year to keep it.

Public CAs don't issue certificates for hosts in $0 domains, and the root certificate for your private CA isn't always easy to install on devices brought by guests.

Re: Fuck off with this security bullshit.

[BitZtream]

No, thats the entire point of .local tld

You dont need to make one up, you just have to bother to do a basic google search before you make ignorant assumptions for your organization.

Of course the larger you get with something like this before someone in your stupid ass company points out that your doing it wrong by not using .local really is more of an indication that your tech staff is completely inept.

If you dont already use .local your an idiot, the rest of thisis just a question of what level of ID10T you are

Re: Fuck off with this security bullshit.

[Anonymous Coward]

At least you answered my earlier question. The reason developers keep doing this is because developers are morons.

Re: Fuck off with this security bullshit.

[F.Ultra]

Welcome to the world of software development :-)

Re:Fuck off with this security bullshit.

[Anonymous Coward]

Maybe if the browsers gave sensible warning instead of hiding the details, so the user could easily tell the difference between a self-signed cert, a cert that expired a day or two ago, and going to x.com, but the cert is y.com, maybe users could make sensible choices instead of getting into the habit of knee-jeck accepting all.

Re: Fuck off with this security bullshit.

[BronsCon]

I was looking at this from the viewpoint of the people complaining that they can't use Chrome on their private .dev hosts without HTTPS, as though you were suggesting they use a different domain instead. Now that I see what you were getting at, you are right, but I'd like to point out that you can register domains for a lot less that $15/yr.

Re: Fuck off with this security bullshit.

[Anonymous Coward]

And you may do whatever you want on your network.

You're complaining about downloading an application written by someone else, and running it on your network. That means you have to play by commonly accepted rules like everyone else.

Don't like that? Fork the application and modify to taste, then become your own maintainer and enjoy all the associated work.

Re:Fuck off with this security bullshit.

[complete loony]

And what do you do when your engineers leave HQ and go to consult onsite?

Re: Fuck off with this security bullshit.

[Anonymous Coward]

ICANN is the violator. They listened to $$$ rather than the people who told them don't allow registration of all these top level domains.

Re: Fuck off with this security bullshit.

[Anonymous Coward]

"TOLD" ?

Re: Fuck off with this security bullshit.

[Anonymous Coward]

Yep, looking over Google searches it is not hard to find articles going back several years saying, "Hey, don't use .dev. There are several domains set aside for what you are using .dev for."

I saw mention that .dev belongs to Google? Wonder if Google uses it for internal testing?

Re:Fuck off with this security bullshit.

[Aqualung812]

Competent DNS admins have been paying a whopping $15 bucks or so a year to go out and secure companydnsname-dev.com for a LONG time so that they're never bit with conflicts.
Cheap and competent DNS admins set aside dev.companydnsname.com for DEV use for $0 a year.
I don't run things internally that someone externally can claim.
See also: people that use 1.0.0.0/8 or class E addresses internally.

Re:Fuck off with this security bullshit.

[Anonymous Coward]

The private use reserved value are bloody useless anyway. .localhost? Might as well type the bloody IP at that point. .test? I'm not testing. .invalid? I'm not trying to create invalid DNS. .example? It's not an example.

So what do I use? Ideally I want short, easily remembered hostnames. pf.tld, nas.tld, myname.tld. Incredible lack of foresight in the reserved values list, compared to reserved IPv4 subnets where we have ample choice! The wider internet has .com, .net, .org and a billion other 3 letter TLD, but there isn't a single low char length reserved TLD.

We use .lan, .ext and .v (for dot vagrant) internally, and I will be swearing to high heavens if ICANN ever delegate .lan. It, like .dev, is DEFACTO reserved and this should be written into an RFC and ratified ASAP.

Re:Fuck off with this security bullshit.

[Anonymous Coward]

my-real-local-network-service-in-production-with-real-local-users.test?

Re:Fuck off with this security bullshit.

[johannesg]

I have trouble understanding how anyone would want to rely on anything made by Google, given their history of dropping services that aren't immediately profitable to them. I don't mind occasionally using their search engine, but any kind of business model that depends on _anything_ from Google is just a really bad idea, since it might disappear from one moment to the next.

I'm in the process of implementing a scripting engine. V8 was on the shortlist for evaluation, and ultimately discarded for one reason only: it is made by Google, and for all I know it could disappear tomorrow (and be replaced by something I cannot integrate).

Re: Fuck off with this security bullshit.

[Anonymous Coward]

No, thats the entire point

that's

You dont need

dont't

that your doing it wrong

you're

If you dont already use .local your an idiot

don't, you're

the rest of thisis just a question

this is

Now, whom did you say was an idiot?

Re: Fuck off with this security bullshit.

[Anonymous Coward]

It's my network I'll do what I want.

If you want to 'do what you want' on your network you should create your own browser (easy enough, base it on Chromium or Firefox) rather than using a commercial browser (Chrome) which is basically designed for internet , not intranet use.

If you're creating a system which will ultimately be used via the internet, then it's probably a good idea to live within Chrome's limitations because it will make it more likely your system will work when you release it.

Re: Fuck off with this security bullshit.

[Anonymous Coward]

It's bitztream the autism-hating, custom EpiPen-hating, Musk-hating, Qualcomm-hating, Firefox tabs-hating, Slashdot editors-hating Slashdot troll!

Re: Fuck off with this security bullshit.

[Zero__Kelvin]

Set up self signed certificates for use internally. That's why God created them. :^)

Re: Fuck off with this security bullshit.

[Zero__Kelvin]

No, that is not the topic, because by definition those servers do not end in .dev. That's the part you don't seem to be able to grasp.

Re: Fuck off with this security bullshit.

[sjames]

Clearly you do not know what "by definition" means. By definition, red paint isn't blue. By CONVENTION fire trucks aren't blue.

Re: Fuck off with this security bullshit.

[Zero__Kelvin]

Standards provide the definition dumbfuck.

Re:Fuck off with this security bullshit.

[ripvlan]

go ahead and register that .Dev site. I don't think you can ... because .dev isn't open for registration and is owned by somebody else. Because somebody has "borrowed" the .dev TLD that they didn't own -- then the owner came along and imposed rules - not sure you can complain. Whine a lot, certainly.

Since Google owns it for their own use - they make up the rules. If they started selling subdomains to any-taker then it might come with a caveat "SSL only"

Re:Fuck off with this security bullshit.

[ripvlan]

thank you. I meant localhost - my network admin read the papers and implemented it. I just knew not to use un-used domains because - someday they'll get used - so he figured it out. Plus the lab was off the grid - but we still allowed a select few sub-domains or specific servers to resolve (like our upstream WSUS server) via forward references on the private DNS server and get out through the firewall. .local appears to be the mDNS https://tools.ietf.org/html/rf...

Re: Fuck off with this security bullshit.

[sjames]

And the ICANN root servers are not part of a standard. There exist other DNS roots, and according to another /. story, there will soon be yet another.

The ICANN root is normally used for world reachable servers to avoid confusion, but that is convention. If you dig down far enough, the closest to a standard you will find is "Because Jon Postal said so".

Re: Fuck off with this security bullshit.

[Zero__Kelvin]

You are a fucking idiot.

Re: Fuck off with this security bullshit.

[sjames]

Translation, you cannot be wrong because it would break your ego?

All you needed to do is just not reply. Your resorting to a one line ad-hominem tends to confirm this.

Do further entertain me though! Feel free to reply with a reference to an actual standard that shows that no .dev server exists on a non world routable network.

Or pound impotently on your desk shouting about someone being mean to you on the internet. Doesn't matter to me.

Re: Fuck off with this security bullshit.

[Zero__Kelvin]

I don't give a shit if you pride yourself on your ignorance. Have a ball. Run your own DNS server and add an entry for *.com to 127.0.0.1 for all I care.

Re: Fuck off with this security bullshit.

[sjames]

Hrmmmm, no links to any standards I see.

Re: Fuck off with this security bullshit.

[Zero__Kelvin]

I don't doubt you don't see any. That would require a basic technical competence you clearly lack.

Re: Fuck off with this security bullshit.

[sjames]

It would also require you to post one rather than amateurish insults.

Re: Fuck off with this security bullshit.

[Zero__Kelvin]

Yes, because it is my responsibility to teach you what I, ICANN, Google, and every competent person already knows. Plonk.

Re: Fuck off with this security bullshit.

[Anonymous Coward]

Another glorious pwn!

Re: Fuck off with this security bullshit.

[Aighearach]

If you understood networks a little better, you'd understand that ICANN can't invalidate your private network names.

And no, no standards are violated.

Re: Fuck off with this security bullshit.

[Aighearach]

Nobody questions that part, for sure. People declared it harmful. Indeed.

That's not the debate.

Re:Fuck off with this security bullshit.

[Aighearach]

Right, but you're just not understanding the argument, so you're giving meaningless citations about things that are not in dispute.

Re: Fuck off with this security bullshit.

[Zero__Kelvin]

.dev isn't your private network name anymore than google.com is, and that's the part you need to understand if you ever want to get a clue someday.

Re: Fuck off with this security bullshit.

[Aighearach]

You would have to look somewhere other than the network names to know if a network is public or private, I recommend considering drawing a network map and figuring out what network you're actually on! Instead of just guessing by the names.

It is like walking down a private street and insisting it is a public street because the houses have numbers.

Re:Fuck off with this security bullshit.

[Anonymous Coward]

It's ironic that you use .local. It is not a reserved TLD, and there is already confusion as to how names should be resolved for that space (bonjour vs my server being authoritative for .local).

Simple solution

[smooth wombat]

Don't use spyware posing as a web browser.

Re:Simple solution

[Anonymous Coward]

Exactly!

Also, maybe of you'd use a different browser on occasion you'd see your shit only works in Chrome because you're too lazy to try anything else.

Not everyone has Chrome. People say they want Chrome on their work computer but they don't REALLY want it... because oh man is it HILARIOUS when you have someone open up a Chrome browser that's projecting in a conference room and their xxx bookmarks show up from at home!

More make-work, less productivity

[RightwingNutjob]

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.

Re:More make-work, less productivity

[thegarbz]

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:More make-work, less productivity

[RightwingNutjob]

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.

Re:More make-work, less productivity

[redmasq]

Once logged in, it takes about 10 minutes on the average Linux machine and about 15 on the average Windows 7 with Cygwin machine, including coffee breaks, to setup a private certificate authority, convert the public key cert, and copy it to a flash drive. Installing as a trusted certificate authority onto multiple Windows machines can be done rapidly using group policy, if available, or Powershell script from an admin account if not. It takes a couple of minutes per CSR to sign for the webservers and random numbers of minutes to get them into IIS. Apache is a bit faster.

That said, I have not read the details of the change, but I hope there is a readily accessible power-user option to turn it off. I worked for several companies with IT department that demands exclusive control over whatever CAs are out there but takes forever fulfilling new signing requests. I am not at one now, but through the lens of past experience, it is better to have the option to control the behaviour.

Re:More make-work, less productivity

[thegarbz]

No it's not. This isn't task based.

Not doing it, and doing it correct is both fast and easy. If it's not then *you* are doing it wrong. But that was clear when you mentioned managing expiring certificates on your own dev server. Why would you set an onerous expiry date on a certificate used for internal development?

when it isn't necessary. But I repeat myself.

Yes you do, but simply saying something doesn't make it so.

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

Not an issue

[Murdoch5]

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.

Re:Not an issue

[Anonymous Coward]

Sure, you have the extra hours to screw around getting certificates sorted out.

Certificates for production are reasonably well understood and straightforward. But for internal use, you've really REALLY got to really muck around with CAs or self-signed-certificates (which, of course, completely invalidate HTTPS anyway.) It's a right PITA.

The real issue is Google presuming they own the internet and baking in things like this - they don't.

Re:Not an issue

[edtice1559]

No, you use HTTP with properly named machines.

Just buy local...

[Anonymous Cashews]

I prefer to use .local for my internal network. Problem solved.

Re:Just buy local...

[Anonymous Coward]

This user is a Pedobear Troll! Hide your chikdren and goats!

Re:Just buy local...

[Anonymous Coward]

I prefer to use .local for my internal network. Problem solved.

.local can conflict with zeroconf shit in various ways, unless you're certain you've entirely disabled everything related to it, and as such is not recommended.

You should use .test, although there still could be DNS server/resolver or firewall issues with it (but it's the same with all the others, except for .localhost if you're only doing this on your local machine...).

Don't forget to add an entry in your host file or DNS server/resolver for .test itself, with no subdomain, to avoid contributing to root server hammering in case of misconfiguration or typo.

Re:Just buy local...

[Anonymous Cashews]

Don't forget to add an entry in your host file or DNS server/resolver for .test itself, with no subdomain, to avoid contributing to root server hammering [wikipedia.org] in case of misconfiguration or typo.

I got the .local entries set up in dnsmasq that is running from inside a FreeNAS jail.

Re: Just buy local...

[Zero__Kelvin]

That's bad advice. .test implies it is a test server, not a development server.

Re:Just buy local...

[Anonymous Coward]

This user is a Pedobear Troll! Hide your chikdren and goats!

Re:Just buy local...

[Anonymous Coward]

You are a baffling creature, Christopher Dale Reimer.

Re:Just buy local...

[Anonymous Coward]

There you are spamming amazon affiliate links with yet another fake account, you revenue stream hogging disgusting fat sexist tube of lard, Christopher Dale Reimer!

You can be sure I will be watching this fake account too. I know this is you because you told me you were working on your freepass 11 file server and you are so dumb that you can't even masquerade yourself properly.

Now, I told you I was out of meds last week and you didn't even care to contact me you lazy fucker.

How many times do I have to express the emergency of the situation??????

The python click script you wrote for my pheromone revenue stream web site suddenly stopped to work!!!!!!

You fucking incompetent python script writer!!!

When it works, I get 4000+ clicks a day on my pheromone revenue stream web site but only 5 or 6 without it!!!!

Now, it seems like you dont care and that you have abandoned me you heartless fucking pig!

Bonus:
Here is a story that creimer told me when convincing me what a hard life he had:

The tree was him and the tree knot was his butt hole!

So, his uncle packed his fat ass with lard and with his cock! Not that it makes much of a difference but anyway, there it is!

Signed:
The girl that used to love you and now hates you, burn in hell where you belong you sexist pig!

Re:Just buy local...

[Anonymous Coward]

There you are again spamming amazon affiliate links with yet another fake account, you revenue stream hogging disgusting fat sexist tube of lard, Christopher Dale Reimer!

You can be sure I will be watching this fake account too. I know this is you because you told me you were working on your freepass 11 file server and you are so dumb that you can't even masquerade yourself properly.

Now, I told you I was out of meds last week and you didn't even care to contact me you lazy fucker.

How many times do I have to express the emergency of the situation??????

The python click script you wrote for my pheromone revenue stream web site suddenly stopped to work!!!!!!

You fucking incompetent python script writer!!!

When it works, I get 4000+ clicks a day on my pheromone revenue stream web site but only 5 or 6 without it!!!!

Now, it seems like you dont care and that you have abandoned me you heartless fucking pig!

Bonus:
Here is a story that creimer told me when convincing me what a hard life he had:

The tree was him and the tree knot was his butt hole!

So, his uncle packed his fat ass with lard and with his cock! Not that it makes much of a difference but anyway, there it is!

Signed:
The girl that used to love you and now hates you, burn in hell where you belong you sexist pig!

It's Google's world...

[Anonymous Coward]

we just live in it.

Can't wait for these dicks to fall. Of course then another dick will take their place, but a period of a few years respite between monopolists is nice.

Re:Wondering Why Your Internal .dev Web App Has St

[Anonymous Coward]

I've always used a reserved TLD; I probably should have put more thought into the why, but way back when that's what I was told starting my first job and it became habit so I hadn't thought about it again until now...

Whats the alternative?

[Zaiff Urgulbunger]

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 diagnose a problem. Plus, really, I don't need it.

I could go with using my own domain name, but I'd prefer not to because, frankly, I really like having a shorter domain name for testing with! (zaiffurgulbungerenterprisesinternational.com is a bit too long!!)

Re:Whats the alternative?

[Kenja]

The alternative is Firefox. Seems Google doesn't want us using their browser anymore, and who am I to argue with them.

Re:Whats the alternative?

[Junta]

.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:Whats the alternative?

[viperidaenz]

Google own Chrome
Google own .dev

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

Re:Whats the alternative?

[viperidaenz]

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.

Re:Whats the alternative?

[Junta]

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:Whats the alternative?

[Albanach]

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.

Re:Whats the alternative?

[viperidaenz]

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...
What if the ownership of one of the 40,000 entries in that list changes?

Re:Whats the alternative?

[WaffleMonster]

Google own Chrome
Google own .dev

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

They own .dev in the global Internet DNS system ONLY.

They do not own .dev in all namespaces across every network on planet earth.

The assumption all names are global DNS names is simply not correct.

Re:Whats the alternative?

[Anonymous Coward]

Use "dev.yourdomain.local" or "test.yourdomain.local"

I don't see them changing the .local away from local use...

Re:Whats the alternative?

[Anonymous Coward]

How about zaiff.thishereismytldgoogleyoucangofuck

Re:Whats the alternative?

[viperidaenz]

gTLD's shouldn't be used in private networks

The assumption should be you don't control any names you don't own.

Every place I've worked uses their own domain for their intranet.
The last thing you want is for a client to have their DNS servers incorrectly configured, or to be used outside the intranet and have intranet requests be made to random internet servers.

If an employee is working from home and their VPN isn't connected, where does the HTTP request end up when the domain name is resolved by their ISP's DNS server? If you used your own domain for your intranet, it goes nowhere, as the DNS lookup fails because your intranet host names aren't in public DNS servers.

If it's some random TLD, it goes to some random IP address.

Don't be stupid, never use a domain you don't own for internal purposes, unless it's in RFC2606.

So, what is a .dev web app?

[Anonymous Coward]

Don't call it a web app, call it what it is - a web server.

A better headline/summary would be that chrome is going to require any web server domain name that ends in .dev to use https, which means it won't work unless there is a valid certificate on the web server that is trusted by the browser.

It's retarded and bad security

[Anonymous Coward]

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. For a while the user could override this stupidity, recognizing that the map data doesn't need to be secure, and go about his business. Now the stupid fucking browsers won't even allow you to override this.

This is why we can't have nice things, stupid fucking people and the companies that have gotten rich off of them.

Re:It's retarded and bad security

[ranton]

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.

Re:It's retarded and bad security

[tepples]

We have a product that embeds MapQuest. But MapQuest doesn't allow HTTPS

If MapQuest refuses to offer a means to authenticate that data actually came from MapQuest, then don't embed MapQuest in your product. Instead of embedding MapQuest in your product, embed a competitor to MapQuest in your product. What does OpenStreetMap or Google Maps fail to provide?

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Wondering Why Your Internal .dev Web App Has St

[WaffleMonster]

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 why we stayed with IE6 for so long

[Anonymous Coward]

It was bad, but it was a known bad and there are still deployments out there. Windows XP still has 5% market share because people don't want breaking updates. With Chrome stuck at 49 and Firefox 52 on XP we can write web apps and not worry about having to update them. It is the 2010s COBOL. Chrome is for Drones, XP IE 6 is for developers with long term job security.

Do no evil

[Virtucon]

Yeah, right.

Fuck Google, Fuck Chrome, Fuck Walled Garden nonsense.

Re:Do no evil

[viperidaenz]

They aren't being evil

They manage the .dev gTLD and one of the rules for using a .dev domain is HSTS

Re:Do no evil

[Virtucon]

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:Do no evil

[viperidaenz]

Perhaps someone should have thought to put it in RFC2606, like they did with .test, .example, .invalid and .localhost

Re: Do no evil

[Anonymous Coward]

The RFC process has never been perfect but give it 10 yrs and Google will want to control that too.

Re:Do no evil

[Anonymous Coward]

Bullocks. They enforced this policy through their industry position, nothing more.

Hard HSTS "pinning" within the browser, is a nightmare waiting to happen. Any badguy(tm) who can MITM you, can also strip HSTS -- EXCEPT on their preloaded list : https://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json/

It's almost as bad as the current list of DEFAULT CA's. Why in the hell should I trust Hongkong Post when I'm neither employed by them, nor even IN HONGKONG.

Wondering why?

[viperidaenz]

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.

Re:Wondering why?

[Anonymous Coward]

I own a computer not connected to the public internet. I own all domains on that, fuck you very much.

Re:Wondering why?

[Anonymous Coward]

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.

Because no one could possibly have been using this before it became a gTLD during the internet version of a land grab, right?

Re:Wondering why?

[Anonymous Coward]

I own a computer not connected to the public internet. I own all domains on that, fuck you very much.

Yes, of course you do. But naturally, that means asserting that right by using your own fork of (say) Chromium, which then handles all domains in the way *you* want, rather than using a commercial, Internet oriented browser such as Chrome, which handles domains in the way google thinks is appropriate for the public internet.
If you can't be bothered to do this, then you have to live with Google's choices.

code wranglers

[Hognoxious]

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

Re:code wranglers

[frank_adrian314159]

It's one of the hipster names for programmer. Please keep up. Git along li'l bits.

Re:code wranglers

[jrumney]

What in the name of Gordon H. Bennett is a sodding code wrangler?

Ask your cow-orkers.

Re:code wranglers

[Hognoxious]

Kudus, I see what you did there.

code wranglers?

[Anonymous Coward]

I love that people now have so little control over their software that they are referring to them selves as wrangles and not programmers. Cut, paste and pray.

Fuck Google

[Anonymous Coward]

This is ridiculous and a huge overstep to actually force non-existent tlds to use https. It makes debugging more difficult because all the traffic is now encrypted. I havenâ(TM)t used Chrome in years and Iâ(TM)m gonna keep it that way.

Fuck off, Google. Fuck off.

How To

[Anonymous Coward]

Okay folkx, so lets get to the grit and get this issue fixed shall we?

Now I don't know about apache servers because I live in the age of cars not buggy whips so I'll just skip past the jurassic period of web development and concentrate on modern day nodejs servers.

First off, get your SSL certificate
1) Open your console (linux, if your doing web anything on microsoft or mac well I can't fix stupid)
2) sudo add-apt-repository ppa:certbot/certbot;sudo apt-get update;sudo apt-get install certbot
3) certbot certonly --standalone -d example.com (note this will not work for localhost addresses, but we will get to that)

Next set up your server
Create your index.js file under /var/www/node
index.js contents -> https://codeshare.io/5NZEyV /* I tried to just paste the code but slashdots comment system said it was junk, apparently this was because of ascii penii art being pasted too often */

Now start up your server
cd /var/www/node;sudo forever start -o log.txt -e err.txt index.js

Next set up your browser

1)If you visit the site normally you will find that it will respond perfectly from example.com, so nothing need be done for this
2)When visiting on localhost or local_ip you will find that the cert doesn't cover these addresses so you must set your browser to 'REMEMBER HISTORY'
goto your site, accept the certificate even though it doesn't quite fit, after this you can reset your browser to properly never remember history but it will remember this entry so long as you do not clear your history

DONE!

P.S. For a site devoted to nerds you guys bitch a lot but don't code a lot, wtf people?

"Use a proxy." explained

[tepples]

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:"Use a proxy." explained

[hierofalcon]

Well of course you could do that, but that still doesn't prevent any man in the middle attacks between the actual switch and the proxy. If you're on an isolated network, it might not matter so much. If you're managing remote equipment, it might.

Anyway - only meant to be a reason why the deploy https everywhere and break anything that tries to present a cert we don't like (even if created in-house and the in-house root is marked as trusted) can be problematic. I don't care if I get warned, but if I've identified the cert I should be able to mark it as trusted. That is getting harder and harder to do.

Should HP fix it? Of course. There should be a method where you can just install your own existing cert instead of going through a CSR process just for these situations. How many people are left at HP who could fix it is an exercise left to the people in charge at HP.

Re: "Use a proxy." explained

[Zero__Kelvin]

The proxy sits on your local net and interfaces to the public infrastructure, so MITM is a non-issue, besides you certainly weren't protected from that at all before so it's wired to be bringing it up as a possible drawback now.

Re: "Use a proxy." explained

[Zero__Kelvin]

That's correct.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Wondering Why Your Internal .dev Web App Has St

[evileeyore]

that tld was registered in 2014 https://icannwiki.org/.dev my guess is well over 95% of developers posting gripes in here have infrastructure dating back far further thant 2014.... I personally have been using a .dev locahost enviornment on my dev box for a long ass time.

Re:Wondering Why Your Internal .dev Web App Has St

[edtice1559]

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.

Re:Wondering Why Your Internal .dev Web App Has St

[edtice1559]

And you were warned in 1999 not to use .dev, but to use one of the TLDs reserved for this purpose.

Re:Wondering Why Your Internal .dev Web App Has St

[Anonymous Coward]

There are four of them, FWIW:

.example, .invalid, .localhost, and .test

Only one isn't a mouthful...

Secure Contexts bans some JS APIs in clear HTTP

[tepples]

What has HTTP/HTTPS to do with HTML?

The Secure Contexts spec, currently a W3C Candidate Recommendation, deprecates use of some web platform features over cleartext HTTP. Attempting to use certain methods in a document served over cleartext HTTP will instead produce a SecurityException.

Be your own root zone and root CA

[tepples]

With http I all I need is an IP address or at least a TCP port on a shared address. With HTTPs I need a DNS name and a certificate.

If you have administrative access on all machines on a private network, you can mint your own DNS names and your own certificates because you are the root zone and you are the root certificate authority. What you say is true of bring your own device (BYOD) scenarios however.

Then install your root certificate

[tepples]

for fuck's sake let me trust a certificate I myself made.

Which version of Google Chrome doesn't allow certificates that chain to a user-defined root certificate that has been installed into the repository of TLS CA certificates on each client machine?

You've got to be kidding me

[Anonymous Coward]

If you think for one moment that HTTPS protects you from government spying, you might just be an imbecile. When your operating systems, servers and browsers are tailored by government agencies and businesses catering to those agencies[like Firefox, Chrome, Edge, Microsoft, Amazon, Google, App.. et al], you have only the reasonable expectation of the fallacy of privacy. In such a case, keep your DAMN hands off what I choose to do on my development networks.

Re:Wondering Why Your Internal .dev Web App Has St

[WaffleMonster]

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 in the real world out the gate. There is a bunch of tribal knowledge one must have to account for the difference between RFC and what is actually implemented in real world. It isn't ok to simply cite chapter and verse of text and blindly ignore reality. What is or is not written down in some document isn't an excuse. As I said before responsibility is bidirectional. The lack of ".dev" appearing in an RFCs that results in IANA reservations in the GTLD space does not excuse irresponsibility demonstrated in the act of assigning it.

Nor does Google have an excuse for mistaking the ".dev" Internet namespace they own with all namespaces everywhere.

Both instances of irresponsibility exist independent of judgments against individuals for using .dev.

Re:Wondering Why Your Internal .dev Web App Has St

[vux984]

Which TLD was reserved for that purpose?

localhost? no.
example? nope.
invalid? hell no.
test? maybe... but no... not really, if you actually read the RFC.

And "dev" isn't "test" anyway... hell many of us have BOTH.

Violation of trust

[Anonymous Coward]

Obviously we can't trust Google. This is Google interfering with OUR networks, and so, our data. We should never, ever use their browser. Don't let them dictate how you run your own internal network! This is just another instance of a company trying to interfere with our lives. They are getting away with it because the weak-minded and foolish think it is ok for big corporations to dictate to the people in general. It isn't. Even when they get away with it, as here.

If I want to use HTTPS on a website, I'll bloody well do it. If I don't, I won't. The web does not belong to Google. The web belongs to everyone. HTTP is a perfectly good protocol for many purposes.

Today I removed Chrome from my computer. I already have a mother. I don't need another one.

So,

[BitztreamNotARealNam]

How's life in the hypocrite lane?

Re:Wondering Why Your Internal .dev Web App Has St

[edtice1559]

You can have .dev.test and .test.test! Or you can use a TLD that you own!

Just more proof that we are "monkeys ...".

[martinfb]

Just more proof that we are "monkeys with a machine gun" idiots!

Technology is being allowed to be given to entities that do not the proper use.
And, this is further proof that this internet thing needs to be regulated as a PUBLIC UTILITY which, ultimately, means that NET NEUTRALITY is a MUST.

Score:-5, Pwned

[Anonymous Coward]

Witness BitZtream getting pwned!... twice.....three times!