Google Chrome To No Longer Show Secure Website Indicators (bleepingcomputer.com) 68
Google Chrome will no longer show whether a site you are visiting is secure and only show when you visit an insecure website. Bleeping Computer reports: To further push web developers into only using HTTPS on their sites, Google introduced the protocol as a ranking factor. Those not hosting a secure site got a potentially minor hit in their Google search results rankings. It has appeared to have worked as according to the 'HTTPS encryption on the web' of Google's Transparency Report, over 90% of all browser connections in Google Chrome currently use an HTTPS connection.
Currently, when you visit a secure site, Google Chrome will display a little locked icon indicating that your communication with the site is encrypted, as shown below. As most website communication is now secure, Google is testing a new feature that removes the lock icon for secure sites. This feature is available to test in Chrome 93 Beta, and Chrome 94 Canary builds by enabling the 'Omnibox Updated connection security indicators' flag. With this feature enabled, Google Chrome will only display security indicators when the site is not secure. For businesses who wish to have continued HTTPS security indicators, Google has added an enterprise policy for Chrome 93 named 'LockIconInAddressBarEnabled' that can be used to enable the lock icon again on the address bar.
Currently, when you visit a secure site, Google Chrome will display a little locked icon indicating that your communication with the site is encrypted, as shown below. As most website communication is now secure, Google is testing a new feature that removes the lock icon for secure sites. This feature is available to test in Chrome 93 Beta, and Chrome 94 Canary builds by enabling the 'Omnibox Updated connection security indicators' flag. With this feature enabled, Google Chrome will only display security indicators when the site is not secure. For businesses who wish to have continued HTTPS security indicators, Google has added an enterprise policy for Chrome 93 named 'LockIconInAddressBarEnabled' that can be used to enable the lock icon again on the address bar.
Re:That's cool, but what about blue checkmarks? (Score:4, Funny)
As soon as they can find literally any sites on the Internet that aren't, for comparison.
Re: (Score:2)
This is the consequence of forcing HTTPS everywhere, now no site can be trusted.
That is really stupid (Score:5, Insightful)
Not that most people even look in regular circumstances, but what if people get warned to be careful in some environments? Then most cannot.
Anyways, using a "mainstream" browser like Chrome is probably a pretty bad idea.
Re: (Score:3)
Personally, I only use browsers that I've written myself.
Re: (Score:2)
I use knockoff browsers not done by companies with a security team larger than some countries.
Re:That is really stupid (Score:5, Insightful)
No, the always-on indicator serves no purpose. Just have an indicator that shows up when something is wrong. That's why cars have a "check engine" light, but not "engine does not need to be checked" light.
Re:That is really stupid (Score:5, Interesting)
But a 'check engine light' is lit when the engine is started to show that it functions.
If you never show a symbol/light if everything is ok, then how does the user know that it is working properly? Maybe it is not working properly and not being tripped or lit.
Re:That is really stupid (Score:5, Interesting)
The problem is, somewhat interestingly, similar to the "check engine" light: It lies (sort of). The light goes on even when it's time for a scheduled oil change and nothing is wrong with the engine at all. As a result there's a risk some people who know this will ignore it, when there is actually something seriously wrong with their car.
The lock icon has a similar problem: some people are under the idea that it means the website is safe. This is not true. It just means nobody can snoop on your communications with the server, it says nothing about the trustworthiness of the server itself. And anyone can get that lock on their site for free. So it makes sense Google would want to do something to combat this dangerous belief.
Re: (Score:3, Informative)
Did you really need https to read a newspaper?
Yes.
Do you need https to read comics?
And, yes.
The downsides of using plain http in these situations is really much worse than the energy bill for it.
Re: (Score:3)
The check engine light is lit when the car is turned on to make sure the bulb isn't dead. Bulbs used to die regularly before LEDs and now digital dashboards.
In the case of Chrome there is a really good system for warning the user. Normal HTTP pages show a broken lock. If the user starts entering any data into a form on a non-secure page an animated red warning message appears. If they try to submit the form a pop-up explains the issue and asks them to confirm.
Re: (Score:2)
The problem with this is that most users will not understand that they are now outside of a secure workflow. They will just think "something is broken, let's try anyways". An "everything is ok" indicator is much better for non-experts, because it being missing signals a clear "stop".
Re: (Score:2)
But a 'check engine light' is lit when the engine is started to show that it functions.
I don't need to replace the indicator on my browser graphic. Users of cars and computers put a lot of faith into the fact that things work. We provide verification for the few cases where an inexplicable hardware error such as a blown lightbulb can cause a function to fail on demand.
Re: (Score:2)
Telltales are moving to icons on screens in cars, except for a handful controlled by regulation, which includes the engine light and airbag.
Re:That is really stupid (Score:4, Interesting)
No, the always-on indicator serves no purpose. Just have an indicator that shows up when something is wrong. That's why cars have a "check engine" light, but not "engine does not need to be checked" light.
Not long ago, I was here discussing with others who were defending the ongoing value of FTP as browsers look to depreciate support for that insecure protocol. And now, we are going to flag any and all websites running HTTP, as "something is wrong"? HTTP is still a perfectly functioning protocol, as is FTP. The main difference is FTP is utilized far more to serve up specific files and content that would likely hold a higher need for privacy, integrity, and security.
A website that does not dabble in authentication or collecting personal information and merely exists to serve public information, doesn't need HTTPS to function. Perhaps we re-think the wrongthink?
And if it's privacy you wish, anyone have any evidence that a subpoena from your ISP has now become worthless, because HTTPS-everywhere? If that were the case, why is anyone pissing money away on a personal VPN proxy? HTTPS made you invisible and secure.
Re: (Score:2)
ISPs are intercepting HTTP and changing the content.
This is why their is the big push to HTTPS.
Re: (Score:2)
always-on indicator serves no purpose
It has one purpose, right click to enable javasctipt when "no" is your default. Gonna be a right pain in the ass doing it through settings or find the keyvalue again when they change that too.
Re:That is really stupid (Score:4)
I disagree. Your car analogy is flawed. For example, a car most certainly has a gas level indicator that _also_ tells you when you do not need to get gas. And if you look at more more professional cars, you will certainly find a green light for "engine" or something like it.
Not stupid at all. (Score:2)
Not that most people even look in regular circumstances, but what if people get warned to be careful in some environments? Then most cannot.
An indicator which is always on is an indicator which is always ignored. The purpose of this indicator is to show you something unexpected. With some 80+% of websites now using SSL it's far more valuable to indicate an insecure connection than it is to indicate a secure one.
Notice how in your car you have a lamp that comes on when oil pressure drops, or the engine goes into limp, or when fuel is low? These aren't lights which are always on and just go out when something happens.
We have 60 years of research
Re: (Score:3)
The problem with a specific "fault" indicator is that it requires an act of understanding. In fields that have reliable engineering (cars), such indicators can be simplified to "stop car now" and will not cause issues, because it will only light up if something very likely wrong. In the software field, we do not have reliable engineering. Hence users are used to ignoring indicators of faults and just try anyways because that often works. That behavior is fatal in a "security not present" indicator.
Re: (Score:2)
The problem with a specific "fault" indicator is that it requires an act of understanding.
This problem is not at all related to how the indicator shows up but rather is inherent to the indicator itself. If a person doesn't understand it then it makes no difference whether it is always lit, and off by exception or the complete reverse. Any problem with the "fault" indicator exists equally with the "secure" indicator.
That behavior is fatal in a "security not present" indicator.
You seem to be basing your entire experience on the idea that a fault indicator will be ignored because it will be frequently present. I'm not sure if you actually use the internet, b
Re: block http immediately (Score:2)
Re: (Score:2)
I don't want to buy SSL certificates for my private websites that are visited mostly by MYSELF.
Re: (Score:1)
Never heard of https://letsencrypt.org/?
Do you even use it? (Score:2)
Let‘s encrypt is brilliant, but (in it‘s simplest implementation) it needs an inbound connection resolving from to the common name used in the certificate. :80 in the firewall.
That means my internal network’s services need regular domain names (.k2r will not work) and I‘ll have to open
On top I will need to direct traffic from one inbound IP to the proper internal addresses, because I have multiple (way too many) devices on my internal network.
This really suggests to “do it righ
Re: (Score:2)
Let‘s encrypt is brilliant, but (in it‘s simplest implementation) it needs an inbound connection resolving from to the common name used in the certificate.
It doesn't. Yes, you need a hostname that's resolvable via regular DNS, but that's all: There are other challenge types [letsencrypt.org] available for hostname verification, and the DNS challenge works well.
That means my internal network’s services need regular domain names (.k2r will not work)
True.
and I‘ll have to open :80 in the firewall.
On top I will need to direct traffic from one inbound IP to the proper internal addresses,
Nope.
Re: (Score:2)
Let‘s encrypt is brilliant, but (in its simplest implementation) it needs an inbound connection resolving from to the common name used in the certificate.
It doesn't. Yes, you need a hostname that's resolvable via regular DNS, but that's all: There are other challenge types [letsencrypt.org] available for hostname verification, and the DNS challenge works well.
Really, why do you think I wrote /simplest/ implementation and what kind of challenge would you consider to be more simple? Scripting DNS updates? I was talking about the network in my /house/ that contains way more devices talking to each other and me than I imagined 20 years ago.
LE is fine, they rock, I love them and I use it a lot, and I really like caddyserver, but at home I‘m not a company employing an administrator to worry about this, I have to do it myself.
I hate knowing enough on the topic to
Re: (Score:3)
There are a couple of ways to handle this. You can self sign a certificate and then install it in Chrome so that it is trusted (or install it in your OS if you like). That's a good option for corporate networks where Chrome can use a centralized configuration to distribute the certificate automatically.
It's not dissimilar to how you handle your SSH keys.
Another option is to use a public CA with just a DNS entry rather than an IP address. You can set the DNS to be public, generate a certificate, and then cha
Re: (Score:2)
Of course I can operate my own CA and import it into the trust store of all devices that are communicating with each other, hoping, that they will all work with it. Hint: There are more things speaking to each other than Humans, Chrome and Apache and I met quite some resistance convincing some stuff to speak TLS within the last decades. This (has been) work and I hate doing it at home.
And it is a lot more involved than my current setup and I don‘t see much security gain in my home network.
(This is how
Re: (Score:3)
I know this is an unpopular opinion around here, but I object to Let's Encrypt because it empowers malicious actors to get trusted SSL certs without putting up any kind of payment or personal identification.
Yeah, I know that a certs are cheap. Even without Let's Encrypt I buy certs for less than 10 bucks per year. But, that requires some kind of payment, and that means a financial paper trail. With Let's Encrypt, there is no financial transaction. Yes, criminals can use stolen credit cards to buy certs,
Where‘s the damage (Score:2)
[Blech] but I object to Let's Encrypt because it empowers malicious actors to get trusted SSL certs without putting up any kind of payment or personal identification.
Let‘s Encrypt verifies that the requestor of a certificate is in control of the system that the certificate is for. The kind of certificates Let‘s Encrypt provides say nothing more than “this connection can be considered private between you and the person controlling the system you are talking to“. If a malicious actor is in control of the system a malicious actor is in control of the system.
Once a malicious actor has an SSL cert, it becomes easier for then to hide their traffic from firewalls and antivirus, and there are plenty of examples of Let's Encrypt's services being abused in this way.
- A payment paper trail is an accident and not reliable
- A connection is either securely encr
Re: (Score:2)
[Blech] but I object to Let's Encrypt because it empowers malicious actors to get trusted SSL certs without putting up any kind of payment or personal identification.
Let‘s Encrypt verifies that the requestor of a certificate is in control of the system that the certificate is for. The kind of certificates Let‘s Encrypt provides say nothing more than “this connection can be considered private between you and the person controlling the system you are talking to“. If a malicious actor is in control of the system a malicious actor is in control of the system.
Agreed, but web browser vendors have historically presented the notion that SSL=Secure, and that's what most users believe.
Once a malicious actor has an SSL cert, it becomes easier for then to hide their traffic from firewalls and antivirus, and there are plenty of examples of Let's Encrypt's services being abused in this way.
- A payment paper trail is an accident and not reliable
- A connection is either securely encrypted or it is not. I don‘t see how Let‘s Encrypt makes it easier to hide traffic than any other SSL encryption
The paper trail may be accidental and unreliable, but is better than nothing. Crime syndicates get busted based on paper trails. Let's encrypt certs is just too free and too anonymous.
To inspect traffic I have to run a forward SSL proxy at the firewall, breaking the SSL trust environment. Antivirus software does the same locally to scan incoming HTTPS traffic. That causes a lot of brow
Re: (Score:1)
Re: (Score:2)
It's really useful for local stuff. Some applications put out http status. So I can see an argument for blocking it from publicly routable addresses, but not entirely.
What would be interesting would be to have a mode where it's blocked, but gives you a notice like the popup blocker, so you can enable it. Then see how often it gets enabled and why. We should be nearing the point where http is as rare as ftp.
Re: (Score:3)
I agree with you that one ought to expect a public website to use HTTPS. (I'll assume for a moment that the last sentence is hyperbole.)
However, HTTPS introduces practical problems for web-based administration interfaces of appliances on a home LAN, such as a router, printer, or NAS. What certificate should an appliance on a home network use? If a certificate from Let's Encrypt or other free DV CA, then under what domain name should such an appliance obtain a certificate? Or is it time to expect each head o
Re: (Score:2)
There's no reason it should be as hard as it is to have your own CA and issue certs for your printer and such.
A desktop app with a simple interface could write pem files and ideally upload them to your printer.
The lack of standardization is glaring.
Re: block http immediately (Score:2)
Re: (Score:2)
"Now what do I click on?"
"That thing. Now see that field?"
"That what?"
"That little box, click it and type this list of letters."
"Why can't this all be automatic?"
Because programmers are idiots who should be kept well away from product design. [amazon.com]
Re: (Score:2)
However, HTTPS introduces practical problems for web-based administration interfaces of appliances on a home LAN, such as a router, printer, or NAS. What certificate should an appliance on a home network use? If a certificate from Let's Encrypt or other free DV CA, then under what domain name should such an appliance obtain a certificate? Or is it time to expect each head of household to buy a personal domain?
If browsers supported TLS-SRP this wouldn't be a problem. You would be able to securely access your device using only a username and password.
Re: (Score:1)
Error: DDNS subscription expired (Score:2)
QNAP does this rather well. They assign you a subdomain, then do ddns on it
Do the subdomain and the dynamic DNS still work after the 12-month factory warranty on the device runs out?
Re: (Score:1)
Re: (Score:1)
The definition of communication is two-way. 99.99% of the web sites I visit daily only send me information, I don't login, don't send a password, don't send any personal information, nothing to intercept.
ISPs tamper (Score:3)
Without HTTPS, the current protocol provides no way to verify that your ISP isn't tampering with the contents of even one-way communication from a website to you. Xfinity by Comcast, for example, has been shown to tamper with cleartext HTTP connections to insert advertisements. (I can find sources on request.)
Would the answer be to add signing-only cipher suites to HTTPS to verify integrity without confidentiality?
Re: (Score:3)
An attacker with access to your network can inject a redirect or a browser exploit and take over your computer or mobile device. Just google browser exploit .. there have been plenty over the years.
Re: (Score:2)
Re: (Score:2)
Well I didn't think so much education is lacking. An unencrypted stream is susceptible to injection attack. For example, a browser exploit can be injected by someone on your network to take over your computer. Or you can be redirected to a malicious site.
Re: (Score:3)
Some advanced users want to use old operating systems on a virtual machine. Since web servers somehow completely dropped support for old-HTTPS, it's incredibly difficult to download one of the latest browsers that still runs on the older operating system.
Also, https is still susceptible to MITM-hijacking. In the same way ransomware can get on people's computers, sufficienctly advanced malware can inject certificates and intercept content as if it's regular
Kazakhstan, greatest MITM in the world (Score:2)
Or maybe a country can mandate certain certificates to be installed for internet access.
Kazakhstan tried mass-MITMing the country's HTTPS connections a couple times. The major browser publishers pushed an urgent update to explicitly revoke trust for that certificate [slashdot.org].
Or maybe the website or browser is doing something that doesn't technically require https.
Browser makers are working on that as well, gating more and more JS APIs behind Secure Contexts [pineight.com].
Re: (Score:1)
Communication must always be end-to-end encrypted. Browsers should ditch http immediately, no notice required. If anyone was not using https by now they shouldn't be allowed to have a website or service and spend 6 months to a year in jail.
A website that doesn't require authentication, or collect personal information, and exists solely for the purpose of serving public information, does not need HTTPS.
If you're that paranoid, best not think about what a subpoena served to your ISP could still provide. And I sure as hell hope no one tells you about camera use in public and mass video surveillance. You might get the idea that we're living in some kind of dystopian Orwellian hellscape...
Integrity (Score:2)
A website that doesn't require authentication, or collect personal information, and exists solely for the purpose of serving public information, does not need HTTPS.
How do you prove that the public information that you received is the same public information that the server sent? At least with HTTPS, you have the browser publisher's word that a CA vouches for the server's authority to speak for a particular domain.
Re: (Score:2)
A website that doesn't require authentication, or collect personal information, and exists solely for the purpose of serving public information, does not need HTTPS.
How do you prove that the public information that you received is the same public information that the server sent? At least with HTTPS, you have the browser publisher's word that a CA vouches for the server's authority to speak for a particular domain.
Yes, because we've never had CA corruption happen before. And if HTTPS is the end-all-be-all for integrity, I'd like to know why they're even wasting their time providing 512-bit integrity hashes for downloads served under the magical protocol. Seems quite redundant.
Re: (Score:2)
Yes, because we've never had CA corruption happen before.
(Sarcasm noted.)
When this has happened, such as with DigiNotar and Symantec, the browser publishers have marked the culprits' root certificates as compromised.
I'm sure this won't go badly at all (Score:2)
Nope.
So no indication is better? (Score:2)
Also disappointing is that they've just made it more inconvenient to see the certificate info.
Re: (Score:2)
The problem they see that they're trying to solve is that, based on their research, people incorrectly associate the lock icon with trustworthiness of the site rather than the security of the connection to the site. Removing it and only warning if there's an actual problem with the connection security solves that problem.
In my opinion, people shouldn't need to give a second thought to whether the connection is secure anymore. Secure connections should be the default. Other factors such as trustworthiness, p
Re: (Score:2)
Inappropriate conclusions (Score:2, Informative)
Why not do both? (Score:1)
Seriously, why? Is there a shortage of green pixels or something?
They constantly want to try to hide part of the URL anyway, so it's not like they need the room for that ...
More downranking? (Score:2)
They're ALL insecure websites (Score:3)
Bwahahahahaha
extreme stupidity (Score:2)
This is in the category of something not being there tells you X. The problem is that the something not being there could be due to any number of bugs or unforeseen circumstances. They are idiots.