If you look at this previous paper they (Entrust + Comodo) published, they're proposing that OV and EV certificates get padlocks and DV ones don't: https://casecurity.org/wp-content/uploads/2017/09/Incidence-... Or, in other words, you can't get a padlock from Let's Encrypt and you'll have to pay them for a padlock.
Compare with Google's plan at
https://blog.chromium.org/2018/05/evolving-chromes-security-... which just drops the padlock for everyone, treats plaintext HTTP as affirmatively insecure, and stops pretending that paying money to a CA means that you're a morally upright website.
A CA leaving the CASC seems like a good thing for the world.
CASC member GoDaddy cold-called a random musician with an HTTP site and told her the only way to avoid an SSL warning from Google would be to pay them $200+: https://www.facebook.com/rebecca.ann.925/posts/1740244236062...
I can see why Digicert would want to run from the CASC and keep their reputation safe.
(from Ryan Sleevi of Chrome's crypto team https://twitter.com/sleevi_/status/1012338888088719360 - searching for his other interactions with the CA Security Council is pretty enlightening too)
A more direct link to where they admit it (and publicly try to fix the mistake) is this: https://twitter.com/perezbox/status/1011708133960536064
They don't admit to a general pattern of mistakes like this there, they do say they will use this "as a learning opportunity for all our agents. Whether that is because this was genuinely a one off or because this is the only publicized example is unclear.
Apple's App Store for example demands that companies wanting to publish apps have to undergo a verification process using a DUNS number. And this has been useful for example in resolving trademark and DMCA disputes. But not really sure if it's improved security in any way.
This is interesting to me, in part because I've argued again and again against the idea that HTTPS must involve verification of the legal identity of the operator of a website, and for many years I always had people push back and insist that the encryption part was only a tiny, almost worthless portion of HTTPS -- identity verification was the real benefit. I even had people claim that encryption without identity verification was actually worse than no encryption at all! It was as if they lived in a completely different world than I did, where eavesdropping/recording of unencrypted transmissions was incredibly rare and not worth worrying about, but ten trillion googolplexes of HTTPS spoofers were lurking around every corner.
Now, of course, people have done a complete 180 and realized that the encryption is the important part, and the identity verification is at best a distant secondary or even tertiary concern. Identity verification doesn't significantly add anything to end-user security; the avenues for phishing and other malicious uses of the web rely on a general public so technologically illiterate that prominently-displayed identity verification is probably several hundred steps down the list of the top thousand things you can do to protect average users, if it even cracks the list at all. Which is probably why all the prominent identity display stuff seems to be phasing out in browsers; the vendors have recognized that it doesn't contribute useful additional security (and some notable cases have shown that it's easy enough, if you want, to spoof even "verified" identities).
Once upon a time, "using the Internet" meant shared-medium Ethernet, and the only choke-points were things like routers (too stupid to be nefarious) and ISPs (who were too busy).
These days, nearly everything is star-topography, and one of the biggest potential bad actors (the NSA) gets Internet backbone ISPs to silently do their bidding.
Sure, phishing is still a thing and identity verification doesn't solve that, but at least promoting it requires continual, repeated effort. You can't just add a black box to a network closet somewhere and come back a week later to pick up all the intercepted data.
This gets us most of the benefits of standard certificate pinning without coupling us to any specific private key or certificate vendor.
The theory is that it’s hard(er) to fraudulently get an EV certificate issued, although—having gone through the process—it does not strike me as super secure against a determined adversary.
I don't think there's much advantage in knowing that you're some registered organization. It's pretty easy to register an organization - see e.g. https://stripe.ian.sh , to which the CASC responded by proposing the rule "Applicants that have been in existence for less than 18 months are not eligible for EV certificates," as well as a requirement that the CA inspect your tax returns to make sure you're a bona-fide business. This is basically a losing game (losing for the CAs, because it won't work, and losing for the world, because startups can't get EV certificates and everyone else loses their privacy), hence my comment about validating that you're a morally upright website. It's the evil bit, except as a TLS extension.
One thing that does have value, though, is making sure a website is the right website. It's perfectly fine for https://stripe.ian.sh to have a cert as long as they don't get my https://stripe.com credentials or cookies. On the cookie side, the browsers already solve this with the same-origin policy, so the hard part is just making sure that you don't enter usable login credentials on the wrong website (i.e., preventing phishing, which is the stated goal of CASC). There are pretty good solutions for this like FIDO/FIDO2 - in the future I'd like to see places like banks either giving you U2F security keys or letting you bring your security key in when you enroll for an account and activate it on their machine, because the FIDO protocol lets the security key participate in the same-origin policy. If I've enrolled my key with bankofamerica.com, and my login requires using a security key, I can't divulge usable credentials to bankofamerica-secure-login-trust-me.com.
Relatedly, the same-origin policy doesn't (and can't) distinguish between the type of HTTPS you have or whether there's a verified organization name on the cert. It treats any HTTPS for the same domain as the same origin. So the browser makers have been pushing back against meaningful distinctions between DV, OV, and EV (and also against EV even having any costmetic distinctions), which is completely at odds with the CASC's strategy. Sucks for the CASC because it means a $0 Let's Encrypt certificate is as meaningful as a $300+ EV certificate, but I think the browser makers are right, here.
If you can count on a prior relationship in encryption, then you don't even really need PKI. Just mutually decide on an encryption key and then use that to encrypt/decrypt your traffic.
Not every website is Twitter or Facebook or Google or a major bank, where the vast majority of visits are repeat visitors. I run dozens of websites, and every single one has more than 50% new visitors, year in and year out. That is representative of the vast majority of websites out there.
Browser makers have dramatically shifted their security focus toward repeat visitors. Two-factor authentication, same-origin policy, HSTS, and other new security features are only useful for repeat visitors.
EV certificate notices (the "green banner" in the address bar) are one of the very few browser features that attempt to help first-time site visitors. Now, obviously EV certs have problems as you cite with Stripe... but instead of trying to solve this problem, browser makers are simply copping out and falling back on a posture that HTTPS just means encrypted over the wire, not identity. Essentially: establishing security is the user's problem. Once it's established, then we've got all sorts of tools to maintain it.
This is a mistake. It does not help most websites, and it privileges incumbent services (which have lots of repeat visitors) over new websites (who are trying to win new customers).
CAs and browser makers must continue to attack the problem of trust on first visit. It's not an easy problem but it is the essence of the promise of the web. Visitors should be able to load a new site and know if it is trustworthy, just like people trust that they can physically walk into a new store and not get robbed.
But seriously, I think that's the actual answer. The only way you find websites is by receiving a URL from somewhere - whether that's from a search engine, or from a link on some other website, or from non-web means like a paper advertisement or a billboard. And the PKI does solve the problem of bootstrapping trust from a textual URL. (And to be actually fair to Google, they've HSTS-preloaded the top-level domain .app, so any website inside .app gets HSTS from first use onwards - which seems like the right way to solve the problem of URLs communicated aurally.)
To solve the problem of "Am I on the right website," the concept of "right website" has to be well-defined - which generally means you have to already know of the existence of some right website. The UX problem in security is how to take advantage of that knowledge, e.g., not let a Bank of America customer click a link in a phishing email that doesn't actually go to the website they previously signed up with.
The alternative is that some committee like the CASC determines which sites are morally upright and worth anyone visiting, and which ones aren't. That solution works okay for physical sites, more or less, but applying it to the internet generally doesn't produce good outcomes.
Personally, I would not be opposed to CAs requiring proof of cyber insurance in order to issue an EV cert.
If someone is offering that today, they aren't marketing it well. And again, actually signing the certificates would be a negligible part of the business (or the cost).
Actually, if I were in the insurance business I'd actually think about pushing this direction. If you could get the browsers to sign up for giving it special treatment it would probably greatly increase the size of the market. (Right now operators seem to mostly just escape significant liability for compromises)
The human who may be sat at a PC using, say, a web browser, can contemplate anything they like about a certificate and, in principle has some very sophisticated tools at their disposal, for example a human _could_ read the name "Fun Co. Jurassic Toys Inc." in the Subject O field of a certificate and think about a TV documentary they saw last week which said this company was run by a convicted fraudster from Spain, and that might colour their opinion of the web site they thought was a legitimate discount airfare company named "Cheaper Flights" they'd seen recommended on Facebook. They might ask their IT literate nephew Steve, "Hey, Steve, one moment, does this site look dodgy to you?" and end up not giving a criminal $850 for tickets to San Francisco that never existed.
All trusted certs, including DV certs, allow the software to do all its checks, in real time, as it proceeds. When you submit a form by pressing the "reply" button on Hacker News to insist I'm wrong, your browser will insist on verifying that it is posting that reply to a server which has the appropriate credentials for news.ycombinator.com before it transmits the reply, not a minute afterwards when it's too late. This simple, entirely automatic, verification is the only way to make it painless enough to actually get used. Any security strategy that says "And then obviously the human operator does X" is from a dreamworld unrelated to ours, a world which also has no drink driving, nothing is ever left in the back of a cab, a world where the pencil eraser was never invented.
If the browser vendors had wanted EV to have a practical impact on the actual security, rather than just the cosmetics desired by the CA industry's sales people, they'd have instigated a more complicated origin policy, but they intentionally didn't do that.
If your situation really is that your sites mostly attract visitors who genuinely had no previous connection, nothing we can do fixes the actual problem, you are asking merely for theatre, which will cost you extra money, in the foolish belief that conmen aren't going to also put on a show, and probably a better one than you, if it makes them money.
The two groups are the major public Certificate Authorities and the browser vendors. The browser vendors wanted better quality certificates, to improve the trustworthiness of HTTPS (and thus of their products), the CAs wanted to push the higher-priced certs they were offering which included Subject fields like Organisation name by augmenting the browser UI.
The immediate result was EV (Extended Validation) certs, the CAs would promise to do a better job checking the identity of their subscribers before issuing these certificates (and so would charge a premium for them), and the browser vendors would mutate their UI to show the new "green bar" with the organisation name highlighted if the certificate was made to EV standards.
The side effect, and larger long term consequence was the formation of a standing meeting between the two sides, the CA/Browser Forum or CA/B Forum which now sets baseline rules for all "SSL certificates".
Over time browsers have used CA/B to improve those rules, the Baseline Requirements so that the cheapest certificates are more fit for purpose, and so in effect they got their original goals achieved for all certs - practices like issuing for non-Internet names, or issuing without SANs, or without EKUs have been driven out, and today the DV cert you buy for $5 from a reseller (or get at zero cost to you from Let's Encrypt) has a more solid basis behind it than the certs people were paying say $100 for fifteen years ago. They also got the CA/B to behave transparently, you can read most of what it discusses, as well as all votes and documents on a public website, no more meetings in (metaphorical) smoke-filled rooms.
OV requires users actually open the certificate (assuming browser support), hit "details", then scroll down to the Subject section. Then, if there is an O= section there, you can read the Organisation name. That field is missing in a DV cert.
The CA industry wants us to believe the average user does this regularly, in order to determine trust in a website. It's absurd.
Are you suggesting that they both verify the same thing (that a particular legal entity is the owner of the cert, verified by a certain CA), so convey the same security-related information to a client... but with one of them, you pay extra to a CA to get a name in the URL bar?
If the browsers aren't getting a cut of this fee to have _their_ software put someone's name in the URL bar... they're really missing out! It's browser software that's providing the "value" to the person paying the fee, but the CA apparently obtaining the fee, and none of it seems of any value to the user... what am I missing?
I hadn't realized the cert market had gotten _this_ screwy.
I believe that the CA/Browser Forum has extensive documents on what passes for EV (and, notably, you have to be a registered business/organization for EV), and the only rule for OV is that you have to "implement a process" that makes sure you have "verified" the information but doesn't care how stringent you are, so in theory the "extended" part actually means something.
What the browsers wanted was for all the Public Certificate Authorities to get their shit together and do a better job.
They met and discussed at length how both sides could get most of what they wanted. The immediate results were twofold:
1. New versions of popular browsers (all for desktop operating systems because this is over a decade ago) added the "green bar" showing the Subject Organisation for certificates which met some agreed criteria.
2. The Commercial CAs all agreed to obey these "EV SSL Certificate Guidelines". https://cabforum.org/extended-validation/
This is a pretty good deal for the CAs, they get a new product they can sell for a premium price, the browsers do a bunch of extra engineering work. Many feared this was creating a something like a treadmill, they predicted that soon "EV certificates" would be cheapened and a new "Even more Extended Validation" would be needed, with correspondingly higher prices just to get back to reasonable trust and the cycle would repeat forever.
But there's two unexpected consequences. Humans like socialising, so the meetings continued, the CA/Browser Forum standing meeting is now important across the industry and it set not just these "EV SSL" guidelines but eventually the Baseline Requirements for all "SSL certificates". https://cabforum.org/baseline-requirements-documents/ Also, desktop browsers ceased to be as important because everybody now owns a mobile phone, and the quite different UI in a phone browser lets them reconsider what is important. An Android phone doesn't show Organisation info prominently, just the domain name.
So in the end mostly the browsers got what they wanted more than the commercial CAs. The CAB BRs have allowed them to gradually tighten things up, the treadmill runs in reverse - so that today your $0 Let's Encrypt cert is produced under more stringent conditions than were needed for the $$$ Extended Validation certificates from 2007, and the EV UI is less important though it still exists in popular desktop browsers.
Fixing the problem is arguably better for at least two of the big browser vendors than just getting a cut of the money, that is Mozilla and Google. Both need a trustworthy web, Mozilla as part of their charitable purpose, and Google as a direct need of their business, so for them improving DV over ten years was much better than making a few grand off the higher priced certificates AND it avoided the inevitable conflict of interests taint.
Did "OV" exist at the point you are talking about, more than ten years ago, that "EV" was solidified?
If not (I literally hadn't heard of it until now), it seems like the "treadmill" has worked in a different way, filling in the market underneath with a cheaper "OV", which it's unclear how it's security assertions are any different than EV, it's just cheaper (and it doesn't get a name in the location bar). I'm not sure this is helping the security landscape.
In the mid-1990s, the Netscape Corporation invents SSL so that their web browser ("Netscape Navigator") can offer secure encrypted web pages, a huge innovation that will make it possible to do things like sell stuff on the Internet.
They find out that basically there's a problem here about who the hell you're communicating with securely, and one obvious option is that Netscape sets itself up to make this decision. And the problem is that obviously competitors won't accept that, and so either the Web gets balkanized or nothing ends up secured. Also Netscape would need a whole new division to bootstrap this whole identifying web sites and proving their identity problem.
However, the X.500 directory system already has an associated system of certificates X.509, and some fairly serious-sounding companies are minting such certificates, so Netscape picks some of those (names you're familiar with today like Verisign and Thawte) to offer certificates for their new Secure Sockets Layer encrypted web.
The X.500 system envisions a single global directory hierarchy, countries are at the top (e.g. C=GB - the United Kingdom of Great Britain and Northern Ireland) and under those are States, then Localities, and Organizations, and Organizations have Organizational Units under them, one vast all-encompassing tree, envisioned by technologists but never actually realised.
So, SSL uses X.509 certificates, and those have X.500 directory names for their subjects, but no such directory really exists, and so the Certificate Authorities write whatever seems roughly correct into the certificate, or they check what an applicant wrote, and if it seems OK they just sign that.
At first then, the certificates are what we'd now call OV because there is no other kind of certificate.
But there's a pressure on the Certificate Authorities to drive more revenue, and making more certs at a lower price seems easier than persuading everybody to buy a $500 cert. So they invent "Domain Validated" certificates. You write the Fully Qualified Domain Name into the X.509 "Common Name" human readable field, and then you write "Domain Validated" in fields like Organizational Unit, and it looks pretty much OK in Netscape Navigator or the shiny new Microsoft Internet Explorer web browser, but instead of needing make international phone calls and own paper business directories for foreign countries now you can just send an email to like "firstname.lastname@example.org" and call it job done.
And it kinda, sorta works, and there are other more pressing problems like making dynamic HTML work, so the web browsers mostly just let the Certificate Authorities carry on doing whatever seems best to them... for a while.
I really don't think that's true, purely by thinking about the number of iOS jailbreaks that have been published recently Vs the number of browser exploits.
Security is part of the reason Apple charges like it does, but it is only part and I'm not sure the distinction between the Chrome and iOS sandbox is much of a factor.
Email/GPG has services like keybase, Instagram has verified accounts, WhatsApp does too. Even bloggers who dislike checking organisations for certs (EV) do so from verified accounts - though Twitter mistakenly tried to tie it to both noteworthiness and ethics, which they're now trying to fix.
The entire concept of encryption presupposes that you care who you're talking to. If you don't, then why not just broadcast your message in the clear?
Of course using authentication is vastly superior, but lacking it doesn't render encryption useless.
* I mean if your business is online banking then it's a little different. But for 99.9% websites out there having EV isnt necessary.
A MITM attack requires more work to pull off.
The rest of this is correct, but nobody is asserting EV means you're good, just that it means you are whoever you're verified to be.
I.e. your cert has an Organisation field of 'Verified Org Inc' rather than a blank item like a DV cert has.
DigiCert still very much supports EV, they just don't like how CASC is planning to do silly things like require you to be in business 3 years before getting verified.
The Mozilla Foundation on the other hand takes these decisions in public, m.d.s.policy is the newsgroup for security policy decisions, which ultimately mostly means stuff about SSL/TLS and these certificates.