
Chrome's 'Secure' indicator was designed to make users proceed on any HTTPS site - nailer
https://certsimple.com/blog/browser-security-indicators
======
sbierwagen
Certsimple is talking their book. They sell EV certs, so they have to trash DV
certs, like the ones Let's Encrypt provides for free. Reminder: Amazon uses DV
certs, and they seem to be doing fairly well.

~~~
Rjevski
There should be a separation between transport security and brand
authenticity, and the latter shouldn't even be part of TLS.

~~~
nailer
EV is matching a legal entity to a pubkey. Nothing more, nothing less. Brands
and trademark ownership don't come into it: it's legal identity only. Let's
look at how other cryptosystems match identities to public keys:

\- Debian/dpkg does it with key signing parties, where people hold up their
passports and read out the pubkeys used to sign their packages. From
[https://wiki.debian.org/Keysigning](https://wiki.debian.org/Keysigning) :

> The people who will sign your key will need to see some form of government
> issued ID (passport or similar).

This is almost the same as the EV process for a sole proprietor.

\- Email users who use GPG do it by publishing keys in places like keybase or
university address books which confirm identity by control of other well known
accounts associated with that person - eg, your Twitter handle, or university
account associated with your identiy.

\- SSL/TLS _used_ to do this with phone calls, faxes and YellowPages entries,
verifying that all those fields you entered into your CSR were correct, before
GeoTrust invented Domain Validation to save themselves a bunch of money.

If you don't want to prove who you are, that's fine. But matching identities
to pubkeys is a very, very normal part of PKI.

------
atonse
I clicked on this article looking to just scoff at some way for a CA to make
money in the LetsEncrypt era, but I actually sort of agree with the idea of
this. So much of security is about user behavior.

"Secure" implies my password won't get stolen _ever_, not just "won't get
stolen while I'm in this coffee shop but may be stored carelessly in plaintext
by this vendor".

Private would imply the latter more clearly, rather than the former.

~~~
schoen
I actually work on the Let's Encrypt project (though I'm speaking for myself
here), and I have often said when forms of this issue have come up that I'm
not sure what the right forms of security indication in browser UI should be.
Obviously the Chrome people have been putting a lot of thought and research
into this question. It seems like they would probably agree that there are
significant challenges here and some fairly bad trade-offs. A simple form of
that trade-off is that we don't want people to enter personal information or
passwords on non-HTTPS sites, but we don't want them to think that a site
being HTTPS means they don't have to care what site it is.

We had someone on the Let's Encrypt forums complain that her site got hacked
even though she used a Let's Encrypt certificate, which was supposed to make
her site "secure". But I'm pretty confident that millions of site visitors
experience exactly the same kinds of confusion about the meaning of the
certificate, and don't regularly think about all the different dimensions of
security here (including the confidentiality of your communications on the
wire, the forward secrecy of your communications, the protection of your
communications against tampering and content injection, the identity of the
site operator, the intentions of the site operator, the data retention
practices of the site operator, the data protection practices of the site
operator, the jurisdictional exposures of the site operator, whether the
site's infrastructure has been compromised, whether it will be compromised in
the future, whether third parties can send you data through the site that
harms you personally or that harms your devices...).

