Google Will Soon Let You Know By Default When Websites Are Unencrypted (softpedia.com)
An anonymous reader writes: Permanent changes are planned for future Google Chrome releases, which will add a big shiny red cross in the URL bar if the website you're accessing is not using HTTPS. Google says it is planning to add this to Chrome by the end of 2016, after one of its developers proposed the idea back in December 2014. Many have argued that the web is predominantly unencrypted, so they're displaying a persistent and ambiguous error message for a large portion of the Internet. Since unencrypted content is not an error state, the Chrome team should use alternate iconography, because the default error message this will just confuse average people, and it will encourage error blindness.
HTTPs only encrypts the contents of what you are retrieving, not the location (URL) that you are retrieving it from. Seems rather pointless to push it everywhere. It only has a purpose when the user and/or server want to exchange secret payloads (e.g. credit card numbers).
Encryption would just slow me down with all that extra processing.
Don't "help".
That's great. Now, will Google let us know when it is tracking every thing we do online via its myriad of tracking technologies? Will it let us know when our email is going to be harvested for marketing data just because we sent an email to a non-google-appearing domain that was hosted on gmail? Will it let us know when and how it is logging our movements via android phones? Will it let us know what location data its "self driving cars" are going to be reporting back to google?
I thing the OP wanted the title to be "Google Chrome" Maybe one of the mods can fix that by at least replacing Google with Chrome.
Using that logic: The web is predominantly for porn. So we should label exceptions as SFW (Safe For Work).
Have gnu, will travel.
Good, finally some parity compared to the situation where a browser like FF would through huge error messages around self signed certificates but would absolutely not yell or scream about plain text sites.
You can't handle the truth.
We already suffer from error blindness;
"Since unencrypted content is not an error state" says who?
because to me it is. its not about the encryption, its about the verifiable accountability.
So we used to have a simple system, see http:/// on the URL bar, or see https:/// on the bar.
Then some idiot got the bright idea of hiding the start of the URL, so users could be ignorant or infuriated.
Now they are going to use another symbol to indicate the lack of an "s"?
Have I really got this right?
(Hopefully in the future the symbol will be clarified by replacing it with a sequence of letters.)
I can't see any problem with showing clear icons for the state of the connection, which includes unencrypted being distinguishable from encrypted with a cert signed by an untrusted party (aka self-signed) vs a cert signed by a trusted party.
It's better than the current state of things, where the web browser programmers out right mis-interpret what is going on and potentially lying to the user.
For example, if I run my own CA and sign all of my own certificates, and push my CA public key by hand to computers intended to access my server, verified by hash fingerprints - this is arguably MORE secure than a "secure" public CA signed certificate that I have no control over.
After all I know exactly who signs certs with my CA - me - and despite what the public CAs and web browser programmers claim, I in fact do trust myself.
CAs are known to have signed fraudulent certs, so they are not the ultimate high tier of trust.
Of course the self-signed situation described above is very different from random snakeoil.crt style self-signed certs where the only possible way to verify the servers identity is to check the thumbprint hash. And who has time for that?
Displaying the lowest tier of security icon for non-https sounds just as useful as it has been since SSL was invented.
(After all, a lock vs a lack of a lock works good enough for anyone that cares about encryption, but I could care less what the two icons actually are of)
At least Googles approach is better than Mozillas by an infinite amount! .html files locally in firefox :P
I'd rather use Chrome and at least have it bitch about the lack of SSL while still actually showing me the webpage.
Firefox will soon actively remove non-https support and display an "unknown protocol 'http'" error instead.
Hope you don't like browsing
https://blog.mozilla.org/secur...
Seems to me that this great push towards https everywhere could lead to an unwelcome endgame. Tried viewing youtube through a proxy doing an m-i-t-m interception? Seems you can't with chrome and certificate pinning. Of course that's by design, and exactly what you want, but it means Google now has end-to-end control of the media. No slipping an ad-blocking proxy in there or otherwise tampering with or examining their content.
Now it's heading towards "no https, no play". Next, only content signed by "trusted" CA's? Nice way to raise the barrier to entry for the web.
Seems like the internet could end up as a proprietary, closed content-delivery system, just like cable TV was.
Anon, because tinfoil hat.
Now I have to pay someone else to have a web site that will visible to the public.
... I don't even use cookies. Now big-ass Google is coming in and I need to pay someone else to have an encryption certificate.
... after three days I was not able to implement SSL on my server (help!?!). I suspect that implementation of SSL is one of those "if you know it - it's simple. If you don't - good luck".
My website is primarily static information (actually, it is only static information). I don't exchange any data (other than standard log files)
If things were bad enough, the last one I tried to implement
I'm forced to agree with this Slashdot poster. The use of a red X in this context will confuse users about perfectly correct and properly working websites, particularly legacy sites that carry no practical risks and contain widely referenced information, but that cannot be upgraded to SSL in a practical manner. The most likely outcome will be users learning to ignore such warnings completely because they will be so widely present and widely viewed as "crying wolf." It is also likely that many sites will push back against Google on this by posting explicit messages on their pages explaining to users that Google is playing Mommy and that nothing is wrong with their sites. It is perfectly acceptable and reasonable for Google to encourage the use of SSL. However, the approach being discussed is not helpful and is likely to even be counterproductive. REFERENCE: "When Google Thinks They're Your Mommy" - http://lauren.vortex.com/archi...
How about just showing the red bar if the HTML/javascript posts anything?
Forgive my ignorance but this is an honest question - am I missing something?
I run about 50 websites, some for myself and some for local non-profit organizations. They're all simple information/brochure websites with no real interaction or sensitive content. For the life of me I can't conceive of any reason to encrypt any of these websites, yet it's going to cost me a small fortune in certificates to keep them alive in the future.
Why would I need to encrypt a website that offers nothing more than, for example, a list of local historical sites to visit? Thanks for any insights.
They finally figured out nobody pays attention to anything unless you give it bright colors. It's amazing how little we have evolved (or perhaps devolved) since our early formative years. Of course when people see a big red "x" they tend to panic somewhat (as red often symbolizes danger). But because a site is not encrypted doesn't necessarily pose a danger. If there was sensitive data being sent unencrypted (or even a password field and unencrypted), okay, alert them. But to encourage ALL sites to encrypt regardless of purposes/data to avoid the big red "x" from google Chrome...seems a bit much. I'm enjoying the Vivaldi browser so I think I'll just keep using that. :D
"Imagination is more important than knowledge" - Einstein
So they are forcing identification of all website owners.
So my simple web server, serving up some basic info - like maybe my most recent cat photos.. Are you saying that I *must* use SSL to do this? And to make SSL work I have to pay to get a certificate (cuz I don't really trust the freebie options yet). All so that visitors to my site will *know* that they are looking at cat pictures securely? That doesn't really make too much sense, and seems to suggest a broad assumption about the main purpose of web sites. Not everything requires an encrypted channel. Won't someone think of the kitties? All this hype about safeguarding the Internet for the kids, and not enough to remember that kitties need love too.
Then do what on break-time?
Unless the feature is going to be added not only to Google Chrome but also to Google Search. The latter already uses HTTPS availability as a weak tiebreaker for ranking.
it actively tries to impress upon the user that the https connection with a self signed certificate is worse than a plain text http connection
A URL using the https: scheme and an unknown certificate authority gives a false sense of security, while a URL using the http: scheme gives a true sense of insecurity. Browser publishers rank truth of sense greater than security.
What's an acceptable level of "verifiable accountability" to you? I assume HTTPS with a self-signed certificate. Is a domain-validated certificate enough? Or do you demand an organization-validated certificate because of the risk of someone registering bankofarnerica.com and obtaining a domain-validated cert?
Next, only content signed by "trusted" CA's?
Let's Encrypt is a trusted certificate authority. And I don't see that going away any time soon, as the division of Google responsible for Chrome is a platinum sponsor of Let's Encrypt.
My Chrome browser recently started putting up an error page because python.org's certificate was a few days out of date. The error page has a big blue button marked "back to safety", the other button is a little harder to spot. It was mildly annoying since I was using the online docs while writing a script and the browser forgets your "fuck off" answer to the error between sessions. I'm sure there's an option somewhere that will automate my willful blindness to this error page, I'm just too lazy to look it up
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
Now I have to pay someone else to have a web site that will visible to the public.
You already have to pay your domain registrar and hosting provider.
Now big-ass Google is coming in and I need to pay someone else to have an encryption certificate.
But you don't have to pay StartSSL, WoSign, or Let's Encrypt for a TLS certificate.
I run about 50 websites, some for myself and some for local non-profit organizations. They're all simple information/brochure websites with no real interaction or sensitive content.
The "sensitive content" is what a man in the middle could insert into your stream: pornography, libel, ransomware downloads, or what have you.
yet it's going to cost me a small fortune in certificates to keep them alive in the future.
Let's Encrypt certificates cost zip.
Can adblock+ do 16 things hosts do 4 speed, security & reliability:
1.) Protect vs. bad sites (past ads)
2.) Protect vs. fastflux botnets + stop C&C talk
3.) Protect vs. dynamic dns botnets + stop C&C talk
4.) Protect vs. DGA botnets + stop C&C talk
5.) Protect vs. downed DNS (4 reliability)
6.) Protect vs. DNS redirect poisoning
7.) Protect vs. trackers
8.) Protect vs. spam
9.) Protect vs. phish
10.) Protect vs. caps
11.) Get past dns blocks
12.) Keep off dns request logs
13.) Speed up surfing (adblock & hardcoded favs)
14.) Works on anything webbound multiplatform.
15.) EZ data control
16.) Block ads better vs. addons more efficiently
* ANSWER ="NO" on ab+ doing it as well or @ ALL + hosts = on devices natively.
APK
P.S.=> Ab+ does less vs. hosts less efficiently - hosts do MORE w/ less + Hosts start w/ IP stack before REDUNDANT inefficient addons BEGIN operation (as 1st resolver).
---
Ab+'s a 128-151mb memory hog http://cdn.ghacks.net/wp-conte... (hosts use 3-11mb w/ my program initially). Even FireFox 41 adblock eats 65++mb http://www.ghacks.net/2015/06/...
---
ClarityRay defeats it seeing addons via native browser methods!
---
Ab+'s bribed not to work by default http://www.businessinsider.com... & ABP bought out adblock http://www.theregister.co.uk/2...
---
Ab+ adds complexity in slower usermode (w/ more messagepassing overhead + context switch vs. hosts in kernelmode).
---
AdBlock's SLOWER: http://superuser.com/questions...
---
What's best?
APK Hosts File Engine 9.0++ SR-4 32/64-bit http://start64.com/index.php?o...
MalwareBytes' hpHosts Admin (MalwareBytes employee who verified its source is safe http://forum.hosts-file.net/vi... ) hosts & recommends it http://hosts-file.net/?s=Downl... & MalwareBytes = BEST antivirus http://www.av-test.org/en/news...
&
It's safe per 57 antivirus programs in BOTH its 64-bit model https://www.virustotal.com/en/...
+
a 32-bit model too https://www.virustotal.com/en/...
& Installer -> http://f.virscan.org/APKHostsF...
Files need a type (assuming out of bandwidth necessity, a stretch itself given many modern types encode what they are in the beginning of the data itself e.g. jpg) but that should be in another data field of the OS rather than repurposing part of the name.
How would a portable program specify the content type of its output? The standard library of ISO C provides no way to manipulate "another data field of the OS". Nor does the standard library of ISO C++. Which well-known multi-platform programming language's standard library does?
So, uh, when is slashdot.org going to run over https?
Didn't anybody notice?
And even if you had money, you would have to renew certificate each year
Let's Encrypt automatically renews your certificate every couple months.
(for some reason these things expire)
They expire as a means of pruning the revocation list.
Can adblock+ do 16 things hosts do 4 speed, security & reliability:
1.) Protect vs. bad sites (past ads)
2.) Protect vs. fastflux botnets + stop C&C talk
3.) Protect vs. dynamic dns botnets + stop C&C talk
4.) Protect vs. DGA botnets + stop C&C talk
5.) Protect vs. downed DNS (4 reliability)
6.) Protect vs. DNS redirect poisoning
7.) Protect vs. trackers
8.) Protect vs. spam
9.) Protect vs. phish
10.) Protect vs. caps
11.) Get past dns blocks
12.) Keep off dns request logs
13.) Speed up surfing (adblock & hardcoded favs)
14.) Works on anything webbound multiplatform.
15.) EZ data control
16.) Block ads better vs. addons more efficiently
* ANSWER ="NO" on ab+ doing it as well or @ ALL + hosts = on devices natively.
APK
P.S.=> Ab+ does less vs. hosts less efficiently - hosts do MORE w/ less + Hosts start w/ IP stack before REDUNDANT inefficient addons BEGIN operation (as 1st resolver).
---
Ab+'s a 128-151mb memory hog http://cdn.ghacks.net/wp-conte... (hosts use 3-11mb w/ my program initially). Even FireFox 41 adblock eats 65++mb http://www.ghacks.net/2015/06/...
---
ClarityRay defeats it seeing addons via native browser methods!
---
Ab+'s bribed not to work by default http://www.businessinsider.com... & ABP bought out adblock http://www.theregister.co.uk/2...
---
Ab+ adds complexity in slower usermode (w/ more messagepassing overhead + context switch vs. hosts in kernelmode).
---
AdBlock's SLOWER: http://superuser.com/questions...
---
What's best?
APK Hosts File Engine 9.0++ SR-4 32/64-bit http://start64.com/index.php?o...
MalwareBytes' hpHosts Admin (MalwareBytes employee who verified its source is safe http://forum.hosts-file.net/vi... ) hosts & recommends it http://hosts-file.net/?s=Downl... & MalwareBytes = BEST antivirus http://www.av-test.org/en/news...
&
It's safe per 57 antivirus programs in BOTH its 64-bit model https://www.virustotal.com/en/...
+
a 32-bit model too https://www.virustotal.com/en/...
& Installer -> http://f.virscan.org/APKHostsF...
Other than that. I guess the other side of the argument to "why not use just use unencrypted HTTP?" is "if there is no cost involved and doesn't a lot of extra effort to set up, why NOT use encrypted HTTP?"
And the answer is that it does "a lot of extra effort to set up", at least according to Bomarc's comment.
If I only want to encrypt connection so it remained unmodified
A man in the middle can decrypt on one end and encrypt on the other end in order to modify the data. A self-signed certificate protects against only passive attacks, not active (man in the middle) attacks, unless you find some way to communicate the certificate's fingerprint out of band.
Easy solution. Allow self-signed certificates.
Then let me rephrase Anonymous Coward's post:
Use of a CA means your "list of local historical sites" remains exactly as you wrote it, and doesn't mysteriously lose mention of that awful thing which happened in 1846 that a local politician feels "school children just don't need to be taught" when it is viewed through a man-in-the-middle proxy on school WiFi. It also won't suddenly gain a banner advertisement for Amazon when viewed through the man-in-the-middle proxy of a certain US ISP. You presumably care about the "simple information" on your sites and want it presented as you wrote it, so that seems valuable, but without some means of detecting a man-in-the-middle proxy, there just isn't any guarantee at all.
Slashdot used to offer subscriptions. When it offered subscriptions, subscribers used HTTPS to view ad-free pages. HTTPS was treated as a subscriber perk because until September 2013, there were no major ad networks that worked over HTTPS.
First, allow me to decide how MUCH of the URL to show in the address bar when I'm finished typing
ie: allow me to type cnn and hit return, knowing that it will resolve to http://www.cnn.com/ and allow me to decide whether I just want that displayed as www.cnn.com or as the full http://www.cnn.com/
Second, allow me to decide whether my browser should be even allowed to display non-https content. Because frankly, if you aren't using HTTPS on your site for EVERYTHING, you are doing your users a dis-service, period. I do currently use HTTP sites, but if this was the default behavior for all browsers, we would quickly see the entire internet switch over to HTTPS and I personally see this as a good thing.
Third, warn me and allow me to decide what level of SSL I want to support (I will always pick to ONLY support the most advanced currently unbroken SSL level). Again, if your site isn't using TLS 1.2 then I'm not going to be using your site.
Why is this so fucking difficult? I devised these rules in 5 minutes. Come on Google, get your Chrome team ahead of the curve.
So they are forcing identification of all website owners.
Whois already does that, thank you very much. And Let's Encrypt doesn't need any more information than what's already on your domain's Whois record before issuing a domain-validated certificate.
Firefox defines typing in s as indicating that the user desires protection from a man in the middle (MITM). Install the Perspectives extension, which adds a second method of detecting MITM that works with self-signed certificates, and self-signed certificate errors will go away.
Especially because SlashdotMedia just got bought out by BIZX, and some people think this is dangerous.
You can always come to SoylentNews. It has HTTPS, and we won't bite.
I would argue that in our new we are recording you world, unencrypted content IS an error state. Just like not wearing your seatbelt is an error state now. In the old days, it wasn't. And when those "BEEP BEEP WEAR YOUR BELT" signs came along, they were greeted with similar "useless warning" arguments. In fact, it was NOT a useless warning, and now everyone mostly wears their belts. Some day, all data will be encrypted, and it will seem just as dumb not to encrypt as it is not to wear a sealt belt in a car.
This hopefully will encourage more sites *cough*slashdot*cough* to enable HTTPS connections, and make them the default for all traffic. The more the internet is encrypted, the better. Keeps the spooks busy and hopefully in the dark (or at least wasting a lot of resources decrypting mundane traffic.)
On install or setup ask if they would prefer SSL only results/sites and inform them after the fact they elected for the option if they want to proceed to an unecrypted site. Kind of the same thing with sites that have certificate errors.
As others have said the warning thing will just add a layer of complexity that users ultimately won't understand.
Cacheable pages might have ads, but they're not The Right ads.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Most secure sites should run on a dedicated server, not be shared with other domains websites on the same server, since it is a security issue.
Because of IPv4 address exhaustion, multiple dedicated servers would have to sit behind a load balancer with one IPv4 address that terminates the TLS connection.
But you could also use a unique IP address for each site hosted on the same server..... IP virtual hosting
This became impractical as of IPv4 address exhaustion.
Internet Explorer on Windows XP does not
...receive security updates anymore. It hasn't for 21 months. Therefore, it should be assumed subject to compromise by things such as keyloggers and therefore insecure.
An upgrade from my present cellular plan to one allowing tethering would cost roughly $50 per month, or $600 per year. At 2000 hours per year (full-time) and 25 percent income tax, this would reduce my effective hourly wage by 40 cents per hour. At 1000 hours per year (part-time) and 25 percent income tax, this would reduce my effective hourly wage by 80 cents per hour. But if an employer provides unrestricted break-time Internet, I don't have to pay $600 per year to a cellular company, and the employer can keep me as an employee without having to give me such a raise.
While it's true that https makes it harder to MITM the guy's blog or whatever, in my 15 years of full-time web security work, I haven't seen too many problems with MITM.
What I've seen a LOT more of, at least 200 times more, is hacked sites. Some Wordpress vulnerability or whatever and the bad guys ad malware to the public pages, while hosting phishing related pages in hidden directories.
A security- conscious company, head of household, or even ISP can largely protect users against malware that's been added to sites by detecting it at the firewall, as it enters the network. Unless of course it's https, in which case you can't detect the content at all. (Unless you do your own MITM, which often turns out badly).
So while https on a content site, a site that doesn't handle secure transactions, can theoretically reduce the risk of something that rarely happens anyway, it makes it much harder to protect against the far more common threat.
Overall, turning on the light and seeing what's flowing through your network is often safer than operating in the dark. In the dark you may -feel- like noone can see you, but in fact you can't see what's going on either. Often, what's hiding in the dark is more dangerous than being visible in the light.
That's just may experience, my fifteen years with the 70,000 or so client web sites I have data for.
The firewall can detect the hostname through the Server Name Indication field of the ClientHello packet, which is sent in the clear. If the hostname is known to have been infected, it can block the connection. It cannot detect the URL with path granularity, but if a site has been compromised, all paths on that site are probably shot as well.
So while https on a content site, a site that doesn't handle secure transactions
The Firesheep extension demonstrated that any site into which a user can enter a name and password, such as to post to the site's comment section or to read private messages or paywalled documents, is a site that "handle[s] secure transactions".
While it's true that https makes it harder to MITM the guy's blog or whatever, in my 15 years of full-time web security work, I haven't seen too many problems with MITM.
What I've seen a LOT more of is hacked sites. Some Wordpress vulnerability or whatever and the bad guys add malware to the public pages, while hosting phishing related pages in hidden directories. 99.9% of malware on sites is actually added to the site, not MITM by a rogue ISP or whatever. (And if you're buying internet service from a rogue ISP that alters web pages, you need a new ISP, not a red X).
A security-conscious company, head of household, or even ISP can largely protect users against malware that's been added to sites by detecting it at the firewall, as it enters the network. Unless of course it's https, in which case you can't detect the content at all. (Unless you do your own MITM, which often turns out badly).
So while https on a content site, a site that doesn't handle secure transactions, can theoretically reduce the risk of something that rarely happens anyway, it makes it much harder to protect against the FAR more common threat.
That's just my experience, my fifteen years with the 70,000 or so client web sites I have data for.
You know, LiKe iT UsEd To Be!!!! (I werent allowed to use all caps for the desired effect since acording to /. its like yelling. I kNoW! ThAtS WhY I DiD iT!
This is actually bad security. It is similar to the Vista UAC debacle. Vista taught a generation of users that they don't need to read security pop ups. By having them pop up way too often and without consequences if you don't read them for most of the time. Even if the user had read them, they wouldn't understand.
The user is the most important part of security, period. Thus teaching the user is more important than anything else, when you want to mitigate risk.
Google is making the web a lot unsafer with this.
Goodbye Slashdot, nice knowing ya!
Google Chrome will make Slashdot, and all other non-HTTPS websites, obsolete in 2016.
What's the point?
Once this feature gets implemented, by default any website will be considered insecure unless it uses proper HTTPS connection and the certificate is valid.
Then it would be just a matter of coherence to completely remove the warning when accessing an HTTPS website with an incorrect/untrusted certificate. I have never understood this warning and the extreme reaction from browsers in this use case.
A shade/brightness of red depending on scripts and input fields on the page.
rewriting history since 2109
"Principle: It is just important to be visually inconsistent when things act differently as it is to be visually consistent when things act the same
Make objects that act differently look different. For example, a trash can is an object into which a user may place trash and later pull it back out. If you want to skip the “and pull it back out” functionality, that’s fine. Just make it look like an incinerator or shredder or anything other than a trash can.
Make pages that have changed look changed. If someone encounters an unfamiliar page on an updated website or in a revised app, they know to look around and figure out what’s different. In the absence of such a cue, they will attempt to use the page exactly as they have always done, and it won’t work."
From http://asktog.com/atc/principles-of-interaction-design/
Completely unnecessary. Many sites that only have plain-text, non-sensitive information will have a big "X" on them, scaring off unaware users. Google is forcing admins to get SSL certs for no reason
I know it goes against all /. rules, but I went and read the original article. At the end there is an update saying,
"UPDATE: We were contacted by Peter Kasting, one of Google's engineers in the Chromium project, who told us we're idiots. But at least we're not the only ones. As Mr. Kasting's puts it: "In other words, there's no story here, unless the story is 'by the way, a year ago the Chrome team added a flag to do this and we just wanted to let you know that the flag still happens to exist'." So there's no permanent to Chrome coming by the end of 2016. We're sorry, but most of today's stories break via Twitter. Sometimes you get nice teasers, sometimes you get developers talking about their wishes and desires, instead of actual implementations."
So this is a non-story.
I'm hoping this get voted down sufficiently, so the tinfoil hat brigade and continue to lament about Google breaking the interwebs.