

Chrome and misleading security information - tcarnell

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!):<p>https://puntoshare.com/resource/BvihzPSc<p>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'.<p>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.<p>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.<p>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.<p>Can't Google bypass the CA's and implement their own site authentication mechanism (for free)?
======
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.

------
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!

------
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.)

------
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?

