Slashdot Mirror
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.
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?
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).
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.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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.
Don't use spyware posing as a web browser.
We will bankrupt ourselves in the vain search for absolute security. -- Dwight D. Eisenhower
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.
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.
Support my political activism on Patreon.
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.
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...
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.
I prefer to use .local for my internal network. Problem solved.
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.
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.
Wut. I mean... wut?! "My cert is a cookie"?! Care to explain how that works?
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.
Average Intelligence is a Scary Thing
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?
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
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...
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.
Okay... I understand using
Is using .test a drop in replacement? Basically I'd like something that can't accidentally leak requests on the Internet. And I *DO NOT* want to use HTTPS/certs internally for development because it's a pain in situations where I'd currently resort to Wireshark to 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!!)
Yeah, I gotta say, I support Network Neutrality not Network Doitmyway.
Not everything benefits from HTTPS, some things benefit from caching and broadcast distribution!
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.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Someone should invent proxies.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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.
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!
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.
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.
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?
Comment removed based on user account deletion
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...
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.
What has HTTP/HTTPS to do with HTML?
"HT"?
Says the AC who has no credibility to trade on.
First, a network email scanner would be on the mail server itself, looking out for suspicious links. The suspicious link scanner can easily visit websites to make sure they're safe for the reader, especially if it's a site that's not previously indexed by Google.
If you use a corporate computer (especially one for a large company), there'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.
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.
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?
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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.
CLI paste? paste.pr0.tips!
Yeah, right.
Fuck Google, Fuck Chrome, Fuck Walled Garden nonsense.
Harrison's Postulate - "For every action there is an equal and opposite criticism"
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.
You can use whatever network technology you want, just not on Chrome...
So go find another platform and gtfo
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.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Don't forget all the commercial tools that allow enterprises to snoop on traffic using TLS, e.g., WebSense
Harrison's Postulate - "For every action there is an equal and opposite criticism"
That is the weakest troll I have seen in a long time, unless you believe that, in which case you are an idiot.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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.
CLI paste? paste.pr0.tips!
Web proxies that MITM TLS connections are way worse than proxies that outright refuse to do HTTPS.
(That said, this is about mail.)
CLI paste? paste.pr0.tips!
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.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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
CLI paste? paste.pr0.tips!
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.
Support my political activism on Patreon.
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.
Support my political activism on Patreon.
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)
CLI paste? paste.pr0.tips!
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.
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.
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.
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.
OK, I'll bite. What in the name of Gordon H. Bennett is a sodding code wrangler?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
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.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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.
This has literally nothing to do with Network Neutrality, *except* that HTTPS makes violating it more difficult.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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.
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?
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.
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.
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.
Well the subject was corporate network so a MITM proxy is usually the norm anyway.
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).
Support my political activism on Patreon.
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?
Comment removed based on user account deletion
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.
Someone had to do it.
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.
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).
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.
And you were warned in 1999 not to use .dev, but to use one of the TLDs reserved for this purpose.
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.
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.
There are four of them, FWIW:
.example, .invalid, .localhost, and .test
Only one isn't a mouthful...
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.
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.
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.
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?
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?
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.
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).
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
If you control the cache, you can use it to cache https.
Support my political activism on Patreon.
Established at connection time = different for each connection = not persistent = not a viable method of tracking. Follow?
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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?
There's nothing stopping your browser from establishing a new connection/session for each request. Follow?
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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.
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.
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?
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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.
FFS, just google it or click this link: https://en.wikipedia.org/wiki/...
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.
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.
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?
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.
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.
//TODO: Think of witty sig statement
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.
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.
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.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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.
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.
Except where it's not their right :-P
(Probably would not stop them anyways)
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.
How's life in the hypocrite lane?
That's a valid point, but that's rather different from "the cert being the cookie".
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.
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.
Wannabe nerd.
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.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
You can have .dev.test and .test.test! Or you can use a TLD that you own!
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.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Autocorrect... END == DNS
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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.
Support my political activism on Patreon.
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.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
You care to link to a standards document that backs you up?
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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.
CLI paste? paste.pr0.tips!
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.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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.
Self-importance and self-indulgence is the root of ALL evil.
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.
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.
No it wouldn't because your corporate CA would be installed as a trusted CA.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Witness BitZtream getting pwned!... twice.....three times!
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.
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.
I didn't say, "this has to do with network neutrality." Try reading it again backwards.
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.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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!
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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?
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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.
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 ...
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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.
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.