It's not easy being green: EV HTTPS cert seller Sectigo questions Chrome's logic in burying EV HTTPS cert info

Sectigo’s chief compliance officer has hit out at Google for minimizing the visibility of Extended Validation HTTPS certificates in Chrome. 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 …

[Tascam Holiday]

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.

[IGotOut]

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.

[Anonymous Coward]

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.

[Anonymous Coward]

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

[Hubert Cumberdale]

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

[needmorehare]

Google gets to improve web security so that..

Web apps and PWAs can take over. They want everything to be web based so they can realise their mission of organising the worlds information and making it more accessible. Eliminating plaintext protocols, alongside the implementation of CA pinning, helps achieve that goal.

I happen to think the web is a dumpster fire these days and that native apps are better. But developers seem to disagree, opting for bloatware like Electron... bloatware which makes Java look like Mo Farah.

[LosD]

"Newsflash: Seller of X doesn't like that no one cares about X"

[sabroni]

Google made the decision?

Oh well, it must be in the best interests of the general public then.

[Martin Summers]

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.

[Dan 55]

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.

[Ben Tasker]

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)

[Dan 55]

Re: Google made the decision?

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.

UI fail by Google. It should have been green for both HTTPS and HTTPS EV.

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.

That's because Google decided the new definition of security was more about not being open to mass data slurping, before it was more about being authenticated with the website you're supposed to be authenticated with.

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)

Firefox had a better UI, it was green for both HTTPS and HTTPS EV and EV certs also had the business name in green next to the padlock as well. But Mozilla followed Google's lead as per usual ("Soon after Chrome's announcement, Mozilla also announced").

Didn't downvote by the way.

[Norman Nescio]

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.

[Ben Tasker]

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

[The Basis of everything is...]

Internal CA not that difficult

If you control the distribution of keys to users machines, set up a Certificate Revocation List on a server somewhere and be sensible with the signing process it's not difficult to run an internal CA. There's various tools to help manage and automate too,

For small organisations you can do it yourself with the like of XCA or if you want to be really hard core techie OpenSSL on the command line.

[Ben Tasker]

Re: Internal CA not that difficult

> and be sensible with the signing process it's not difficult to run an internal CA

Regional Sales complained to your CEO because they needed to get a demo site live urgently, but no-one from your team was available to sign the certificate. The direction has come that sales should be given access to the signing doo-hickery so that they can sign their own certs when needed.

As I said, running an internal CA is easy. Managing it properly, in a decent sized organisation is not (there will be exceptions), just as with everything else sysadmin'y sometimes directives come from on-high that completely undermine your ability to run it properly.

[Anonymous Coward]

Kinda a false choice though, isn't it?

Going backwards to fully user managed certs WOULD be a nightmare. That is kind of like saying dropping all forms of light other than the sun would be worse than only using matches. Technically true, but still backwards.

The EV part of EV certs doesn't fix the problems that are inherent to SSL/TLS as implemented. That doesn't mean the idea is without merit. I'd suggest separating the EV part so it can be an add on independent of the issuing CA (Better Competition) and improve both it and the certificate architecture to address the glaring chain of trust issues. Specifically, we need to address the SSL/DNS conundrum that any CA can issue a cert for any domain. Part of the domain registration should include designating your allowed DNS and CA's, so only the CA you actually use can issue a cert clients will accept as valid. No more banana republic issued certs cloning other peoples domains. Then the EV endorsements can provide additional confidence for critical services and raise the cost of exploitation to make domain spamming less cost effective. It would also make it easier to exclude bad actors, both as CAs and EV endorsers.

[needmorehare]

Certificate pinning plus strong authentication = WIN

Have DNS-over-HTTPS backed by DNSCRYPT convey the correct CA for the site you’re about to use. If it doesn’t match, reject it. Then to ensure phishing can’t happen, just force users to use tokens. Banks can afford to hand out dedicated devices to account holders and ordinary sites can just have users enrol with a TPM (standard in PCs) for webauthn or authenticate using their phone with a QR code (similar to WhatsApp).

[Ben Tasker]

Re: Certificate pinning plus strong authentication = WIN

> Have DNS-over-HTTPS backed by DNSCRYPT convey the correct CA for the site you’re about to use

That only helps you as far as your chosen resolver. Someone capable of answering queries from your resolver can still send an incorrect response.

Also, how do you intend to authenticate the HTTPS connection you're placing DoH over, given there's now no locally trusted store? Is the browser vendor going to pre-approve some (in which case, you've still got a problem of trusting someone you haven't vetted, and who might get compromised).

What you've done here is moved the security challenge from one place (the browser/OS's trust store) to another (DNS). It presents different challenges, but crucially, as a user you've now got less control (you may not want to, but you can currently go through and disable roots you don't want to trust).

> Then to ensure phishing can’t happen, just force users to use tokens.

Nice idea, but you'd need to get buy in from every disparate service operator, worldwide. Otherwise, part of the push-back you'd get from the userbase would include them going to your competitor who doesn't require 2FA.

Forcing things onto users never really pans out too well, even at smaller scale (new password policy at work? Checked whether there's been an increase in post-it orders?)

> authenticate using their phone with a QR code (similar to WhatsApp).

That works because Whatsapp is already tied to their phone, and that phone is running your app.

If you start requiring users to run your app on their phone to use your service, you're likely to see that newer users go to a competitor instead (depending on your service, honestly, that'd include me).

Using something like TOTP would be more viable as it gives users more flexibility, but even that still gets pushback.

There are no simple answers. There's plenty that sounds idyllic as an improvement, but once you add meatbags to the equation they tend to go awry.

[Claptrap314]

I bank with Chase

What address should I expect the cert to show, and how in the world could I determine that?

[Anonymous Coward]

PayPal

I do keep a watchful eye on the address bar and certificates when doing anything financial online and will even check the site's certificate with Gibson Research's "HTTPS Fingerprint" site as an added step:

"https://www.grc.com/fingerprints.htm"

But when trying to make an online payment to PayPal I noticed that my web browser's address changed as did the trust certificate to some weird "cloud" I've never heard of before:

"HydrantID (Avalanche Cloud Corporation)"

For a few desperate moments I thought my DNS had been poisoned or my computer compromised until I found out about the sale of PayPal credit to Synchrony bank.

It still looks extremly scammy to this day.

[Anonymous Coward]

GRC is still around, that's a blast from the past.

Is he still trying to code everything in assembly?

Always an entertaining if alarmist part of the earlier internet era. Made a few handy tools to too, and one of the few that were consistently really small too.

[Werner Heisenberg]

Just found out

Firefox not only removed the address bar label, they nuked the site from orbit.