PayPal's Beautiful Demonstration of Extended Validation FUD(troyhunt.com)
troyhunt.com
PayPal's Beautiful Demonstration of Extended Validation FUD
https://www.troyhunt.com/paypals-beautiful-demonstration-of-extended-validation-fud/
106 comments
I run infra for a payments company and switched our main website from EV to DV last month silently. This is the landing website, not the application (which had always been DV). There have been ZERO people who have noticed, including peers in my Infra or Security teams.
It's obvious that EV does nothing for end users these days, which is why I think these "EVs are useless" articles from Troy and others are kind of silly, like dunking over a person with two broken legs.
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 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.
These "EVs are useless" articles are still good for something - ammo to convince your boss that they really shouldn't bother paying for an EV certificate.
> this problem has been solved in real life, at least in the U.S.
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?
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?
> 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:
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.
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 accountability: Knowing who to sue doesn't really get my $50 back from some jerk. The effort put into small claims makes it a net loss. My best option is a chargeback, and the cert doesn't do anything.
For reputation: I have no idea if that's the company name of Wal-Mart. It's barely better than verifying the domain name.
For reputation: I have no idea if that's the company name of Wal-Mart. It's barely better than verifying the domain name.
If you walked into a store on Main Street and got scammed for $50, would you just throw up your hands? Or would you call the cops? If you did call the cops, they would have the address of the store to start their investigation. And aside from maybe getting you your $50 back, the state might prosecute the scammer for committing a crime.
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?
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?
In person I'd try some things. Online I really doubt the cops are going to care about $50.
> 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.
> 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.
I think a monitoring service that notifies you when the certificate changes would be useful (although it's fine to rely on CAA records)
If you're a site operator, it could definitely make sense to have cert checks (e.g. can I assess this cert as trustworthy, will it still be valid 28 days from now) as part of your high level system dashboard. A site with a busted cert is as broken as one that gives 404 errors to all visitors or crashes and won't load at all.
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.
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.
You can get MitM on a smaller scale by simply spoofing WiFi SSIDs.
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 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.
I didn't think SSL-strip could work as described (unless you trusted the cert chain), so I did a little reading.
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".
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".
Thanks for the clarification. I can't edit the original post anymore, so your reply will have to do.
You work in infra for a payments company where the security folks didn't notice a certificate change?
Please name the site! (so I can avoid them at all costs)
Please name the site! (so I can avoid them at all costs)
Should have clarified, nobody noticed that the new cert was not EV.
I'm surprised no one has mentioned the main practical benefit of EV certs: the fact that a green cert in the browser ensures that there is no man-in-the-middle network proxy/appliance intercepting the traffic even if a trusted certificate for the proxy/appliance (or bad guy) has been placed in your machine's cert store. Browsers will only honor the EV setting in the cert if it was signed by a hardwired (and much shorter) list of CAs.
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.
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.
Browsers are moving away from showing differences between EV and DV certs nowadays though. And anyone can register a company name and get an EV cert - that doesn't make it trusted. https://stripe.ian.sh/ is a prime example of this.
HTTPS is a nice reassurance, sure, but an EV cert isn't.
HTTPS is a nice reassurance, sure, but an EV cert isn't.
> https://stripe.ian.sh/ is a prime example of this.
It used to be. All his EV certs were revoked.
It used to be. All his EV certs were revoked.
Sure, but my point doesn't change. https://scotthelme.co.uk/the-power-to-revoke-lies-with-the-c... is a good write-up about that.
Company homonyms are an issue, albeit a US specific one. The industry is looking at verifying trademarks, which tend to be monopolies.
The article is precisely about this: regardless of practical use, people don't follow the behaviour associated with supporting that practice, so it's worthless.
And people who would follow the correct behaviour...are probably capable of doing so without the EV anyway.
And people who would follow the correct behaviour...are probably capable of doing so without the EV anyway.
> "The article is precisely about this"
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.
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.
"PayPal really doesn't care that the world's most popular browser no longer displays the EV visual indicator."
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
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
Hi!
We have two callback options - for 'Classic' and REST. I checked both of them and they both return the proper UA.
Can you let me know if this is Webhooks or IPN and if you saw this in production or sandbox?
Thanks!
Can you let me know if this is Webhooks or IPN and if you saw this in production or sandbox?
Thanks!
'Classic' NVP and this is in production right now.
Gotcha. I'll check it out - in my tests that's returning "PayPal IPN ( https://www.paypal.com/ipn)".
Thanks for getting back to me.
I'm really happy that Paypal ops is not upgrading anything just for the sake of upgrading it. At that scale, changes should be approached with extreme caution.
Well, perhaps they should upgrade it for the sake of the ~170 CVEs that have been published against Java 1.8.0_60? https://www.cvedetails.com/vulnerability-list.php?vendor_id=...
Sure, a lot of those probably don't apply to how they're using Java, but I'd bet at least a couple do.
Sure, a lot of those probably don't apply to how they're using Java, but I'd bet at least a couple do.
They're missing out on probably dozens of security fixes from the past 4 years. Unless they depend on buggy behavior, it is incredibly unlikely that they'll have any backwards compatibility issues, and hopefully they would have tests they could run against a newer JVM to help surface those issues.
> changes should be approached with extreme caution.
It's good to make updates carefully, with full testing and a rollback plan. It is also important to actually push updates.
It's good to make updates carefully, with full testing and a rollback plan. It is also important to actually push updates.
Firefox 66 does not show EV indicators, either, any more.
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.
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.
Interesting because I've got Firefox 67 and Paypal.com does show EV indicator. Actually I see the same in Google Chrome 74.
I'm seeing the EV indicator with Chrome 74.0.3729.169 on Mac OSX Mojave 10.14 (18A391)
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)
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)
On MacOS, Safari uses the green (as shown in your png) for EV certs. HN does not appear to have an EV cert, as it's a gray padlock (not green). And, Paypal does appear with the EV green on my Mac as well.
Paypal URL is green in iPhone Safari.
Normal TLS sites are black.
Sites with no SSL/TLS say “Not Secured —“ before the site name.
Normal TLS sites are black.
Sites with no SSL/TLS say “Not Secured —“ before the site name.
Firefox 66.0.3 and Chromium 73.0.3683.86 on Ubuntu both show the EV indicator on PayPal.
66.0.4 doesn't, Chrome 60 (old version, kept around for specific reasons) doesn't, Chromium 74 does, all on arch.
"Well this is weird".
"Well this is weird".
66.0.5 on my mac did show the EV cert indicator. Not sure if that would have been part of the .4 -> .5 release or if it's because of the os?
67.0 on my Mac does. Chrome 74 does.
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.
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 replicate your findings too. FF67 and C74 in Ubuntu 19.04 shows EV certs on both.
Chrome 74.0.3729.157 here on Windows. No EV indicator for paypal here.
> 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.
I can't even imagine what you are referring to here. PayPal phishes people? Citation needed, please.
I can't even imagine what you are referring to here. PayPal phishes people? Citation needed, please.
Paypal does its best to make all its emails look like phishing by using a quadrizillion of different origins (stuff like paypal-service.com, paypal-australia.com.au, paypalcustomercommunication.com etc.) and routing links through another set of phishy origins and/or external third parties, and to top it all off they give bogus advice like "You can see this email is from Paypal because we are using your proper first and last name".
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 [email protected], 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.
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 [email protected], 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.
I have found PayPal to be excellent in response to phishing attempts- but that's an N of 1 and as an outsider.
Tangential question: neither McDiarmid's "Kill Sticky Headers" [0] nor its improved version [1] work on this website. Does anyone know how the bookmarklet can be changed to work here?
[0] https://alisdair.mcdiarmid.org/kill-sticky-headers
[1] https://news.ycombinator.com/item?id=19962875
[0] https://alisdair.mcdiarmid.org/kill-sticky-headers
[1] https://news.ycombinator.com/item?id=19962875
Is the bookmarklet being blocked by a CSP? There should be an error in the console about that (on chrome, at least)
Indeed it is. So I guess there is no way around it?
A browser extension. Most can run in a context above CSP.
Yeah, interestingly enough the CSP spec says that this behavior is wrong, but browser makers don’t seem to care.
https://bugzilla.mozilla.org/show_bug.cgi?id=866522
https://bugs.chromium.org/p/chromium/issues/detail?id=233903
https://bugzilla.mozilla.org/show_bug.cgi?id=866522
https://bugs.chromium.org/p/chromium/issues/detail?id=233903
We do in fact care. I put up a fix on https://bugzilla.mozilla.org/show_bug.cgi?id=1478037 just yesterday which will make https://alisdair.mcdiarmid.org/kill-sticky-headers work in Firefox no matter what the CSP says. I fully expect to get that landed sometime in the next few weeks.
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...
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...
Sorry, I was a bit frustrated with how long that (and similar bugs in other browsers) have been open without resolution.
I can understand that, for sure!
That's awesome! Thank you!
[deleted]
Ublock Origin's "zap" tool works on it, and you can make the change permanent by creating a cosmetic filter for '##.container.header_block'
In the uBO settings you can bind Zap to a keyboard shortcut. I use ctrl-shift-f. Quite useful.
I recommend adding this filter to uBlock Origin: https://raw.githubusercontent.com/yourduskquibbles/webannoya...
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.
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.
On the HN thread on Troy's last post about this, I said [1]:
"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
"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
> literally everyone who'd want to visit Facebook knows Facebook's URL
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.
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.
I forgot about that one. It's interesting how people will hold on to their method of doing things, even if the workaround is harder than doing the direct thing: (one of the comments)
> 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.....
> 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.....
> literally everyone who'd want to visit Facebook knows Facebook's URL
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.
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.
I have seen multiple people, mostly elderly, who will go to whatever search engine that loads by default in their browser, search for Facebook, and click on the link. Nothing close to everybody has Facebook's URL memorized.
Not everyone knows what a URL is, or understands the difference between a search box and a URL text box.
I remember a few years ago when someone wrote a blog post about Facebook that somehow ranked higher than Facebook itself in Google search results for "facebook login", and was innundated by people who thought they were on facebook and left angry comments about how the redesign was terrible and they couldn't figure out how to log in.
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...
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 found the linked page from ian.sh is extremely instructive. [1] Especially the part about how some browsers hide the domain name when the EV certificate is in use.
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.
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.
> Especially the part about how some browsers hide the domain name when the EV certificate is in use.
This drives me nuts. Browsers should never hide the domain name (or any other part of the URL).
This drives me nuts. Browsers should never hide the domain name (or any other part of the URL).
Thankfully even iOS (I believe starting with 12.2) no longer hides the full domain name when EV is present, but EV will still make the domain's characters turn green.
Security Keys fix the problem of credentials getting phished by making them unphishable (a Security Key will let you give evilguy.example credentials, but only for evilguy.example, they are utterly useless for facebook.com or goodguy.example or any other site, it dumbly refuses to help you give Evil Guy your real goodguy.example credentials)
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...
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...
True, but using visual inspection of the URL is problematic too: Do you mean to be at apple.com or аpple.com ?
www.xudongz.com/blog/2017/idn-phishing/
www.xudongz.com/blog/2017/idn-phishing/
Which, isn't really a problem any more since browsers don't display Punycode any more. https://imgur.com/a/COCrJGy
So, if you're a non-English speaker, doesn't this render distinguishability for real IDNs completely useless?
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 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.
Iirc, the rule being used is the IDN gets rendered unless it crosses character sets. So your domain entirely in Cyrillic or Kanji is fine, but mixing them with Latin characters should be a no-no.
It should be. Unfortunately even really obviously fine cases like Swedish government agencies on the Sweden TLD (försäkringskassan.se), which by the way supposedly has a proper IDN policy that browsers should respect, don't get respected by all modern browsers :(
That Swedish domain doesn't have a TLS certificate for their fancy name.
Compare:
https://www.ssllabs.com/ssltest/analyze.html?d=xn--frskrings...
https://www.ssllabs.com/ssltest/analyze.html?d=www.forsakrin...
Compare:
https://www.ssllabs.com/ssltest/analyze.html?d=xn--frskrings...
https://www.ssllabs.com/ssltest/analyze.html?d=www.forsakrin...
Why should they need one to have the IDN respected?
I don't know what försäkringskassan.se looks like in modern browsers because it redirects (302) to https://www.forsakringskassan.se/
EDIT: woah HN did a funky thing with a URL in a post to fight against misleading domains! http://xn--frskringskassan-2kb71a.se
EDIT: woah HN did a funky thing with a URL in a post to fight against misleading domains! http://xn--frskringskassan-2kb71a.se
Looks like this is fixed in Chrome and Edge by default. In Firefox (release 67.0) you have to dig into about:config and flip the switch on network.IDN_show_punycode (this is discussed in the above demonstration article.)
Defined 'fixed'
huh... Apparently appIe.com takes you to the Amazon page for Apple products through a referral link...
That approach works for the very well known domains, but it doesn't even work for tech giants
Who is https://withgoogle.com?
Who is https://www.microsoftedgeinsider.com?
Who is https://withgoogle.com?
Who is https://www.microsoftedgeinsider.com?
I'm one of those who doesn't pay any attention to those EV cards at all. I know I probably should, just out of completeness, but I don't. In fact, with Firefox anyway, that spot where the EV indicator goes is used for enough weird little things that I've sorta developed a blindness to anything that appears there (I'm not saying that's a good thing!)
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.
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.
I (used to) implement EV certs among other duties and I don't pay attention to them either.
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].
[0]https://i.imgur.com/1dbJUQ9.jpg
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].
[0]https://i.imgur.com/1dbJUQ9.jpg
Steps 1-3 generate quite a paper trail for you and step 3 generates a paper trail for Dewy Cheetum & Howe.
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.
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.
> I'm one of those who doesn't pay any attention to those EV cards at all
The point is, you'd be an outlier if you did!
The point is, you'd be an outlier if you did!
The problem is that EVs never got really widespread - even well-known, important sites never used it. So you have to remember if that particular site used to have one, which is a much harder requirement.
"PayPal really doesn't care that the world's most popular browser no longer displays the EV visual indicator."
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.
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.
PayPal was very early in the 2FA movement, hardware security keys were available starting in ~2008 (https://systembash.com/using-the-paypal-verisign-security-ke...). If you're referring to app based TOTP that is a relatively new option.
I was prompted to change to TOTP when I logged in.
I was prompted to change to TOTP when I logged in.
> Note: yes, I know there can be regulatory requirements for EV in some jurisdictions, but let's not confuse that with it actually doing anything useful
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...)
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...)
Speaking of FUD:
> "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 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.
I don't want this to end badly for you (via CertSimple), but as you perhaps come to anticipate my primary concern is always preventing Future Harm. EV hasn't been effective for that purpose.
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...
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...
The full sentence from the article is:
> 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.
> 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.
(DC would also provide a tree structure if Netscape had wanted to use domain names as the exclusive form of identification - but they didn't. The objection was to verify enough information for commerce, which domain names clearly do not)
How long ago was it that users didn't notice or care if the URL was http:// rather than https://? Yet no-one was declaring HTTPS dead on those grounds.
Apples and encrypted oranges. There's no actual technical difference between EV and DV for the end user, much unlike https vs http...
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.
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.
> Apples and encrypted oranges. There's no actual technical difference between EV and DV for the end user, much unlike https vs http...
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.
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.
The difference matters because http vs. https makes a difference regardless of what the user or HN commenters think, whereas EV relies entirely on the user acting in a way that is entirely theoretical and not seen in practice.
HTTPS has a tangible benefit beyond making the user feel comfortable: it secures the information channel.
[deleted]