PayPal's Beautiful Demonstration of Extended Validation FUD
troyhunt.com
troyhunt.com
I think the far more interesting question is why EV certs do nothing for end users, and why browser makers have not introduced any new features to replace what EV certs were intended to do: help end users understand which websites they can trust on first visit.
The entire Internet industry has absolutely punted on this problem. It's a hard problem, but no one is trying to solve it!
And it is absolutely striking to compare against how well this problem has been solved in real life, at least in the U.S. You can walk into any retail establishment in the nation and reasonably expect to have a safe, productive interaction with a proprietor you don't know--even on the first visit.
It's the exact opposite on the Internet, and it's insane that everyone just accepts that.
I haven't spent enough time in the US to have an opinion about it, but in many places this is not true. For example, taxi services in many countries seem to pretty commonly be ripe for dodgy behaviours with little accountability.
It's really about that accountability - what are you going to do against an internet entity which scammed you? How effective is that action going to be?
Accountability was supposed to be the extra value of OV and EV certificates.
If you look at the cert for https://www.walmart.com/, you see the following Subject fields:
Common Name = www.walmart.com
Organization = "Wal-Mart Stores, Inc."
Locality = Bentonville
State = Arkansas
Country = US
That's what the famous "green banner" in the address bar was supposed to convey--that this website has a paper trail that can be used to impose accountability.
That's NOT a guarantee that the website will treat you well. It is a guarantee that you can try to do something if it doesn't. Even if a corporation is only established temporarily for the purposes of getting an EV cert to run a scam, that still leaves a legal paper trail. DV certs do not.
And this is a standards-based distributed system. It doesn't rely on one company like Google or Microsoft, or one particular browser, or even one particular CA. If Wal-Mart doesn't like GlobalSign anymore, they can go to another CA like Digicert. If you don't like Chrome, you can use Firefox--they can both read this cert information equally well.
IMO it is really a shame that the Internet industry was not able to lean into this concept of accountability. For example, why don't browsers surface this company contact info directly to consumers? The way that a consumer can easily find the street address for a store they visit? Instead it's buried 4 clicks deep in a complicated cert menu. Why don't they supplement it with a link to the corporate record of the company? Or to the Dun and Bradstreet listin? Or to the police department website in the registered locality? (Bentonville, AR in the case of Walmart) Or to the Better Business Bureau in that state?
It just seems like there was been the opposite of innovation into this concept of using certs to provide IRL accountability for websites.
For reputation: I have no idea if that's the company name of Wal-Mart. It's barely better than verifying the domain name.
EV and OV certs are intended to provide similar information. If you report a scam by a website with an EV or OV cert, the police can use the information in the cert to start their investigations. There's more to accountability than small claims court.
Setting aside the cert issue, it's just striking how many people take it for granted that there are no consequences and no recourse for online crimes. How did we come to accept this as normal, as a society?
> How did we come to accept this as normal, as a society?
Probably because it's so much harder to pin down specific actors. That cert only does so much.
Having somebody else do this for you makes some sense, but again it makes sense as part of a whole system dashboard, you care if your site gives 404s to everyone outside the VPN as well.
Bad guys _mostly_ don't start by getting illegitimate certs issued. For the DNS hijack stuff for example, even where a cert was issued we see it significantly _after_ the traces of the hijack are visible. The bad guys lie in DNS and _then_ they might get themselves certs so they can run an HTTPS site, you ideally want to detect the DNS hijack as otherwise you're already playing catchup before the first pager alert happens, and these attacks may last just hours or even minutes, so every second counts.
Without DNS hijack, they're mostly doing phishing, so you won't see new certs for your site, because you know you're legitimate.site.example and not legit-site.example or login-legit.badguys.example. Your customers, alas, not so much.
It used to be that spoofed WiFi and SSL-strip (a program that terminates all HTTPS connections and forwards them as HTTP) would work pretty well for that. These days HSTS should stop most of that.
HSTS has been adopted by the big ones, (e.g. gmail, paypal, lastpass). I'd say these are also the ones where it might work out to drop a pineapple in some NYC coffeeshops. It isn't widely deployed though, so it'll still do some damage. I guess criminals don't wanna do the sleuthing to figure out where they found creds.
It seems like it works by intercepting traffic and downgrading the attacked machine's connections to http. So, your text is correct; it is terminating the https connection "the other way 'round" from the way I first read your text. It's https from the MITM machine to the "real" server, but http from the browser to the MITM machine, rather than the MITM machine being able to terminate the https session from the browser (without a cert error).
Sharing in case that helps someone else not have to google for "hey, I don't think that will work the way it's described".
Please name the site! (so I can avoid them at all costs)
As long as you, the user, trust that the browser itself hasn't been modified (for example if you downloaded it yourself), then it's a nice reassurance when using a browser in a not totally trusted environment.
HTTPS is a nice reassurance, sure, but an EV cert isn't.
It used to be. All his EV certs were revoked.
And people who would follow the correct behaviour...are probably capable of doing so without the EV anyway.
No, I don't believe it is. The point debunked over and over again by Troy in this and other articles of his is the supposed anti-phishing aspect of EV certs: that because the browser shows the company name separate from the url, the user can know that they're really at e.g. Amazon and not amaz0n.com.
I'm referring to a very specific situation that is much more rarely mentioned: when you are using a computer with a managed cert store (usually a company computer behind a firewall) and you want to know if the site you are visiting is getting "legitimately" (per company policy) SSL-sniffed by a network appliance. This is completely different from phishing attacks or whether you think you are at the real Amazon. All you need to do is go to a single site that you know has EV and see if it shows up as EV in the browser. Sure, they could selectively sniff, but in practice I believe most companies that do this have an all or nothing approach.
OT but hopefully interesting: Paypal doesn't care about many things. Like keeping their callback JVMs up2date, or changing their UAs from defaults to disguise their enabling tech.
2019.05.20 xxxx|173.0.81.33|xxxx|POST xxxx/paypal/callback HTTP/1.1|200|954|-|Java/1.8.0_60|xxx|xxxxxxx 2
Can you let me know if this is Webhooks or IPN and if you saw this in production or sandbox?
Thanks!
Sure, a lot of those probably don't apply to how they're using Java, but I'd bet at least a couple do.
It's good to make updates carefully, with full testing and a rollback plan. It is also important to actually push updates.
But I would also like to point out that PayPal is a known bad player when it comes to phishing, so no one really should give a damn what they do, and if you do the opposite of what PayPal does in security you are probably doing better than them.
Edit: I also see the EV cert on Firefox 66.0.5 and 67.
I can't really tell if safari has an EV indicator or not? I really don't use it much but it looks like this https://i.imgur.com/9asQkbN.png Safari version 12.0 (14606.1.36.1.9)
Normal TLS sites are black.
Sites with no SSL/TLS say “Not Secured —“ before the site name.
"Well this is weird".
Not sure if it's possible, but my money is on incorrect certificate deployment somewhere in the Paypal infrastructure, maybe an incomplete bundle somewhere that is affecting the "EV" evaluation.
I can't even imagine what you are referring to here. PayPal phishes people? Citation needed, please.
A lot of the bigger companies are guilty of this, Google is probably one of the few exceptions, since emails from Google tend to actually originate from ...@google.com, and their logins are all handled through accounts.google.com, unlike e.g. Microsoft which still has a handful of different login portals for the same account on non-microsoft.com domains (such as "msauth.net").
E.g. Dropbox sends emails from half a dozen or so origins, Microsoft uses a bunch, too, including shit like "microsoftmail.com" which rivals some of Paypal's choices for phishiness.
https://bugzilla.mozilla.org/show_bug.cgi?id=866522
https://bugs.chromium.org/p/chromium/issues/detail?id=233903
Making CSP not affect bookmarklets at all (as opposed to not affecting whether they execute) is a different situation entirely, because bookmarklets by definition execute in the JS environment of the page (unlike extensions, say), so it's not really possible to tell apart things that the bookmarklet does from things the page does. For example, what should happen if the bookmarklet calls a page-defined function that then does a subresource load? What if a bookmarklet defines a function to do a subresource load that the page later calls? Note that from the point of view of the JavaScript engine the functions the bookmarklet defines and the ones the page defines are indistinguishable from each other...
It blocked the sticky header for me on this site no problem.
> Description: Web Annoyances Ultralist Sublist for CSS element modifications - Modify site elements that block screen real estate - Primarily used to "pin-in-place" sticky headers, dickbars, floating headers, floating videos, scrolling headers, scrolling videos, stickynavs and other distracting page elements.
"Big sites can get by with DV because people trust big sites by fiat, just by mental associations they already have to a URL. There's no benefit to Facebook having an EV cert, because literally everyone who'd want to visit Facebook knows Facebook's URL. User error about entering credentials on the wrong site -- accidentally due to typosquatting, or through leading such as phishing -- is better mitigated in other ways: multi-factor authentication (especially unproxiable such as U2F); not by making the high-profile site pay thousands of dollars for a text string in green, when there's users who fall victim to phishing from bizarre domains too."
Ultimately, this is a bad example to show that EV is pointless. The biggest benefit of EV is as a flawed signal of legitimacy [1] for sites whose URLs aren't widely known and get a fair amount of first-time visitors: web presence for real-life service businesses, specialized payment portals accessed through redirects, and the like.
This is because people's mental model of the trust that EV confers is broken. People typically care about whether the site they arrived at was the one they were intending to visit, which the computer can't possibly know without additional input, but EV has attained a role of serving as a flawed signal of such, because the browser bar said something that doesn't look alarmingly different.
EV formalizes the vetting between legal entity and domain name, so it translates okay to entities that are firmly anchored in meatspace. But all of this chaining is trust in people's heads is done by names and strings, and experiments like stripe.ian.sh prove [2] why it's fallible. Nonetheless, EV effectively allows one extra indirection between (1) the name of the business as people refer and recognize it, and (2) the domain name that's likely correct, than DV does -- and some operators and some visitors benefit from this indirection, when the URL doesn't roll off the tongue.
[1] https://news.ycombinator.com/item?id=18010961#18011914 [2] https://news.ycombinator.com/item?id=15904513#15909273
Never forget when ReadWriteWeb posted a blog post entitled "Facebook Wants to Be Your One True Login", which ended up ranking very highly for the search query "facebook login". It was subsequently innundated with comments from angry people who hated the new redesign and couldn't figure out how to log in... believing that they were on facebook, because they googled "facebook login" and clicked the first result.
https://web.archive.org/web/20100213061037/https://www.readw...
Scroll down for the comments. It's pages and pages of people frothing at the bit looking for anywhere to enter their facebook password.
> for those of you that want to get in face book now just go to Bing..put in face book and search (or it will pop up) hit on face book login and it takes you to your password page...i did it.... if this ever gets back to normal I will use the address bar from now on.....
I'm not sure I'd agree with this. I don't think most people look at or really understand URLs or domain names. I think people assume they are a lot "fuzzier" than they are, so "facebookapp.com" or "facebook.foobar.com" or anything else would be assumed to be "Facebook" by most people.
As technical people it's easy for us to assume things that feel basic to us are at least understood but I don't think it's the case. My parents do most of their shopping online, and when I was growing up we always had computers around, but I don't think either one of them really understands URLs or things like file hierarchies, or windowing systems on desktops for example.
A very non-trivial amount of people type "facebook" into Google and then click the first result.
Edit: found it! Scroll to the bottom for the comments. https://web.archive.org/web/20100213061037/https://www.readw...
I'm with a company that uses EV certificate for our site, mostly just to "look even more trustworthy", even though it functionally servers very little purpose for us, and in an industry where I doubt very few clients know what it really is. For large companies the cost of an EV certificate is negligible. If someone wanted to impersonate us, they would only need to change a letter or two and get a similar `.com` domain, which would be easy to do since we have a somewhat unusual name.
The linked article also talks about the possibility of people getting a shortened domain name like `g.uk` for phishing. If a company has a wide portfolio of sites, that becomes even easier since it weakens peoples association between a canonical domain and the company.
I guess the main point is that the DNS records themselves are one of the most effective preventions of phishing since you need a mapping from a user intent to the site they arrived at. Domain names provide a memorable and easily "mentally verifiable" method of mapping from "facebook.com" -> Social Media, "gmail.com" -> Email, etc. for most people. But strings of characters are also vulnerable since they can be easily changed by a transposition, or other operation, to create a new domain name that looks _very_ similar. Since our minds are much better at recognizing words by the beginning and end, they are vulnerable to changes in letters in the middle.
It makes one wonder if there is a system that would allow much easier mental verifiability of that mapping, but which would still allow a large number of possibilities. Or whitelisting sites that you regularly visit and alerting an individual on sites not in the whitelist or which _resemble_ sites in the whitelist.
[1] https://www.typewritten.net/writer/ev-phishing/
EDIT: just to make clear, I think strings and domain checking mentally is a terrible model for verifying trust. But at least it kinda works some of the time, even though there are tons of vulnerabilities and problems. But probably better than typing in raw IP addresses, most of the time.
This drives me nuts. Browsers should never hide the domain name (or any other part of the URL).
More subtle manipulations from phishing remain possible, but they're trickier to pull off than just stealing people's passwords.
IIRC somebody has a proof like with Arrow's theorem - that the perfect desirable set of features for names can't be achieved, but I can't find it. Certainly you can see a different trade in Tor hidden services for example, bad guys can't get a name arbitrarily similar to yours, but your name is also mostly gibberish, so your users probably don't remember what it is anyway. Did they buy the last bag from greatweedxstrm4aqp.onion ? Or was it weedxgreatstre6g2q.onion ? And unlike conventional Phishing the plan is probably to break your door down and arrest you if you pick the wrong one which sucks worse than card fraud...
www.xudongz.com/blog/2017/idn-phishing/
Compare http://xn--j1ail.xn--p1ai and https://xn--d1aqf.xn--p1ai - If rendered to punycode, they look like this:
kto.rf: xn--j1ail.xn--p1ai dom.rf: xn--d1aqf.xn--p1ai
To note: Firefox (Nightly) on desktop for me rendered the false Apple domain near-identically to the real Apple, and for the two RF domains, the Cyrillic was used.
Compare:
https://www.ssllabs.com/ssltest/analyze.html?d=xn--frskrings...
https://www.ssllabs.com/ssltest/analyze.html?d=www.forsakrin...
EDIT: woah HN did a funky thing with a URL in a post to fight against misleading domains! http://xn--frskringskassan-2kb71a.se
Who is https://withgoogle.com?
However, if I'm going to a site that really matters, I'm not clicking on some link on a web page or email somewhere. I'm using the link I've bookmarked. So, ignoring the EV cert is probably not putting me at too much risk.
Step One: Create Doofenshmirtz Evil LLC.
Step Two: Register HugsAndTrustBanking.com to LLC
Step Three: Get the legal services of Dewy Cheetum & Howe to issue a letter stating Evil LLC is your legitimate business.
Step Three: Show CA "proof" of ownership for Doofenshmirtz Evil LLC and HugsAndTrustBanking.com.
Step Four: Get genuine EV cert for your shady scam operation.
Step Five: Profit.
EV certs are dumb, you can trust me on that[0].
Without an EV Certificate, you can just buy a domain name and use LetsEncrypt to generate a DV certificate which is a much smaller paper trail.
The point is, you'd be an outlier if you did!
Funny story - I was about to rant that yeah, it probably wasn't by design because Paypal still as of 2019 didn't offer 2FA which, for a payment company, was quite disturbing...
well, turns out I was wrong, they now do. I just hadn't checked in a while, and of course received no email about it when they did turn it on... or maybe just missed it. Typically something you should advertise on each login if it's not activated, but hey, who cares, it's just money after all.
I was prompted to change to TOTP when I logged in.
That exactly. Similarly confused about customers who think OV certificates are better than DV - as far as I can tell no end user knows how to tell those apart in their browser (no 'green' locks...)
> "the true meaning of SSL certificates"
The certificate fields for organisation, city, etc have existed and were expected to be verified since SSL was created in the nineties. Anyone who has ever made a CSR knows this.
Rolling back from checking the organisation to domain-only validation in 2003 was GeoTrust trying to increase profit margins. Again, Troy should already know this and it's surprising he doesn't seem to.
Oddly enough Troy also Tweets from a verified account, which seems somewhat unusual since a well known username should be enough according to his logic against verifying websites.
Heads up: I run CertSimple, a startup that does faster, simpler verification for EV.
The article I've just read never uses the phrase "the true meaning of SSL certificates" that I can see, if that was removed I apologise but otherwise I think I have to assume you're putting words in Troy's mouth.
"The certificate fields for organisation, city, etc have existed and were expected to be verified since SSL was created in the nineties. Anyone who has ever made a CSR knows this."
Anyone who understands what's actually going on here knows that these are part of the X.500 directory system and are present in Netscape's SSL because it leverages that systems's X.509 certificate format. In 1999 PKIX (RFC 2459) proposes how to use this system sensibly with the Internet and the modern Web PKI largely falls out of that and its successor documents.
Prior to the CA/B Forum (and the creation of Extended Validation) the only promises you had about what, if anything, in certificates you relied on had been "verified" and to what extent, was written in the legal documents of the issuing CA. In most cases they disclaimed all or almost all responsibility to the extent possible. Their methods were... unsound.
Even today, when if you run Firefox (or more or less, Android) you can actually trust that someone cares whether the validation was done properly, it's more slip-shod than any of us should want. What has Certinomis been up to for the past few years? What are all these certificates doing with ST=Some-State (yes, literally the words "Some-State", because that's the default in OpenSSL)? or L=Default City (again, the default in OpenSSL)?
I think we can reasonably conclude that the reason nobody engaged with my questions about those is that the answers would be embarrassing and they're hoping that if they stay quiet nobody will follow up by asking why they're filling this crap out (to make money) if they can't validate it properly...
> Frankly, I think this is more a symptom of people coming to grips with the true meaning of SSL (or TLS)
I did add 'certificates' so it read better (the system is PKI not SSL) but yes it's from the article.
Yep, they're x509v3 fields. Netscape was under no obligation to include them - they simply could have included CN only if they thought people didn't want to know the organisation they were communicating with.
However Organisation was included by Netscape and it was verified until GeoTrust invented DV (and later other CAs copied it to compete with the low margins of not checking identity. Totally agreed about the poor quality of verification during the 90s though (fax on company letterhead etc).
The one thing that hasn't changed in 20 years is that people still want to know who they're communicating with online.
Why does my comment have to be spelled out anyway? I'm having a hard time believing you don't know that or haven't realized it.
What does it matter to the end user whether the difference is technical, legal, or procedural? The user just wants to be able to tell the difference between a legit site and a phishing spoof.
> Why does my comment have to be spelled out anyway? I'm having a hard time believing you don't know that or haven't realized it.
The article points out that users and paypal didn't care that their domain wasn't using EV, as if this were a slam-dunk argument against it. But that argument would go through just the same for a domain that wasn't using HTTPS at all.