HN Explorer

Chrome and misleading security information

1 points by tcarnell ↗ HN
If you use a self-signed certificate to secure a website, Google Chrome's reaction is somewhat dramatic and I would say inaccurate and misleading. Below is a screenshot (sorry, you'll have to accept the certificate to view it!):

https://puntoshare.com/resource/BvihzPSc

The Google Chrome url bar with the "https" and "padlock" icons crossed out with a bold red line would suggest to the user that the page is not encrypted, does not use HTTPS and is 'not safe'.

Of course, this is not true and the Chrome 'site information' text clearly states that the site is secured with 256-bit encryption (and displays a reassuring green padlock icon). However, I am sure very few users actually view the 'site information' text.

I agree that the certificate does not verify the identity of the site, but this is a separate issue, right? I just want to ensure the user that information passed to/from the server is encrypted.

We visit unsecured websites all the time and we have no idea how safe they are or who owns them and browsers give us absolutely no warnings, so I am a bit disappointed that when I do attempt to increase security for the end-user the browser works against me, implying the site is unsafe.

Can't Google bypass the CA's and implement their own site authentication mechanism (for free)?

15 comments

[ 4.3 ms ] story [ 55.1 ms ] thread
Piskvorrr
What makes Chrome special here? AFAIK, every browser (FF, IE, Opera, you name it) treats HTTPS with problems as "extremely scary, alert the President" (which is, IMNSHO, absolutely correct behavior - "this site says it's HTTPS://whatever, but I'm unable to verify this, so let's crash and burn - it might just as well be https://evilsite.evil, for all I know"), whereas unsecured, plain HTTP is seen as "meh, whatever."

Moreover, "why can't Google fix the Internet?" is, essentially, saying "do away with the other CAs, and make Google the ultimate CA" - doesn't fix the problem, plus makes it worse.

(FWIW, there are cheap SSL certs out there which are signed by known CAs and thus don't trigger the security error.)

tcarnell
yes, I picked on Chrome just because that's what I was using at the time, I am aware the problem probably exists on most browsers.
Piskvorrr
As I stated in my reply, that's not a bug, that's a feature; sorry to hear it's inconveniencing you, but there is currently no other way to distinguish between https://yourbank.example.com/ and a MITM by https://phishingsite.evil/

Replacing a CA-based chain of trust with a Google-based chain of trust makes no difference IMNSHO (except that Google would essentially own and 0wn the Internet; not a pleasant side-effect).

mooism2
Without verifying the identity of the site somehow, you are vulnerable to a mitm attack. So no, it's not a separate issue.

What is your proposed site authentication mechanism that Chrome should use (and does it scale to Firefox, Safari, etc)?

tcarnell
good point. ok, I should probably think carefully before inventing a security standard 'on the fly'!

I guess I was thinking along the lines that I could add my site to a Google service (just like Analytics) and when people accessed my site (https), Chrome could talk directly to Google and confirm the site authenticity, same way CA's work I guess, but run as a free service.

But as noted in another comment, anything vendor specific would probably be a bad thing for the web.

Piskvorrr
And why exactly would Google (or anyone else) provide this service for free? (Well, except for the ability to do various nasty MITM stuff; but they have that "do no evil" motto - seems legit)

Sounds like "but I dont waaaaaaaaahnt to pay any money for services that I need! I don't care that infrastructure isn't cheap, I just want my free lunch."

tcarnell
yep, that is exactly what it sounds like!
tcarnell
I think I would be more relaxed if browsers used an additional icon to indicate if a site identity is verified or not.

And just because somebody has paid for a site certificate and gets a nice green padlock icon on the URL bar does not mean they wont misuse peoples personal information, does it?

Sambdala
The red warning page you have to click through also seems irresponsible to use in cases like this.

It's the same page you get when there's malware on a site.

Piskvorrr
Well, if the site normally validates, and this time the HTTPS certificate is self-signed all of a sudden - why of course I want to see a big, red, scary warning, because that's what the situation requires.

(Most browsers allow you to exempt specific sites from this warning - this is, however, a significant decrease in security ("to see the dancing hampsters and download our malware, click 'yes yes add exception agree agree I know this is a bad idea yes yes'"); Chrome - aiming to be the browser for the masses - decided to go with the "secure" part of the secure/easy tradeoff.)

dchest
Did you read the warning? It pretty much answers your question:

"This may mean that the server has generated its own security credentials, which Google Chrome cannot rely on for identity information, or an attacker may be trying to intercept your communications."

I just want to ensure the user that information passed to/from the server is encrypted.

Self-signed certificate doesn't guarantee the encrypted communication to/from your server. An attacker can intercept your handshake request and provide their own self-signed certificate.

You can create your own CA, sign a server certificate with it, and then ask users to install your CA certificate into their browsers.

Or you can get a free certificate from StartSSL.

Alternatively, you can contribute to some replacement for TLS.

tcarnell
ok, so are you also saying that it is impossible for an attacker to intercept data from a standard HTTP request?

My next point being that if standard HTTP is also vulnerable to such attacks, why doesn't the browser display a warning on EVERY page, telling us that it can not verify the website identify? Thus, all things being equal, I would assume that unverified, but encrypted is still better for the user than unverified AND unencrypted.

...but I've probably misunderstood something fundamental here (as is often the case!)

mooism2
HTTPS claims to secure the connection, so it is necessary to make clear when these claims aren't justified.

HTTP makes no security claims, no there's no "unexpected lack of security" to disclose.