Chrome's 'Secure' indicator was designed to make users proceed on any HTTPS site | Hacker News Reader

Chrome's 'Secure' indicator was designed to make users proceed on any HTTPS site

certsimple.com

51 pointsnailer58 comments

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.

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

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 :

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

There's quotes from two Google engineers both for and against 'Secure' in the article.

In case you missed the links in the article, you can also read the original research https://www.usenix.org/system/files/conference/soups2016/sou..., section 7.2 and confirm the premise of the article's title for yourself.

I use a DV cert on my personal site. CertSimple happily directs customers to LE, Heroku, AWS Cert Manager, CloudFlare and other places where you can get a cheap / free or shared DV cert for customers who just want people to encrypt data they send to their site and don't need to prove who they are.

Reasons you might want to prove who you are:

- You're handling sensitive data and want to prove there's a real company behind the site, rather than just someone who registered a domain.

- You have other people pretending to be you and want to distinguish your site from theirs.

- You have affiliates selling your product and want to show you're actually the real site.

- You're a crypto nerd and the idea of connecting to random public keys makes you boak.

That said, the "Secure" indicator on Chrome is almost completely pointless from a user security standpoint. They would be potentially more secure with no indicator at all.

This sounds ad hominem to me. While it's certainly worthwhile to consider Certsimple's motivations when reading the article, I actually found their case pretty compelling.

It is - sbierwagen doesn't address any point raised in the article and I'll quite happily challenge him to do so - but it goes with the territory.

Cynicism is healthy. The TLS industry has historically been quite shady. Symantec was selling 'Step up' encryption certs for Internet Explorer 5.5 pre 5.5 SP1 in 2015 as a value add. Comodo tried to trademark 'Let's Encypt' for some reason that still isn't clear.

I'm quite happy for people to ignore the article I wrote, read Section 7.2 of Google's research, and verify for themselves the claim made in the title.

Then consider whether most people understand that 'Secure' means 'Secure from eavesdropping' as the quoted Google engineer suggests.

Ok, from your sibling comment https://news.ycombinator.com/item?id=15009716

  - You're handling sensitive data and want to prove 
  there's a real company behind the site, rather than just 
  someone who registered a domain.

1.) Unicode homoglyph attacks means "Goοgle Inc" looks just like "Google Inc". All browsers mitigate IDN attacks, but the way unicode strings are handled means the browser vendors have to be lucky forever, while an attacker just has to be lucky once.

2.) "Widget Inc" is a different legal entity from "Widgets LLC". Is some clerk in Delaware going to care that an attacker is registering a name vaguely similar to the name of your California corp? Probably not.

3.) Chrome uses the OS cert store. As of 2016, Windows trusts 356 root certificates. Any root can sign a cert for any domain name. How much do the owners of "TUBITAK Kamu SM SSL Kok Sertifikasi Surum 1" care about your security?

4.) It costs, what, a hundred bucks to register a corp online? Easy spend if you're spearfishing a high value target. "Shell-company-as-a-service" has been a value provider of law firms for centuries.

  - You have other people pretending to be you and want to 
  distinguish your site from theirs.

Wildcard EV certs let anyone in the world register "yourcorpname.customer-service.io", or "yourcorpname-help.com" Large corporations train users to do this, hilariously. In order to log into office 365, you visit... login.microsoftonline.com.

  - You're a crypto nerd and the idea of connecting to 
  random public keys makes you boak.

Crypto nerds don't trust the HTTPS PKI at all.

Corrections:

1. Unicode Homograph attacks don't work in a business registration. Someone would have to be able to legally register a business name that fits your look-alike example. That is not possible in most places AFAIK.

So what you re actually pointing out is that domain names are vulnerable to these attacks, which is another reason why DV certificates can fall short.

2. Correct, different companies. This is as intended, but admittedly a weakness in the human-readability of EV certificates.

3. Not all roots can issue EV certificates.

4. It becomes much harder to remain anonymous if you do these things. You are right, it isn't impossible to register a company solely for malicious use. But it carries with it legal risk.

There are no Wildcard EV certificates. You are just describing Wildcards.

Crypto nerds do trust the HTTPS PKI that is why there are about a dozen industry-leading crypto people working at Chrome, Mozilla, etc on PKI crypto.

Thanks for coming back. Quite happy to have a discussion with you about these things and there's:

- a legitimate point (2)

- Three points that indicate you don't have experience of EV (1 - you would have to prove you're legally 'Google Inc' with a homoglyph to a CA, which would be difficult, 3 as vtlynch mentioned, Timbuktu CA is unlikely to issue EV certs and if it does so would be required to be audited on how well it meets the EV for CAs requirements and 4, wildcards are expressly forbidden for EV).

- some which are against PKI, which is great but even more offtopic and you haven't proposed a working alternative. Crypto nerds laugh even more at DANE (which just makes DNS providers CAs) and web of trust (sybill attacks). We could sit and design one together but getting the web to use it may take some time. Many have tried.

...but none of those are points from the article, which isn't about EV or DV.

Still challenging you to address any point in the article if you wish to.

However it's pretty clear that you didn't actually read the article, so you'll probably want to do that first.

The article doesn't say that you can't stay in business using DV certs, so that seems irrelevant. The article says that "Secure" falsely communicates to the average user the sense that it is safe to proceed without caution, and indeed was specifically chosen for that reason.

That's hardly controversial, I would have thought. If it's true, it's true whether or not the person telling you it sells EV certs.

