The Power to Revoke Lies with the Certificate Authority
scotthelme.co.uk
scotthelme.co.uk
https://www.troyhunt.com/on-the-perceived-value-ev-certs-cas...
Also, unlike apparently everyone else, I care who I'm communicating with, not what their domain is.
Visit https://certsimple.com from the UK and you'll even see the UI change to remove the DBA option.
Trademarks aren't the same thing as DBAs, but a number of folks would like to get the EV guidelines extended to include trademarks.
If the EV badge identifies a legal entity plus its country of origin, then how is it supposed to be the CA's fault that there's this leaky abstraction of multiple legal entities with the same name in the same country? If we have a good idea and a poor implementation, then the correct response is to fix the implementation, not throw out the whole idea as fundamentally broken.
Unfortunately, there's also not much that the CAs can do to fix this by themselves. If we want to have a digital representation of a legal entity's identity, the best way to do that is to have a first-class digital identity rather than the hack of a system we have today which attempts to create a poorly supported, non-portable identity on the basis of emailed paperwork and phone calls. Such a first class identity - with private keys controlled by the legal entity, entrusted to the entity when it was first created - will allow clients to verify the identity against the source which actually governs it.
I can understand the privacy concerns surrounding the creation of legal digital personal identities - the creation of a definitive population ledger that goes along with it etc. But for companies? That the US doesn't have such a solution for companies in this day and age is just myopic.
PayPal, Inc. # Street: 2211 N 1st St # Locality: San Jose # State: California # Postal Code: 95131-2021 # Registered: Delaware, US
And we could include other information if we needed.
For PayPal this number is 3014267 and it'll be their registration number with the state of Delaware.
The EV rules require a CA to figure out if there is such a number and if so fill it in on the certificate. If there is no number, they're supposed to write something else (a registration date maybe? I don't remember)
(Sometimes a country has some companies that are so crazy old they pre-date the idea of registering companies, or turn out not to exist in their company register because the country created them by passing a law instead of formally registering them, or whatever, and these don't have serial numbers, e.g. I wouldn't be surprised if the Bank of England has no registered company number)
a) not all CAs will present enough distinguishing data to the client. Case in point: "Stripe Inc. [US]"
b) No consensus between CAs as to who will issue a cert for a given legal entity. In other words, there is such a thing as a CAA record for DNS and DV certs, but no such thing for EV certs and therefore no verification flow of for a given legal entity -> which CA is permitted to issue -> which domains have been certified for that legal entity
c) No support for more complex identity usecases including name changes, subsidiaries, brand licensing (this FedEx-looking site is run by Acme Local Fulfillment Inc. which has been licensed by FedEx to use the FedEx brand), etc.
Certificate Authorities are not in the business of establishing identity and so they are fundamentally doomed to doing a poor job of verifying identity. Instead of trying to coerce CAs into the identity business because of the inflexible and glacial pace at which government moves, we should be pressuring government to adopt more modern identification practices.
(b) Why is this a problem?
(c) Is there any evidence of demand for those usecases? How would you even present them to the users in an understandable way?
"Certificate Authorities are not in the business of establishing identity and so they are fundamentally doomed to doing a poor job of verifying identity."
I don't see how that follows. In fact, I don't see how that's even possible. Whenever you do business with any entity besides the national registry - be it a bank, insurance company, notaries, or even another governmental department - they have to verify your identity. CAs just happens to give you a digital affidavit of the results.
Instead of trying to coerce CAs into the identity business because of the inflexible and glacial pace at which government moves, we should be pressuring government to adopt more modern identification practices.
I disagree; we already have problems with too-big-to-fail CAs; governments are even worse. A CA can be told "follow the CAB Forum rules or get kicked out". But you can't distrust a government when they're the only issuer for the sites of the whole country.
Low-coupling is not just good in software development.
The point is, nobody wants to fix it, because CAs are still making money.
Briefly, I'm going to focus on just one of these. I leave it to the reader to spot the others.
Ian Carroll got an Extended Validation (EV) for Stripe in another state to prove that EVs are forge-able. That is, although he followed the guidelines, he believed those guidelines weren't enough to safeguard an EV.
Then when the Certificate Authority (CA) finds out about this and revokes his deliberately misleading EV, Scott Helme writes the article linked accusing and detailing how CAs have too much power, because they can revoke an EV based on arbitrary decisions. He defines arbitrary decisions as "not following the guidelines".
To summarize: Ian Carroll abuses the guidelines to register a deceptive EV to prove that the guidelines aren't enough. Then Scott Helme accuses the CA of not following its own guidelines and of taking an arbitrary decision to revoke Carroll's abusive certificate.
They just can't win.
There was no forgery.
If there were any abuse or forgery taking place here the certificate would have been revoked for those reasons and the CA would be held to account for mis-issuing a certificate. That's not what happened.
Given the name of the account that made the comment I'm curious about the affiliation of the author, perhaps they would share that in the interest of transparency?
Does anybody trust an EV cert more than a DV cert? It's hard enough to get the average person to check for the green padlock before they enter their password, how can we hope to convince anybody to check the company details in the certificate?
I first noticed that it wasn't intercepting my connection to my bank, and then after some experimentation, that turned out to be the pattern. Sounds stupid, but there you go, somebody uses EV as a signal for something.
As it turns out it appears to intercept everything except connections to major high street banks.
These days I can't be bothered to circumvent. If I want to do any sort of sensitive browsing at work (e.g. online banking) I just tether my laptop to my phone.
I really wouldn't care for a web shop etc.
EV certs are currently the cash cow of certificate authorities. If you'd take away EV certs it would become apparent that there's no valid business model for CAs any more.
So the whole CA industry kinda depends on keeping the illusion that EV is a valid concept.
With the EV certs, you can be assured that it actually belongs to the company it claims to belong. If I see "PayPal, Inc. (US)" in the address bar, I'm sure I'm accessing the correct server. However, I didn't really know that business names are not unique between different US states, but I assume this is not the case for other countries.
The issue with EV certs is how they are presented in the browser, since they are indistinguishable to the ordinary certs, at least to the majority of the users.
Uniqueness of business entity names is something you should never ever assume or rely on.
I think the current look was updated later.
now stripe could take this up with the courts about how ian is confusing consumers and so forth, and they would win. but they didn't - they went straight to the CAs, and the CAs folded on an arbitrary rather than legal decision, which is a little concerning, but also not too concerning. the CAs were probably were just alerted to the fact that ian was running a website in an obvious bid to confuse people, and decided to revoke his cert. and honestly I think that's a fine, reasonable response to what ian did -- to help protect people from fraud. what wouldn't be a fine reasonable response is to do the same if he were in fact doing real business as a different stripe with non-confusing logos in a different market, not trying to look confusing on purpose.
there's no reason to be worried about having your legitimate cert revoked because of things like this, just like there's no reason to be worried about having your legitimate website kicked off cloudflare because of daily stormer. ultimately his point is that if EV SSL can do this, it is shit, and on that I agree.
Is there any evidence that Stripe had anything to do with this?
Bullshit.
It is utterly insane to accuse him of running this page in an "obvious bid to confuse people" https://web.archive.org/web/20171211181630/https://stripe.ia...
It is also utterly ridiculous to describe this as "helping protect people from fraud". There was no fraud.
>there's no reason to be worried about having your legitimate cert revoked because of things like this, just like there's no reason to be worried about having your legitimate website kicked off cloudflare because of daily stormer
FWIW I've had my website kicked off Cloudflare and countless of domain names suspended because a SF BigCo hired an very big international law firm to keep my site offline at any cost.
I wouldn't put it past them to try and get certificates revoked too, but they tend to be able to put out enough pressure to get the domain names suspended pretty fast.
(My site sells legally scraped public data from that BigCo's website, instead of suing me they prefer to just keep my site offline)
Scroll down a bit on that page, and you'll see this image: https://web.archive.org/web/20171211213402im_/https://stripe...
Maybe that page was updated later in the day, but before the Web Archive captured it.
https://crt.sh/?id=393002115&opt=ocsp
Just compare the revocation date and the archive.org date. At best they revoked the cert after it had been used to serve a completely different site for many months.
And what about this? https://stripe.ian.sh/firefox.png
no, not bullshit. see the screenshots in this thread and the tweet in the post itself where the two stripe sites are compared side by side. making a "look how useless EV SSL is" site through a phishing example isn't a good strategy for maintaining an EV SSL cert, clearly. he was practically asking them to revoke it, and they gave him what he wanted.
> (My site sells legally scraped public data from that BigCo's website, instead of suing me they prefer to just keep my site offline)
it sounds reasonable that cloudflare kicked you off, too. you may not be breaking the law, but you're not respecting BigCo's terms of service and you can't expect a red carpet given the nature of the business you're in. seems like an interesting/fun game of cat and mouse, in any case :)
I'd be much more worried about this kind of thing if it were happening to good/neutral actors. but as presented it just seems like the centralized internet doing a pretty OK job of policing itself.
It's not at all clear whether or not the page was ever publicly accessible like that. It certainly doesn't appear that he was distributing the link to the page if/when it looked like that.
https://web.archive.org/web/20171211181630/https://stripe.ia...
https://crt.sh/?id=393002115&opt=ocsp
The site looked like this for at least 4 months until the cert was revoked.
"obvious bid to confuse people" was a pretty harsh accusation, and you have essentially nothing back it up.
>site through a phishing example
Even if he had copied the stripe page, that still wouldn't make it phishing.
Factoring in EV Certs for systems that are scanning the internet and trying to separate things that might need more validation...think news agencies and the search engines or social media that distribute their content. This illustrates both the benefit and the consequence of that model at the same time.
It would be ideal if there were some type of EV appeals committee to deal with revoked certs that could mandate a revoked EV be reinstated in a situation like this.
There is a place where using the EV model of more comprehensive verification can be beneficial...it's just not to the general public in a browser bar.
Ian run a legit site, not phishing, so what's perfect in revoking his EV cert and not giving back cash?
He originally had a site that looked extremely similar to stripe's official website: https://news.ycombinator.com/item?id=16939094
2: PayPal/Stripe do have their one touch/sso stuff, if sign up with to that you'll have at least an indication if things go weird.
Otherwise you are right. It's a problem but it's a problem with the web, not specifically any payment processors which are all honestly doing anything they can to make these issues a non-issue.
Some feel that the correct approach is to whitelist TLDs that have a responsible homograph rule (so, not .com) and show punycode in all other TLDs. Others want to detect whether a name seems "confusing" by some heuristic and show the punycode instead only in that case.
It's not like you can just disable punycode for all sites, because now you just create a new phishing risk for those sites that used it (xn--pypal-something and xn-flge-something look close enough)
Though I don't know that most people could tell you in which state Stripe is registered, even if they know it's probably Delaware. Heck I think a lot of people could look at the state name, say "hunh, I didn't realize Stripe was a Montana company!", and proceed to be phished.
"I found what looks like a flaw in a system but I didn't try to exploit it for real, look how clever I am"
So his mate registered a company with the same name as another company and got an EV cert. Well done. Everyone knew that was possible already, at least everyone who has gone through the process. It doesn't matter much:
1. Ian wasn't actually a phisher or criminal. If he had been, and had used that EV cert to phish Stripe customers, he'd have been reported to the police using the details from the CA and possibly prosecuted. Bear in mind he had to register a company in the USA, not Kazakhstan.
2. Therefore in reality it is very rare for phishers to use EV SSL certificates. Actually I've never seen it.
So is this a demo that the system is horribly flawed? I don't think so. It's rather similar to people who send 10 spams to some accounts they just registered themselves and claim they've found a way to beat a spam filter so the whole thing is useless ... well, no, you weren't actually a spammer so the filter did the right thing. You're testing a flaw you think sounds realistic but isn't. Another common case of this, someone who beats a DRM system on a game 6 months after it was released and then talks about how useless copy protection is, not realising that after 6 months almost all sales happened already so the system worked just fine from the developers perspective.
What about revocation? Is the CA exercising undue control here? Probably not. CAs have language in the contracts you agree to at the time about how you're not trying to misrepresent yourself as if you were someone else. Ian's argument that he registered a name that happens to be identical to a well known payment processor, but in another state, is technically correct, which is of course the best kind of correct. But the underlying purpose was clearly impersonation, which is a violation of the agreements and thus not only grounds for revocation, but to not do so would rather undermine the whole system - why should Ian get away with it when others do not?
If stripe.ian.sh had been an actual operating company that happened to have experienced an unfortunate naming conflict with the other Stripe, I bet the CAs would not have revoked. They'd have found some reasonable solution - probably by letting the cert continue, on the grounds that no malicious behaviour was taking place in violation of the agreements. But it wasn't - it was just a dummy site.
Overall I don't understand Scott or Ian's point. Yes, legal names aren't globally unique. Did anyone think they were? Yes, Chrome's EV UI is rubbish and the big players other than Apple tend to have an institutional dislike of EV certs because of historical clumsy attempts at market segmentation pricing by CAs, that were totally unreasonable for companies with lots of servers. Yes, EV is imperfect.
The alternative though is paypal-customer-centerr.com ... which is better, how, exactly? It isn't.
If Scott Helme or Ian Carroll don't like how EV works today, why not go find actual criminal abusers and propose specific improvements that would stop them - perhaps making Chrome's address bar work more like Safari's. Otherwise this is just another blog pointing out security stuff that doesn't really matter.
Are you _from_ the USA? Or do you believe its propaganda from outside?
You don't need to even be able to point to the USA on a map to set up a US company and do all this paperwork. You fill out a few forms on a web page, pay a little bit of money, American lawyers sort everything else out. They keep some of the money, the State keeps the rest, everybody is happy. Oh, except your victims. They can call the cops of course, but the State obeyed the law, and the Lawyer just does paperwork. It's not a crime to be the lawyer for a crook.
Why don't crooks do this today? Well, there are two answers. For big crimes, stuff like crooked property deals, they absolutely do this already, it's completely routine. For a phishing site they don't bother because it's not necessary. If 90% of visitors to your unsecured http://paypal-credit-checking.example/ fill out the form, and you get that up to 99% by obtaining a DV certificate for it, why spend $500 setting up a US corporation for the extra one percent? But if you persuade everybody EV is great, then sure, that's what they'll do next.
It also wouldn't scale, domains get blacklisted within minutes or hours, getting an EV cert takes longer than that.