~~~
x0x0
Overselling "Secure" to help lower people's defenses on a site like
[https://bank.com.fraudster.com](https://bank.com.fraudster.com) actively
hurts. That button does not code to most people as "this site is merely who
they say they are", rather than "this site is who I think they are".

My MIL is unable to make that distinction and used to regularly get passwords
stolen. The solution is to only use ios devices and rely on apples app
curation. She doesn't do banking or anything else sensitive on her computer.

------
vtlynch
I wrote an article that covers some similar ground, but is focused on _why_
Chrome's team chose "Secure" over the alternatives, such as "Private."

It is quite a bit longer, but I do break down the data to show some big issues
with the alternatives. For example, 28% of users surveyed said they would
leave a site if it said "Private."

[https://www.thesslstore.com/blog/chrome-https-secure-
indicat...](https://www.thesslstore.com/blog/chrome-https-secure-indicator/)

I agree with Mike that Chrome's testing was incomplete. It _is_ important for
them to test perception... because we wouldn't want indicators having a large
negative effect on things like bounce or conversion rate. In some ways this is
comprehension to an average user... we probably can't expect most people to
ever rationalize past "am I safe or not."

------
stordoff
'Secure' may be flawed, but is 'Private' any better? To me, 'Private' carries
the implication that the data is only known by a specific set of people, which
doesn't seem particularly helpful to a user if that set of people isn't
verified -- flagging it as 'Private' may mistakenly lead to them thinking it
has been.

Also, what does this mean for EV certs if Chrome is training users to look for
'Secure'? Given that EV certs don't display that, does it reduce trust in
them?

~~~
peterwwillis
Private isn't even a valid descriptor. The indicator only shows up on valid
encrypted connections signed by a trusted CA.

It does _not_ ensure privacy. It ensures encryption. Technically, the data is
_obscured_ , but it is not private. Private would mean nobody knows what is
going on. But anyone with a passive traffic sniffer and some machine learning
algorithms can determine your client, your OS, your network, and what websites
you are browsing over HTTPS.

A valid descriptor would be "Encrypted".

~~~
ams6110
If you think the typical paypal user will understand the difference between
"Secure", "Private", and "Encrypted" I would beg to differ.

CAs who issue certificates for clearly fraudulent domains like
paypal.com.removed-limits.com are the problem. Anyone signing a CSR like that
should be blacklisted in all the browsers.

~~~
pfg
What are your thoughts on a CA issuing a wildcard certificate for:

    
    
      *.com.removed-limits.com
    

Blocking the string "paypal" would prevent issuance for phishing sites for
maybe a day. After that, they'd have all migrated to "payypal" or "paypel",
which would still be more than sufficient. And if that stops working too,
well, good luck with wildcards!

Not to mention that in an HTTPS-only world, CAs would have _full_ control over
which domains are permitted on the web. Is introducing a semi-centralized
content police really a good trade-off just to prevent phishing, or shouldn't
we look into how we can prevent phishing using other means (U2F, webauthn) and
focus on moving to negative-only security indicators (where HTTPS becomes the
default, with no security indicator)?

------
r3bl
I do agree with the premise of this article. Heck, even if you click on the
"secure" button, it tells you that the data is "private" when submitting to
the website, not "secure".

I would still be okay with this if there's _some_ indication about the cert on
click, but nope, that's bundled way too deep in the developer tools for some
reason. Apparently, giving control over MIDI devices (there's literally dozens
of sites that allow you to do that!) is more important than showing info
_about_ the certificate.

NOTE: Using Chromium instead of Chrome, but I doubt there's any difference
between the two UI-wise.

~~~
jlgaddis
You can re-enable the certificate info when you click on the lock icon. Visit
chrome://flags/#show-cert-link, click Enable, and restart your browser.

~~~
ekimekim
On what version? I can't find that option on chromium 59.0.3071.115. Tried
your link, which just gave me the top of the page, and tried ctrl-Fing for
'cert' but only got 'Allow invalid certificates for resources loaded from
localhost.'

~~~
jlgaddis
Sorry, starting with version 60

------
woliveirajr
That's a little bit nastier than that, IMO.

When you get confident that something is secure, you lower your expectations
not only for the moment, but as a "stored memory", let's say.

In other words: if you provided your real information to the nefarious site,
someday back in the past, and you though it was ok because it was marked as a
green-secure, when the problem hits you back in the present-future, you won't
be able to remember when you did wrong. Because it wasn't suspicious at all at
that moment.

So, effects and consequences will hit you in the future because your memory
was also stored as a wrong representation of the reality.

------
hdhzy
I'd like to have http marked as "not secure" (there is flag in Chrome to do
so) and https should not have any indicators. It's http that is insecure,
https should be kind of "default". Of course EV should get extra green text
like now.

------
dingo_bat
You can't even see the actual SSL cert in chrome anymore. Some UI decisions
just don't make any sense, to the point where I think UI engineers are just
trolling us all.

~~~
deathanatos
I can?

Open Dev Tools (Click the menu "…" button, More Tools, Developer Tools) then
click "Security" then "View Certificate".

What annoys me most is that Firefox refuses to show you the certificate if it
fails to validate, which makes figuring out validation errors more painful.

~~~
dingo_bat
Ooh! So that's where they stashed it. But aren't regular non-devs supposed to
verify certificate name and the name of the website they are on? Earlier, you
could click on the https part of the address bar and it would show you the
certificate details.

~~~
vtlynch
>But aren't regular non-devs supposed to verify certificate name and the name
of the website they are on? But aren't regular non-devs supposed to verify
certificate name and the name of the website they are on?

The browser does this for you. Chrome (and all major browsers) have a
certificate validation that parses the hostname in the certificate and
compares it to the site you are on.

Checking certificate details manually is primarily useful for troubleshooting.
It serves little to no security benefit for 99% of users.

------
codedokode
They are right. The word "Secure" gives a false impression that the website is
secure, and not a scam. It should be named "Encrypted" instead.

------
mercora
I don't get why its not just indicating that the connection is "Encrypted".
Even my mother, that has no deal whatsoever with this kind of stuff, would
understand what that means.

~~~
bandrami
Because then people would realize that they've spent years paying certificate
authorities for essentially no reason, since a self-signed certificate
encrypts just as well, and for 90% or so of HTTPS traffic it doesn't really
matter if the host is authentic (as in, I don't particularly trust
news.ycombinator.com more than I trust somebody impersonating them).

~~~
Ajedi32
Encryption without domain validation is pretty much useless. Your
ISP/Government/WiFi Hotspot Operator/Friendly Neighborhood ARP Spoofer is just
as capable of issuing themselves a valid self-signed cert for google.com as
Google themselves are. If you don't know who you're talking to, whether the
connection to that entity is "private" or not is kinda a moot point.

~~~
bandrami
Only if you have some sort of trust in the putative other party. I don't trust
news.ycombinator.com more than I trust some rando pretending to be
news.ycombinator.com, so domain validation here is pointless for me. It's nice
to know that, whatever entity I'm communicating with, the message was not
altered or inspected in transit.

~~~
Ajedi32
> I don't trust news.ycombinator.com more than I trust some rando pretending
> to be news.ycombinator.com, so domain validation here is pointless for me.

Okay, so if you try to connect to news.ycombinator.com and instead get
connected to a random MITM attacker who then connects to the real
news.ycombinator.com and proxies your traffic, you're fine with that?

> It's nice to know that, whatever entity I'm communicating with, the message
> was not altered or inspected in transit.

So just so long as another MITM attacker can't inspect or alter your messages
to the first MITM attacker you're fine? I'm having trouble following your
logic here.

Again, without some way to validate that the certificate you're using is
controlled by the website you intended to connect to, you might as well not be
using TLS at all; it's completely pointless.

~~~
bandrami
_Okay, so if you try to connect to news.ycombinator.com and instead get
connected to a random MITM attacker who then connects to the real
news.ycombinator.com and proxies your traffic, you 're fine with that?_

Right. Why would I trust ycombinator.com more than the MITMer? I have zero
actual experience with YC, so any information I give them is by definition
information I would give to an untrusted party.

~~~
Ajedi32
> any information I give them is by definition information I would give to an
> untrusted party

Including your password to the real news.ycombinator.com?

------
bandrami
_Considering that authenticity is part of security, the 'Secure' label is
factually incorrect: the site is not authentic._

How is the example site inauthentic? It is in fact paypal.com.removed-
limits.com, as verified by a certificate authority and displayed by the
browser. That is authentic.

~~~
nailer
OK I'll bite. What percentage of end users do you think understand DNS enough
to distinguish the site from others? Especially if the page is filled with
PayPal branding and the browser expressly says the page is Secure?

~~~
bandrami
Are you able to tell the difference between Citibank and Citi-Bank? This is a
problem that encryption just doesn't address.

------
nailer
Author here. While the flawed 'Secure' indicator on every HTTPS site will go
away soon in favour of negative indicators for non-HTTPS connections, the
worrying thing here is the researchers didn't really examine their own biases.
[https://airbnb.design/anotherlens/#answer2](https://airbnb.design/anotherlens/#answer2)

Speaking of biases: while CertSimple is obviously interested here - online
identity is our job - the tweets included, both for and against marking all
HTTPS as 'Secure', are from Chrome engineers employed by Google.

~~~
CiPHPerCoder
> While the flawed 'Secure' indicator on every HTTPS site will go away soon in
> favour of negative indicators for non-HTTPS connections

Isn't this good for your business model?

> the worrying thing here is the researchers didn't really examine their own
> biases.

Okay, so, how much money is CertSimple willing to offer up in the form of
research grants to address these unanswered questions?

~~~
nailer
We addressed the need for more research by everyone - us included - at the end
of the article. We're more likely to do our own original research (like
Google) than pay for grants, as we're a bootstrapped startup.