Unwary PayPal users are regularly phished even though PayPal have EV certs because the average user doesn't know that authentic PayPal websites should always say "PayPal, Inc. [US]" in the address bar, and aren't concerned when the address bar says Secure instead.

I think the problem really is that we want users to be "safe" on the Internet without them having to learn anything, and the Internet just isn't there yet, and quite possibly never will be.

It's like trying to design a gun you can't shoot yourself in the foot with, because people won't put up with being taught gun-safety.

I do think we could benefit from new Internet users being made, probably by their browsers, to take a short training course in the basic aspects of what encryption really guarantees on the web, how recognise malicious websites, and the like.

A DV cert from letsencrypt means you have provided some bare minimum of evidence that you control the domain in question. That's it. Most people don't understand that. They just think "https == good" and it's taken years just to get to that point. CAs need to do more and browser vendors should expect them to if they want to be included in the default bundle. CAs should not be issuing certificates for any name that contains components like "paypal.com" or "google" or "gmail"

Yeah it's kind of a game of whack-a-mole but at least get the low-hanging fruit.

I agreed with you right up until this sentence:

> CAs need to do more and browser vendors should expect them to if they want to be included in the default bundle.

CAs _should not_ be expected to validate anything about a domain name other than who controls it (at least for DV certs). That's not their job, nor should it be.

First, it's not nearly as simple as blacklisting domains containing "PayPal" or "Gmail". What if, for example, someone wants to register a domain like "paypal-sucks.com" and use that to express their distaste for PayPal's business practices? Should they not be allowed to do that?

And what about wildcard certs? `*.some-site.com` matches `paypal.some-site.com` just as easily as it does `forum.some-site.com`. Do you expect CAs to police that somehow?

You and I understand this. Most paypal users do not. That's why they keep getting phished even when their browser says they are on a "Secure" site.

Maybe it would help to have something between the green "Secure" and the red "Danger! Stop!", e.g. an amber "warning" symbol implying that "You're connected to the site your browser is showing, but be sure it's the site you think it is." Sadly in reality I don't think that would go very far to solving the problem.

The problem with showing a warning like that on every site you visit is that users will quickly become used to it and start ignoring it as a result. (Alarm fatigue)

Warnings are only useful if they're shown rarely enough for users to take note of them as an unusual event when they do occur.

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.

I did a poll for a my sociology class this year[0], I think people were confused between the ideas of what is "secure" and what is "private". In hindsight I should have put a quick definition of the two concepts at the top.

It's particularly visible in the question about "to what degree do you agree with": "social networks are secure"/"bank websites are secure".

People thought bank websites --which have notoriously bad password practices, for example mine (Société Générale) has a 6 digits password policy-- were more secure than social networks. Facebook and Twitter routinely enforce 2FA and multiple checks on each login attempt.

Link but it's in French.

[0]: https://docs.google.com/spreadsheets/d/1tGMDLGKVLfzqkkuCggzC...

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

Overselling "Secure" to help lower people's defenses on a site like 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.

Well, until companies and executives can be charged with criminal negligence for refusing to follow either the advice of their own engineers or standard practices, its cheaper to let the data be stolen and deal with the fallout than it is to deal with building actual security, so you can presume off-hand that the information you provide is not going to be secure if it is retained by them. Assurance that your connection is not being intercepted and at least the transport is secure from your end to theirs, even if it gives no assurance of who they are, is at least a protection against nibshit spies like the NSA. (Until they convince ISPs to install BlueCoat boxes which wouldn't surprise me.)

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

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

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

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

> A valid descriptor would be "Encrypted".

Someone should conduct a poll with a mockup of a URL bar that says "Encrypted" instead, asking a wide variety of users to describe what it means.

When users look at that part of the URL bar, there's an implicit question being asked of the UI.

Describing a URL as "Secure", "Private", or even "Encrypted" is a partial answer, users will infer the rest and they'll get it wrong a lot of the time.

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.

But wouldn't doing that be a _huge_ hurdle to Let's Encrypt/certification automation more generally? I'd not sure that would be a net positive.

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

A CA is just someone who verifies a cert was signed by a key that they know about. Their only purpose is to show your connection wasn't MITM'd.

They have nothing to do with figuring out if you're being phished.

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.

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.

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

Showing up for me on 60.0.3112.90 (Win 10 x64).

Sorry, starting with version 60

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.

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.

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.

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.

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

You can view it in Firefox as well: Advanced -> Add exception -> View

Or, as I just noticed, when you click on the error code (SEC_ERROR_EXPIRED_CERTIFICATE for example) it'll show you the raw certificate.

Ah, thank you! I would not have thought to look under "Add exception", since that's not what I want to do.

(I still wish it could also just be in the normal spot.)

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.

No, I don't really expect an average Joe to check certificate details. Explaining certificates to developers is hard enough — I can't imagine trying to get an average joe to comprehend it.

What details would they realistically look at, anyways? If the certificate validates, that's an automated check of most of the interesting bits. But the first thing in my dialog, for example, is the subject, which is garbage for many DV certs. Then there's the difference between CN and subjectAltName…

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

You can get to it via Developer Tools.

In Chrome 60+, you can enable the old-school certificate viewer with a flag. At some point this will become the default.

Flag is: chrome://flags/#show-cert-link

Full instructions for those less familiar:

https://www.thesslstore.com/blog/enable-certificate-details-... [self promotion]

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.

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.

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

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.

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.

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

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.

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

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.

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?

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

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

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.

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

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.

Reply on news.ycombinator.com