I revoked $1M worth of EV certificates
scotthelme.co.uk
scotthelme.co.uk
"One thing that we can do with CT logs is search all certificates for things that we're interested in"
The CT logs themselves implement only a terribly simple API and you can't search them per se. This makes good sense because they are required to hit really onerous availability and performance targets to remain "qualified" as logs. You definitely wouldn't want to put a sophisticated "search" feature in this code.
However, since they're public we can either read all the data (my employer does this) and process it however we like or there are two famous services which already did this for you, crt.sh (operated by Sectigo, one of the CAs) and Censys (from an ex-University of Michigan team). Scott used Censys for this article, and either Censys or crt.sh are good places to play around with this if you have a passing interest that may not last.
To add, I like the checks of https://sslping.com/ too.
The other big data points being: browsers don't want to display them differently, and users don't notice them being any different.
Now we have that nobody is really checking them that closely.
How much longer will these even exist?
Max length of a certificate is 2 years, so probably 2020. Maybe 2021-2022 if you count stragglers and businesses that are locked into long contracts.
I fought with Name to get them to reissue it, they wouldn’t. I decided it was time to figure out how to setup Let’s Encrypt. They lost me as a customer, and I’ll likely never buy a certificate again.
EV certs are still useful for code signing. At least on Windows UAC warnings look differently if binary is signed with EV certificate.
Windows is my daily driver, and I'm security-minded - yet I haven't noticed different colours for UAC dialogs depending on signature type. I notice if it's not signed at all, of course, but otherwise... no?
I would imagine most typical end users are the same. Similar to how browsers are not actually, where they make it really obvious if a site doesn't use TLS, otherwise it all looks the same.
https://cabforum.org/ev-code-signing-certificate-guidelines/
Whereas for the Web PKI (things that do SSL/TLS, including most obviously HTTPS on the web) there are both the baseline requirements for every certificate:
https://cabforum.org/baseline-requirements-documents/
and EV for adding "extended validation" to that:
https://cabforum.org/extended-validation/
It's kinda useless to have a certificate that says this program is really named "Great Calculator". Oh yeah? So what? Whereas a certificate that says it's from "Microsoft Corp" in "Washington, US" at least tells me whose fault this calculator program is when it wrecks my PC.
On the other hand, knowing this is really https://news.ycombinator.com/ is kinda good because the machine can (and does) automatically check that this matches on every single URL resolved, every image, every HTTP POST, everything.
I had to give them a published telephone number for a callback. I don't publish a phone number, so I setup a Skype Number and published it in a free Yellow Pages kind of site - they did a callback, which obviously totally proves I work for Acme Stuff, and then I removed the listing and Skype Number.
I recall there were a couple of other bits of theatre I had to endure, publishing information on random listing sites that don't do any validation of their own, but I don't remember exact what.
For example they would lack the 1.3.6.1.5.5.7.3.1 EKU which says their purpose is to identify an SSL/TLS server.
The market for these certificates is pretty different from the Web PKI market.
‡ When they're issued by a CA which would also be trusted in the Web PKI some requirements cross over because of that, particularly Mozilla wants to be sure that certificates issued under these hierarchies are never "accidentally" valid in the Web PKI without obeying its rules.
EVs will soon be gone when browsers stop recognizing them. We are already well on our way there. From the same author from a month ago [1]:
> Both Google Chrome and Mozilla Firefox have announced that they plan to move the EV indicator out of their main UI.
1) hardfail on revocation checks 2) you can't get around any errors generated by an EV 3) you can't fake them by truststore manipulation (except ie and maybe edge) as the ev roots are hard compiled into the browser and not dependent on the external trust store.
Validation would have been a 4th reasons if it wouldn't be for all the obvious problems with it especially lately.
The problem is what people imply or are made to imply from different cert types.
Back in the day people were told to just check for the lock, which obviously is dumb considering now everyone can get a dv for free.
Then with EV CAs told people that sites with ev are more trustworthy. Obviously nonsense considering the excluded usages of EVs in the cabforum documents. EVs are only supposed to make a hard link between an offline and online legal entity, and even that failed with stripe.ian.sh (although that's not exactly the fault of EVs)
EVs now get so much higher implied security that the real vs implied security ratio is obviously very ugly while DVs becoming standard obviously have much more real security than implied (if people check the urlbar correctly)
That's the only thing that matters, really.
The selling point of EV certificates is that (1) they are very visible in the browser and (2) users care enough about that to make a difference to your business.
I haven't seen any surveys or A/B testing results about (2) but since (1) is no longer true this is moot.
It means you should just go for the cheapest certificate, which means free nowadays.
Chrome no longer displays EV certificates differently, I believe, that about 2 thirds of the market.
The second thing is (2) is my previous comment: Even if an EV certificate is displayed differently, does anyone care? Does that impact my business to make it worthwhile?
The general public could not care less, imo.
Everybody rails on how useless EVs are, yet it seems like no browsers have spent any time over the past years even trying to improve the UX related to certs. I mean, sure they’ve changed the color and removed the ambiguous company name and country. Which makes you ask why did they ever display country in situations where that isn’t the jurisdiction that issues business licenses, such as in the US?
I mean, click on the lock and through N buttons, then expand various sections and read through dotted identifiers that only ASN.1 experts recognize (seriously, who though it would be a good idea to use OIDs for known fields in the UI?), and then maybe you’ll understand who the certificate is issued to.
At least in the US, when obtaining and EV cert you need the jurisdiction (state), business registration number, they call the business phone number. They basically do some research - usually you need a DUNs number, publicly listed phone number, etc. Wouldn’t it make sense to have a button that when you click it you see a user-friendly window showing the information about the company for OV/EV? I mean, sure, you can register Stripe in a different state - how about providing some statistics like what year the company was formed (usually only file with business registration), a link to the company registration details on the jurisdiction website, the top level domain Whois info, etc? If you wanted to get fancy you could provide a link to the user’s search engine with the company name as the search terms.
Instead it seems like we have a bunch of cryptographers (or maybe just infosec people) obsessed about 1. The money companies are charging for EV certs 2. that it is possible for mistakes to happen. This instead of improving how we present information about a company.
So since there isn’t a perfect, foolproof identity verification system for companies online, now every user online needs to do their own reconnaissance to make sure this is really the website they should be at.
Research suggests they don't do a very good job at that.
There's also the point https://stripe.ian.sh/ made: it's not just about registering the same name in a different state. People don't know in what state your (parent company) headquarters are so they would need to dig deep into the organisational structure to find out if the EV cert they're presented with isn't from a company with the same name in another state. Want to add more years of registration? Just buy an old, probably no longer used letterbox company and change the legal name. Whois info can be set to anything you want for most domain registrars as well. People will still need to find out if all the data matches.
There's also this demonstration of how EV can actually be used to help phishing by using the "green address bar" and the hilariously stupid Apple address bar design: https://www.typewritten.net/writer/ev-phishing/
I believe there is value in EV certificates if you can rely on the identity verification that they come with. Sadly, most providers of EV certificates seem to view them as a way to make more money, not as a tool to bring trust to the web.
An EV-like system will probably be reinvented in the future, giving us a fresh start on identify verification on the web without the crappy practises and standards that plague the EV system today.
Lastly, for such a system to work, all (big) companies need EV certificates. Even before browsers started cutting back on EV UI, nobody knew what site does or doesn't have EV. Some subdomains used different certificates, some didn't have certificates at all. How do you know if a (sub)domain is supposed to have an EV certificate? Will you tell people to just not log into Facebook anymore because they don't have an EV at their login page?
EV doesn't work because it's the wrong way around. For security indicators to work, you need to warn for danger instead of turning off the "everything is okay" light. The OV/EV system has been designed around the latter idea and as long as EV/OV isn't freely available all over the world, nobody's going to mark DV certificates as "insecure".
The identity problem is always fun. I mean i don't care who someone is in real life, i only wanna know whether i have the site by the same individual who made something else.
That can be easily and automatically verified (see keybase) and might be more than enough for a lot of things where there are only normal people involved.
It might also be helpful of a given company is more commonly known behind another online entity. Like for example if pewdiepie had a company which he uses for what he does, the link to his yt would be a much greater indicator of validity than some random company name or even his own real name (which not everyone may know).
For pure DVs i think they should be able to issue them themselves. I mean the only thing those prove is domain control and with dnssec+tlsa there's a great way that domain owners can prove that they are in control of the domain and aurhorize a cert, also this lowers the number of trust paths significantly as there is only one possibly trust path over the TLD, and not like 150 CAs from who knows where. Also both the domain owners and the users have less entities they have to trust, as the TLD managers have to be trusted anyway as they ultimately have the full control of their domains,and thereby could make a DV cert themselves over the CAs anyway.
They’re actively making them worse, actually. I can’t even view the details of the certificate chain in Chrome on iOS. I used to be able to save them from the browser on a computer, and now I can’t do that, either.
Microsoft also has a CA.
Apple has EV and Amazon uses DigiCert, which is the only one that may be domain validated, perhaps.
Several (all?) of them are domain registrars and so they would be able to rely on that to shortcut issuance validation for names in domains for which they are both registrar and owner, but it still happens it's just easier.
All of this sounds like very familiar data entry and maintenance problems.
In general, good data quality can only be achieved by giving the people who enter it some incentives, or make it impossible to enter wrong data (then data can still be missing).
For example, we have automation that configures monitoring and backup for hosts from our CMDB, and this information tends to be well maintained.
Other information that we need e.g. for compliance, but that no automation is tied to, tends to be of much less quality.
The second part is the feedback loop: if you enter some data incorrectly, and weeks or months later somebody complains that it's wrong -- that's too far off to efficiently learn from it.
We as an industry might have expected better from CAs, but we haven't pressured them into building the necessary feedback loops, or indeed given them incentives to provide higher-quality data in the EV certs.
Part of this is probably the fact that many people were opposed to the entire concept of EV certs as basically being a money grab by the dominant CA's from day 1, and indeed the trend is away from highlighting their existence in web user agents...
Years ago the certificate was a big deal in project specifications, project managers could lay out the FUD and trick clients into spending more money on more snake oil. This was a pain for developers as they would have to get the work done. Sometimes the client would not have access to the one or two email boxes needed for this archaic system so there would be an added hurdle of setting up info@example.com or whatever it was that was needed to get EV to happen.
Nobody misses those days and the pain and hassle just was not worth it. Certbot came along and made it so easy. Nobody questioned why they needed EV certificates, sometimes you cannot argue with free and easy.
Should there be some formal/official mechanism of auditing _every_ EV issued?
Perhaps cert authorities should be required to pay for an auditor to audit their certs -- not just the process or a sampling of certs, but automated auditing of every cert. The problem with this of course is the usual 'auditor capture', if the auditor is getting paid by the entity getting audited, the incentive is not to continually approve the auditing, but to make all the audits pass.
In some sense, this is a success story -- the transparency of the cert issuing log allowed the OP to choose to audit some of them, voluntarily. But transparency of the cert log clearly isn't enough, it's been years of bad certs before someone decided to volunteer their time to audit some of them. Just transparency isn't enough without social/business structures in place such that they actually _are_ being checked.
(This has parallels/analogies with other things...)
this is what Extended Validation is supposed to mean in the first place.. and lends credence to the argument that EV solves a problem that shouldn't exist to begin with for 'regular' certs
EV, in contrary to ordinary certs, is supposed to mean the cert authority verified the registrant really is the name on the cert. Ordinary certs the CA doesn't even claim they did that, they don't even claim that a Cert that says Joe Smith on it was registered by someone who's legal name is Joe Smith or a cert that says Widgets Inc on it was registered by a company with that name. The CA's are claiming to do a different thing with EV certs.
I am talking about a third-party auditing the EV certs to ensure the CA was doing what they committed to do. Like a third party audits a bank by analogy. The fact that banks get audited doesn't mean the bank is useless in the first place. But the auditors do (theoretically if the system is working) help keep them honest.
One of the points of the transparent log is to make this possible. But if nobody is actually checking... it is not quite accomplishing this point. The fact that a transparent log is a good thing so someone can audit doesn't mean the EV is "useless in the first place".
(An EV might be useless in the first place for other reasons, but not because auditing is a good thing).
Maybe a better title would be, "Humans not 100% reliable about ensuring accurate information stored within thousands of data records, despite such accuracy kinda being the whole point."
[0] https://www.isc.upenn.edu/alerts-outages/planned-weblogin-ss...
Is it really worth revoking these over tiny discrepancies, especially in cases where you can still determine the entity beyond a doubt?
There is CT logs of course. Even if the certs were issued by error or fraud, they must still be included in the log. There must be automated processes scanning these logs and validate the certs (x509lint, cablint, zlint, etc).
I suppose you can check CA CRLs or combined CRLs like Mozilla OneCRL to find recently revoked certs and lint them to see if there were issued with errors.
A signed certificate that contains invalid or incorrect data is considered to have been misissued according to the CA/Browser Forum's Baseline Requirements [1]. Misissuance not only obligates the CA to quickly revoke the certificate upon discovery, but also frequently leads to discussions in places like Mozilla's dev-security-policy mailing list. [2]
If you follow some of those discussions, you'll quickly see that browser vendors hold the CAs to fairly high standards. Blaming a misissuance on a "data entry error" is generally not considered sufficient or acceptable; they're expected to be able to explain why the errors were not caught by technical controls or verification processes, and how those defenses can be improved to prevent the same errors from recurring.
[1]: https://cabforum.org/baseline-requirements-documents/
[2]: https://groups.google.com/forum/#!forum/mozilla.dev.security...
Say for example that you have an online store. Then the local tax-office could sign your certificate if you are a registered company in that country. If you have a contract with VISA, they could sign your certificate. The authority for your top-domain could also sign the certificate to prove you own the domain and so on.
And for a customer buying from this store, seeing these badges in the browser would let them decide how trustworthy the website is. I actually think with this solution getting the users to understand would be the least problem. The big problem would be to get developers to authenticate the certificates while doing back-end calls. I mean how many developers even does this today?
Given that a non-technical user can't tell the difference between an EV cert and a regular CV, I can't understand why they would care about the actual number of badges. Sliding scales just don't work, they just care about whether it's safe to use a website or not.
The browser vendors _could_ establish a baseline for the number of badges that would make a site acceptable. But the economics would have to match real world incentives (e.g. small and large businesses), and protect against problems like sybil attacks...but then we're back to the heart of the problem.
I really don't see why having a Danish number in a Swedish registered company is a big deal.
The phone might simply their contact for whomever is responsible for the certificate and it might be possible these contact is in Denmark.
I mean if it was a Canadian company with an US number and most likely they wouldn't even know.