It's not easy being green: EV HTTPS cert seller Sectigo questions Chrome's logic in burying EV HTTPS cert info
- Reference: 1614771906
- News link: https://www.theregister.co.uk/2021/03/03/sectigo_google_certificates/
- Source link:
These are the certificates that contain verified details about the owner of the cert, such as its legal name, government-issued business ID number, and physical location. These records could be displayed in, or be easily accessible from, the browser's address bar. This information is manually verified by humans at the certificate issuer prior to the cert being handed over. The idea being that if someone arrives at a website and wants to be certain it's operated by, say, their bank, they can check the verified details of the owner and see that, indeed, yes, it is their bank.
[1]
Google all but [2]hid these extra details in a Chrome update a couple of years ago, arguing that netizens couldn't care less if a site is protected by an EV or a vanilla HTTPS cert – it won't stop them putting in their credit card number or password. Others in the industry have [3]questioned the usefulness of EV certs.
In a chat with The Register , Sectigo CCO Tim Callan said his biz, which among other things is one of the biggest sellers of EV HTTPS certificates, was "going to remove street and postal information from all of our public sites," seeing as Google thinks no one cares where a business is based.
[4]
In some browsers, it's very difficult to even find it. And you have to really know what you're doing
"Once upon a time, if you went back to the 2000s, that information was very visible in the browser," Callan said, "and it was considered to be an important value-add, because when I went to your browser, I could drop down and I could see where this business was located."
Over the years, however, browser makers have given the "little green padlock" increasingly less prominence, said Callan – and by browser makers, he means one in particular: Google.
"Like in some browsers, it's very difficult to even find it. And you have to really know what you're doing... Firefox does a good job of displaying certificate information around but in Chrome, that stuff is buried. Burying is such an awkward word. But that'll do – burying of that information."
Burying is indeed what the number-one browser-maker did: when visiting a website that uses an EV HTTPS cert, desktop Chrome 88 displays the owner's legal name under the heading 'Certificate' when you click on the now-grey padlock icon in the URL bar. To get to the location, you need to click on the name, then in the pop-up box click on the 'Details' tab, scroll to the 'Subject' certificate field and then squint at the records in the 'Field Value' box, in which you'll hopefully find the business serial number and official physical location.
With desktop Firefox 78, you click on the grey padlock in the URL bar, and see the verified name in a drop-down box; click on the right-pointing arrow, and it opens up a panel containing the legal name and address. And this is after Firefox's developer Mozilla also downgraded the prominence of EV certs: what used to be a green indicator in the URL bar is now text in a dialog box. Apple's Safari followed suit.
Callan said Google had justified its move within the browser security certificate community by insisting the decision was "data driven." The Chocolate Factory said at the time: "The Chrome Security UX team has determined that the EV UI does not protect users as intended ... users do not appear to make secure choices (such as not entering password or credit card information) when the UI is altered or removed." Thus, we're told, it doesn't matter if the EV info is obvious or hidden away.
Had a bad weekend? Probably, if you're a Sectigo customer, after root cert expires and online chaos ensues [5]READ MORE
“Sure, after you have systematically removed everything that a consumer would see,” sniffed Callan, comparing the certificate to “hazard lights in my car.” He said: “I will use them once a year. But when I need them, I need them. And I need to know where they are. And the fact that I don't use them 364 days a year does not diminish their importance on that other day.”
A couple of years ago, the CA/Browser Forum, the industry's standards-setting body, [6]mulled cutting new HTTPS certificate lifetimes by half, from 27 months to 13 months, at the suggestion of Googler Ryan Sleevi. This would mean certificate-buying organizations would need to renew them roughly annually, thus theoretically boosting revenues for certificate issuers – unless said organizations use free certificates from [7]Let's Encrypt , which is backed by, among many others, the Google Chrome team.
The argument for shorter certificate lifespans is that it encourages organisations to use the latest and greatest encryption protocols with their certs, and minimises the damage potentially done if a certificate falls into the hands of fraudsters: the crooks can only masquerade as a legit outfit with the certificate for no more than about a year. Let's Encrypt's free vanilla certs are valid for 90 days at a time, and it provides tools to automate their regular renewal.
Sectigo, meanwhile, charges $465 a year for a multi-domain EV HTTPS certificate, if you purchase one for five years; the price goes up if you opt for a shorter duration. That does come with 24-hour support, we note. Whether or not you agree that Extended Validation certs are useful, it is in Sectigo's interests to have browsers prominently display the certificates' embedded data, or else its EVs are mostly pointless.
Google has [8]long championed the widespread adoption of HTTPS, seeking for it to be the default, secure protocol for fetching web content everywhere for everyone. Its love for HTTPS stops at EV, it seems.
[9]
A spokesperson for Google was not available for comment. ®
Get our [10]Tech Resources
[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YD-Aq4HoFRCZFkwO@pJCMgAAAMI&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[2] https://www.theregister.com/2019/08/12/google_chrome_extended_validation_certificates/
[3] https://www.troyhunt.com/extended-validation-certificates-are-really-really-dead/
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YD-Aq4HoFRCZFkwO@pJCMgAAAMI&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://www.theregister.com/2020/06/02/sectigo_root_cert_expires/
[6] https://www.theregister.com/2019/08/13/site_certificate_lifetimes/
[7] https://letsencrypt.org/
[8] https://www.theregister.com/2018/07/03/google_chrome_http/
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YD-Aq4HoFRCZFkwO@pJCMgAAAMI&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[10] https://whitepapers.theregister.com/
Re: EV certs: waste of money
Not only that, it could just a well be issued to a holding company, an accounting department or a 3rd party.
If the company's registered "address" is Dave&sons Accounting, but the company is Widgets Spanners, which one is the correct one?
Answer, both.
Re: EV certs: waste of money
"Which one is the correct one?"
Doesn't really matter - just pay more and you can whatever you want in an EV certificate. The point is to make money, not improve security.
It's all down to the validation...
EV certificates are technically identical to any other certificate. It's just a way to charge more money. Theoretically they are meant to do a more thorough check than the usual "can you receive an email from your SSL domain?"
In practice they don't do any more than increase the price. It's good that Google don't buy into the EV scam...
Re: It's all down to the validation...
It is odd to find myself agreeing with Google (and I don't even use Chrome), but they appear to be kinda right on this one: 99.9% of web users wouldn't know what you were talking about with EV even if you tried to explain it to them, and most don't seem to even really pay much attention to whether a site is even encrypted at all.
They're also annoyingly right in championing "the widespread adoption of HTTPS, seeking for it to be the default, secure protocol for fetching web content everywhere for everyone". It's obvious what the purveyors of EVs have to gain from saying EVs are great, but now I'm left wondering what Google might gain by promoting HTTPS...
"Newsflash: Seller of X doesn't like that no one cares about X"
Google made the decision?
Oh well, it must be in the best interests of the general public then.
Re: Google made the decision?
It's not just Google. As the article says, others have followed suit. Not everyone agrees with the chocolate factory, least of all browser developers. In this case Google are right, they've probably looked at the telemetry they get and found practically no-one clicks to look at an EV certs details. I can't say I really noticed or cared that their prominence reduced. I do my due diligence on a site I've never used before handing over my card details. Which is much more important than checking a physical address of a business on their site certificate.
Re: Google made the decision?
Why would you need to click to check for the details, just the visible difference next to the address bar is enough to show you've landed on the bank's page instead of a phishing site and (hopefully) the real bank has taken the trouble to apply for an EV cert and the domain registrar has taken the trouble to verify that.
It's one more thing you check along with the address to make sure you're at the right site. Idiots are going to enter their password into anything, but it doesn't mean other people didn't find it useful.
As Silly Valley only measures metrics based on where the mouse pointer is or what people clicked on they missed the point. It only takes Google to do something for everyone else to follow suit like lemmings.
Re: Google made the decision?
IIRC the argument was that it's not very effective because it relies on you noticing the absence of something (which humans aren't so good at).
If you've got a green padlock next to the bar, you'll notice it's there. But, if you've got a grey padlock (i.e. HTTPS with a non EV cert) there, will you notice and remember that it should have been green? Most (apparently) won't.
It's also the reason why they switched to not making a big deal in the UI about a site being HTTPS, but showing a big red "NOT SECURE" next to HTTP only sites. You don't notice the lack of a HTTPS notifier, but you will notice the big red warning.
As a theory, it sounds perfectly plausible, to be honest - certainly plausible enough that Firefox were also trying it (in fact, they might have done it first, I can't really remember)
The entire certificate based 'security' edifice is a sham. When was the last time you checked that all the CAs your computer is set up to trust are actually organisations you want to trust?
All Transport Layer Security does is give (limited) guarantees that people you don't trust cannot tap in and read data in transit between source and destination. It says nothing about the trustworthiness or not of the destination, which should be assured in some independent way.
When the padlock appears in the address bar, what does the fact that the connection is secure, verified by e-Szigno Root CA 2017* tell you about the site you are sending data to, and how worthy is that CA of your trust?
One of my banks used to act as its own CA, and the only way to do online banking was to install their root cert on the devices you wanted to use. Unfortunately, they gave up that approach.
It is a shame that no-one has come up with a way to make a web-of-trust easy to use. Centralised 'trust' authorities have well known problems.
NN
*Or TUBITAK Kamu SM SSL Kok Sertificasi - Surum 1. There are plenty of other examples.
> Unfortunately, they gave up that approach.
You misspelled fortunately there - that's a horrible approach.
For all the issues we have with HTTPS, things would be 10x worse if we trained users to install custom CA certs in order to use a service, just because that service said so.
If nothing else, as easy as it is to generate a signing keypair yourself, it's a lot harder to handle/manage it appropriately/safely within an organisation.
Most organisations would fail that test, and you'd more frequently end up in a situation where users had a trusted CA who's key had been compromised, with no real means to revoke it because users were responsible for managing their own trust store.
The current setup isn't perfect by any means, but it's a long way removed from that hellish dystopia.
I bank with Chase
What address should I expect the cert to show, and how in the world could I determine that?
EV certs: waste of money
EV certs are not particularly secure anyway. How do I verify that an organisation's address as indicated by the EV cert is the correct one?
See also https://www.troyhunt.com/extended-validation-certificates-are-really-really-dead/ where it was demonstrated to be trivial to get an EV cert with the same name as an existing company.