Google Chrome will begin to mark all HTTP sites as "not secure" starting in July 2018. This is just a warning displayed in the URL bar and won't stop users from loading the pages:
For the past several years, we've moved toward a more secure web by strongly advocating that sites adopt HTTPS encryption. And within the last year, we've also helped users understand that HTTP sites are not secure by gradually marking a larger subset of HTTP pages as "not secure". Beginning in July 2018 with the release of Chrome 68, Chrome will mark all HTTP sites as "not secure".
Also at TechCrunch and The Verge.
This discussion has been archived.
No new comments can be posted.
Google Chrome Will Mark Non-HTTPS Sites as "Not Secure" Starting in July 2018
|
Log In/Create an Account
| Top
| 45 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
(1)
(Score: 4, Insightful) by bob_super on Friday February 09 2018, @06:47PM (26 children)
Categories of people:
- Those who won't notice the warning
- Those who don't care, or don't know what to do about the warning
- Those who will panic needlessly
- Those who know, but can't force the website to change, and may grumble and/or bitch on feedback forums, to people who don't have the time to fix a problem they DO already know exists.
- Those who understand that the whole internet, regardless of encryption, is "not secure"
So ... who are we helping, here ? Awareness is mostly good, I guess.
(Score: 5, Touché) by urza9814 on Friday February 09 2018, @07:20PM (1 child)
FTFY...I think you missed one :)
(Score: 2) by PiMuNu on Saturday February 10 2018, @04:19AM
Categories of people:
- Those who won't notice the warning
- Those who don't care, or don't know what to do about the warning
- Those who will panic needlessly
- Those who know, but can't force the website to change, and may grumble and/or bitch on feedback forums, to people who don't have the time to fix a problem they DO already know exists.
- Those who understand that the whole internet, regardless of encryption, is "not secure"
- Those who market web browsers and need another bullet point under "features"
- Those who need to tell their boss they are doing something to justify they are worth their salary and keep their department from being downsized
FTFFY
(Score: 4, Insightful) by requerdanos on Friday February 09 2018, @07:44PM (15 children)
Good question; probably not helping many...
Some data, it's important to spend the CPU cycles and bandwidth to make sure get encrypted on the way and decrypted at each end.
Some data, it doesn't much matter.
Even better, what data falls into which group varies by the person, group, and circumstance.
For me, my email, logins, etc. need to be encrypted. If I look up what a euro size 39 shoe would fit in a US shoe size, maybe not so important that it be encrypted.
For the people in a totalitarian country that oppresses shoemakers, it might be critical that it's encrypted (but it might not much matter if their local-language-to-russian dictionary chatter is encrypted because everyone in the country watches Russian TV and Russian isn't their first language).
(But in a neighboring country, the dictator is cracking down on Russian sympathizers...)
And from here, it gets worse... only a small (probably single digit if even that) percentage of the population is even capable of articulating this state of being (the knowing grumblers), much less worrying about it.
For everyone else, if there is a "WARNING: This page is not securE!!!," then much of that majority of the population good at what they are good at, but clueless at these nuances, will start thinking that it's not an intelligent decision where to deploy resources, but rather a black-and-white-good-and-bad "Secure pages are okay! Not Secure pages are evil! Danger! Like viruses and stuff!" (Your Panic People).
If such a warning led to awareness, that would be mostly good, but I think it's likely to do the opposite.
(Score: 3, Funny) by bob_super on Friday February 09 2018, @07:48PM (12 children)
> If I look up what a euro size 39 shoe would fit in a US shoe size, maybe not so important that it be encrypted.
Bad example. How many different Penis Enlargement ads are you going to need to block?
(Score: 2) by requerdanos on Friday February 09 2018, @08:07PM (1 child)
Thank you for pointing this out.
I don't know what people use shoes for that this would be a problem, but I block ads at the /etc/hosts level with blocklists + local whitelist.
This makes me forget what the general experience is, and has led me to cheerfully recommend sites to people in the past who came back and said "why did you recommend that site, it has porn all over it, which made it a little uncomfortable at the office?" ---- having never seen the site's ads.
Maybe looking up equivalencies for imperial and metric tools? Or transposing musical keys?
(Score: 2) by bob_super on Friday February 09 2018, @08:18PM
> I don't know what people use shoes for that this would be a problem
Your specific example was size 39, which for men means small ... feet.
(Score: 0) by Anonymous Coward on Friday February 09 2018, @08:08PM (9 children)
I need encryption because I don't want nosy hackers to know what kind of porn I like!!!!!!!!!!!
(Score: 2) by requerdanos on Saturday February 10 2018, @01:10AM (8 children)
I have bad news... Supervisory channel information is not within the encrypted envelope in https, so your request for https://certain.type.of.site/certain-type-of-content.php travels in the clear, unencrypted. Sure, nosy hackers can't read the page, which itself is sent to you encrypted, but they have its name and location, which is probably good enough. Google's love affair with https everywhere will not change that any.
(Score: 1, Insightful) by Anonymous Coward on Saturday February 10 2018, @02:28AM (7 children)
Ya sure about that? I remember reading on Wikipedia or something that for https, only the domain name (https://certain.type.of.site/) is visible to middlemen; the exact path and page (embarassing/subdir/certain-type-of-content.php?user=you) is transmitted inside of the encrypted request. I didn't look up and confirm this, but it makes a lot of sense. Transmitting the entire URL would be very problematic for both privacy and security, and a glaring flaw in the https protocol.
I expect someone will chime in if I'm wrong. After all, the best way to get correct answer on the Internet is to post the wrong one...
(Score: 2) by unauthorized on Saturday February 10 2018, @03:02PM (6 children)
What AC said. HTTPS fully wraps the HTTP protocol including the specific URL path, your ISP only knows that you've made a DNS request for "certain.type.of.site" and that you've been exchanging data with the IP address associated with it. You can obfuscate your DNS requests by using a third party resolver [wikipedia.org], in which case your ISP will only know that you've exchanged a certain amount of data with a certain IP address, which might allow them to infer the site you've been visiting depending on whether there is only one website or it's a virtual host for 50 different domain names.
(Score: 2) by requerdanos on Saturday February 10 2018, @05:47PM (3 children)
Thank you both for the correction. Cisco [cisco.com] [PDF] describes the process as follows:
So, certain.type.of.site is necessarily in the clear (until we get anoymous encrypted DNS), in making step 1 happen, but the sensivive/subdir/or-page.php doesn't get communicated until step 4, during which there is encrypted communication.
Well, no, you aren't asking for DNS for random.site.on.that.provider.net, you are asking specificically for DNS for certain.type.of.site, and until you get that, you have no way of knowing what other sites might be hosted at the same address.
This is true and helpful in many disciplines. For example, not sure how to say something in a foreign language you're learning? Just speak your best guess to a native speaker and they'll correct you immediately and cheerfully...
(Score: 2) by unauthorized on Saturday February 10 2018, @07:09PM (1 child)
You missed my point there. You can use a third party DNS provider and some of them do provide encrypted DNS, so your ISP doesn't directly have a way to know which hostname you requested. The DNS server owner will know your request, but your ISP will not. If you are really paranoid, you could also run your own DNS server, it's not that hard to set up one and nobody will ever know which hostnames you lookup because only you have the logs.
What your ISP knows is the IP address you connect to. They can easily acquire the list of domain names associated with that IP address from their own DNS database. However, they don't know which hostname you are using unless there is exactly one domain name associated with the target server, which is not often the case for smaller websites.
Well, there you have the correct answer. Enjoy.
(Score: 3, Informative) by urza9814 on Monday February 12 2018, @02:22PM
You're forgetting that SSL encryption can't begin until it has the hostname. Even if you're using encrypted DNS, if there's multiple secure servers on the same IP you'll likely end up using something like SNI [wikipedia.org], which sends the domain you're requesting to the server in the clear. Either way your ISP knows what site you're looking at.
The only way you'd get multiple hosts on the same server without needing to send an unencrypted hostname is if the server uses a master SSL key that is valid on all of the hosts it can possibly serve. Which you might get if that server is a Google load balancer, but then you're still just connecting to one target -- Google. If that server is hosting a thousand peoples' personal homepages, then either you're sending the domain names in the clear, or the hosting company just MITMed every single one of their customers (which is probably even worse in terms of security).
As far as I can tell, the only even *theoretical* way to defend against this would be to fake your first request -- send a request for Jim's homepage, then once the encrypted connection is up you alter the HTTP headers to request Frank's homepage instead. But there's two problems -- first, you have to already know about a "benign" hostname on the same IP, and secondly a lot of servers (Apache included) would apparently drop your connection as soon as you tried that. Maybe you could authorize a specific subdomain -- like sni.mydomain.com -- and you'd give the common webhost a key for *only* that subdomain? That way they can get the encryption up without needing SNI, and then they can redirect you to whichever domain you actually need. But I've never heard of that actually being done, and I can't find any other way to mitigate that particular threat. Plus that's still a form of MITM, it's just a bit more limited...but you've still gotta trust the host to redirect everyone to the right place and give up their access to that connection. At least until it became a standard that browsers understood and could try to defend.
(Score: 2) by urza9814 on Monday February 12 2018, @02:01PM
It's more complicated than that even.
DNS must be in the clear...unless it isn't. You can always set it up locally, it could be cached, it could be encrypted...there's a lot of ways around that, although you do have to actually put some effort into it.
But once you've got the DNS encrypted, and the page served over HTTPS...you've still gotta worry about stuff like SNI. Often you'll have more than one website at the same IP (small sites because they're renting shared servers; large sites because of shared cloud caching or load balancing.) And since HTTPS is tied to the domain, the server can't encrypt anything until it knows exactly which (sub-)domain you want. So even if you encrypt the DNS and encrypt the website, you still have to send the domain to the web server in the clear when you establish the connection. And I'm not aware of any technology that can mitigate that. In fact, some servers (like Apache) seem to be specifically designed to prevent attempts to hide that information (ie, you could theoretically request one site, then once encrypted change the HTTP header to request a different site...but Apache would apparently block that.)
Fully encrypted browsing is not even possible in theory.
(Score: 1, Informative) by Anonymous Coward on Saturday February 10 2018, @07:07PM (1 child)
except we all use dnscrypt, right?
(Score: 2) by urza9814 on Monday February 12 2018, @02:25PM
Doesn't help much. Even if you use DNSCrypt, your browser is sending the domain you want to connect to in the clear thanks to SNI. The technology to secure that has not yet been invented, although I imagine IPv6 might make it redundant if that ever gets fully deployed...
(Score: 4, Insightful) by c0lo on Saturday February 10 2018, @12:58AM
The tree of internet liberty must be constantly refreshed by all CPU-s bleeding cycles.
Otherwise the encrypted communications will be automatically tagged "of interest" by NSA.
A true libre internet is an internet where all the sites are in the .onion, .i2p or the like "TLD"-es.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 2) by Teckla on Saturday February 10 2018, @05:05PM
JavaScript injection is a real and pervasive problem; it would probably help a lot of people -- but they might not even know they're being helped.
(Score: 2, Insightful) by RedIsNotGreen on Friday February 09 2018, @08:23PM
Helping the big boys get a tighter grip.
(Score: 5, Informative) by frojack on Friday February 09 2018, @08:34PM (6 children)
The other thing this does is ENCOURAGES people to ignore this warning.
If a site collects no personal data (no forms to fill in), is non-commercial, and is simply someone's presentation of an area of interest, (fly fishing, botany, skiing, photography, what-ever), there really isn't one single reason to encrypt that page.
Its like the EU mandated warnings about cookies. What good does that pop-up do, other than teach people to click through it automatically? Mindless warnings about info only pages could backfire the same way.
No, you are mistaken. I've always had this sig.
(Score: 0) by Anonymous Coward on Friday February 09 2018, @09:29PM (1 child)
It prevents man-in-the-middle manipulation of the contents.
(Score: 2) by frojack on Friday February 09 2018, @09:35PM
Who gives a rip? Whats the worst that can happen, I tie a blue-drifter fly wrong? An ad slips in?
Besides, I have way less confidence in TLS that you do.
No, you are mistaken. I've always had this sig.
(Score: 3, Insightful) by c0lo on Saturday February 10 2018, @01:04AM (2 children)
But there is a reason: generate encrypted traffic so that any other needed encrypted communication is indistinguishable.
(go read Little brother [craphound.com])
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 2) by requerdanos on Saturday February 10 2018, @01:12AM (1 child)
Okay. There isn't a single intrinsic reason, then.
(Score: 2) by c0lo on Saturday February 10 2018, @01:39AM
True.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 4, Interesting) by TheRaven on Saturday February 10 2018, @12:51PM
How quickly people forget the Committee of Unamerica Activities. Fly-fishing, botany, skiing and photography all sound innocuous, but now imagine 20 years of shifting public perceptions. Fly fishing? Oh, so you're interested in torturing animals? Botany? So you grow drugs at home? Skiing? So you're complicit in damage to mountain regions? Photography? Are you a spy or a pervert?
Of course, most of this won't be filtered by a human, it will go into a big machine learning system, so no one will say 'we're not hiring you because you went to a fly-fishing web site', they'll say 'you were deemed to high risk by our totally objective machine learning system' and not mention that the training set was curated by a militant vegan.
sudo mod me up
(Score: 0) by Anonymous Coward on Friday February 09 2018, @09:06PM (5 children)
Upon encountering an HTTPS site, Mozilla browsers would turn the Address Bar yellow (not e.g. green), as if that was something odd.
On HTTP sites, that would stay the regular white.
So, completely backwards.
-- OriginalOwner_ [soylentnews.org]
(Score: 2, Disagree) by frojack on Friday February 09 2018, @09:37PM (4 children)
But Google's actions are way worse. You don't see the site. You get that "take me back to safety" page and have to drill down to find the I want to see it anyway link. A law suit waiting to happen if you ask me.
No, you are mistaken. I've always had this sig.
(Score: 2) by takyon on Friday February 09 2018, @10:28PM (2 children)
Isn't that what Firefox does with self-signed certs?
[SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
(Score: 2) by unauthorized on Saturday February 10 2018, @03:07PM (1 child)
Yes it does and it'd obnoxious as fuck, but at it's rare enough that it doesn't bug us all the time.
(Score: 2) by urza9814 on Monday February 12 2018, @02:50PM
It gives a warning if the cert is untrusted. Exactly as it should, and no different than it treats any other certs.
If you're got a large infrastructure with a lot of self-signed certs, set up your own internal CA and install it on your devices. If not, just manually install your one or two certs. Either way, if the cert changes, you get a warning instead of just being silently MITMed while still thinking you're still safe.
I'm a fan of marking plain HTTP yellow or even red in the URL bar, but not actually hiding the page contents. Give some kind of visual warning sufficient to make people (at least those who are marginally conscious) hesitant to actually input any personal information, without blocking the information entirely if it doesn't actually need to be secured. Not every webmaster can be trusted to actually set that stuff up properly. In fact, a lot of them are intentionally trying to do it wrong...
(Score: 3, Insightful) by c0lo on Saturday February 10 2018, @01:05AM
It is the bitter pill the civil society need to swallow to make the NSA job harder.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 0, Troll) by Anonymous Coward on Saturday February 10 2018, @12:24AM
Chrome should shut its whore mouth...
(Score: 2) by MichaelDavidCrawford on Saturday February 10 2018, @01:33AM (5 children)
I want my essays on mental illness to be accessible to readers who don't have https-capable browsers
I've seen them in libraries
Yes I Have No Bananas. [gofundme.com]
(Score: 2) by requerdanos on Saturday February 10 2018, @01:45AM
That sounds like a great reason not to require https (or other non-universal features).
Not so much a great reason not to even so much as provide https.
(Score: 2) by TheRaven on Saturday February 10 2018, @12:53PM
sudo mod me up
(Score: 0) by Anonymous Coward on Saturday February 10 2018, @07:33PM (2 children)
that sounds ridiculous. what is the reason someone would have a browser that doesn't support tls in 2018?
(Score: 2) by MichaelDavidCrawford on Sunday February 11 2018, @02:24AM
RLY.
In the case of a library they could hire an IT person or they could be open more frequently.
I'm also concerned about people in countries that don't permit encryption.
Yes I Have No Bananas. [gofundme.com]
(Score: 2) by MichaelDavidCrawford on Monday February 12 2018, @08:49PM
My Mom has that problem with her 2002 G4 iMac. Just about all the https sites she visit complain that the connection is insecure.
Yes I Have No Bananas. [gofundme.com]
(Score: 2, Insightful) by Anonymous Coward on Saturday February 10 2018, @03:13AM
So all Google's sites will be https websites which will eagerly and efficiently store, correlate, and otherwise mine all sorts of details about you when you visit them "securely."
Sorry, but I am usually more worried about what the damn website is doing than what some eavesdropper on the wire might see. Distract them, Google! Behold the spy lurking OVER THERE.
(Score: 2) by VLM on Saturday February 10 2018, @04:46PM (3 children)
My guess is its a coordinated attack against direct end user access via HTTP to "internet of other people's things". All hardware is supposed to home phone to big brother for monitoring and sale of personal data so you can access the giant internet portal until they decided you need to purchase new hardware to boost profits via arbitrary change to the portal.
With a side dish of something like the "license to read" which apparently google has memory holed because I can't find it. So NO MORE web development on raspberry pi you must buy a $1000/yr hosting license from a monitored professional provider to experiment with HTML.
(Score: 4, Informative) by requerdanos on Saturday February 10 2018, @09:48PM (1 child)
"The Right to Read" [wtdhpl.info] might be what you are looking for. If not, it's still pretty on-topic....
(Score: 2) by VLM on Monday February 12 2018, @02:23PM
Zactly yes.
Very depressing to get old, "when I was young" people made horrible fun of that and claimed RMS was insane for writing it, two decades later kids today are like "yeah thats Amazon and Microsofts business model isn't it the greatest".
(Score: 2) by urza9814 on Monday February 12 2018, @03:00PM
Last couple IOT-type devices I've set up have served the web interface over HTTPS with self-signed certs (which I then upgrade to real certs). So IME, most aren't dependent on or expecting a plain HTTP connection.
I suppose you could argue that some chips aren't powerful enough to support the encryption protocol...but that's basically saying that we need to let half cent processors have unrestricted access to the global Internet. Screw that, use a proper processor. If your device costs more than five bucks, it costs enough that they can afford to put in a CPU that can support encryption.