I think the only solution to fixing this is for Safari to show the domain again. It is the URL that is unique and known by the visitor, not the business name.
Here in the UK there is another problem with EV certs, there is no way of registering a "trading name" or "doing business as (DBA) name" against a company so you can only have an EV cert issues against your actual registered business name. If that is different from your trading name and what you use as your domain name then they are less than worthless. For example, if the company is "Widgets of London Limited" but trade online as "Widgets Online" with the domain "widgetsonline.com" they cant get an EV cert with "Widgets Online" as the name - even if they own the registered trademark of it.
Maybe another solution to this is not to show just business name directly, force it to show the domain as well unless there is a registered trademark that is proven to be owned by the organisation and only then go the safari route of showing a shortened name?
If you click through to the page the article is referring to, his description of the problem is far better than Ars' summary[0], and he basically says some of the things you said. He is however more pessimistic:
> There will undoubtedly be many proposed solutions to this issue. Ultimately, though, any method that ends up giving users a legal entity is fatally flawed. As a result of how extended validation certificates work, browsers have few options to fix this. Having said that, they can take steps to ensure EV certificates do not override other critical parts of the user interface, like Safari does.
[0] Edit: Actually, on this note, might I suggest the HN link be changed to point to https://stripe.ian.sh/
> ...so you can only have an EV cert issues against your actual registered business name
This seems reasonable to me. If I had to chase you in court, I'd need your actual registered business name, and not your trading name. Further, there can be no verification of your trading name as there is no central registry or deduplication of trading names. If you could get a certificate naming your trading name, then so could a fraudster.
This does make trading names less useful on the Internet. As a consumer, I don't feel anything of value has been lost.
> ...unless there is a registered trademark that is proven to be owned by the organisation...
This doesn't work either since trademarks don't exist in a single namespace. A fraudster could register a trademark matching yours but for use in a different market.
Everyone is quick to say "well if you show the url its not a problem"
How? Jimmy B User obviously didnt know the correct url, thats how he got to the wrong site. A url like "htts://stripe-payments.com" in this scenario would look reasonably legit to most people.
For countries that don't have national business registration, browsers perhaps need to show more than just [US] etc.
But even then - how do I know what state Stripe is registered in?
> Jimmy B User obviously didnt know the correct url, thats how he got to the wrong site.
Jimmy B may well know the right URL, but have clicked a maliciously crafted link in a phishing email or something similar. Jimmy may also have made a typo and have a chance of spotting it in the address bar.
I love this quote: 'this site uses an EV certificate for "Stripe, Inc", that was legitimately issued by Comodo'. Comodo has been responsible for a bunch of SSL-related security fiascos over the year. https://en.wikipedia.org/wiki/Comodo_Group#Controversies
but in this case, what is Comodo supposed to do? For a generic name such as "stripe", are other (less famous) "stripe" companies, are they out of luck if they want a EV certificate?
Maybe it's time to put all the certification documentation into the certificate so they can be retrieved and viewed by anyone. Registration, signatures, payments, proofs, etc. Why does only the CA get to see it? Everyone should be able to see.
Depending on the certificate, this could be quite a lot of data, the certificate is delivered on every new connection, right now they're commonly a kilobyte or so of data.
For a typical DV certificate, maybe the CA has done 3.2.2.4.6, so they have a log showing the DNS look-up they did from first principles (so it's the whole thing from the root, not just a cached single entry), then the HTTP transaction, with the Request Token inside it, and they've matched the Request Token against the expected value. That could easily be several kilobytes. The CA is required to store this, but burning it into the certificate is extra data all so that what, one person in a million can look at it, and go "Eh, that looks roughly like I'd expect" ?
For an EV certificate there's going to be stuff they found in a government data source, then the stuff from Dun & Bradstreet, then... what maybe a WAV file of a phone call to the number listed in D&B? PDF scans of headed notepaper? And it tells you... somebody, somewhere said this was fine. So what?
As I've stated on m.d.s.policy the ability to make companies in the US and UK that can't be traced back to their real owners without a heroic effort by law enforcement is not a bug it's a feature. Your government (if you live in the UK, the US, or even arguably the EU) tacitly supports the dirty business done by this route so long as they're able to disclaim any knowledge it's going on.
You can send it through a secondary query, not in the initial cert, so only if the user looks it up. It should be a supported possibility though. As for what you get out of it, that's okay, have it match meatspace level first, not trying to fix the world.
"However, when you hear "Stripe, Inc", you are probably thinking of the payment processor incorporated in Delaware. Here, though, you are talking to the "Stripe, Inc" incorporated in Kentucky." -- how is that possible to have identical company name in a country?
Companies are registered at the state level, but names are trademarks that are overseen at the federal level. The real Stripe could probably sue and force a change of name due to trademark infringement, especially since the fake Stripe's primary business seems to be online as well. The real Stripe probably couldn't sue and force a change if someone registered another Stripe, Inc. in a different state who paints lines on roads or something.
Being online isn't a business. stripe.ian.sh does not compete with stripe.com, and there's zero risk of consumer confusion between these two websites. Stripe.com has no case for trademark infringement.
If I were Stripe.com's legal counsel, I'd have already fired off a C&D. Stripe.ian.sh isn't trying to subvert traffic, but the entire point of this exercise is to show how it's possible to be confused for the real Stripe.com under certain circumstances. It's a fine line and if I were from the real Stripe I wouldn't want to let those sorts of grey areas go unchallenged.
Free speech is a defense for trademark infringement, especially non-commercial speech. Showing how someone could theoretically be confused is not the same as actually being confused. Consumers aren't confused by someone writing an article about a company... that's not trademark infringement. A trademark does not give you rights to prevent people from writing about your company.
Article has screenshots of it intentionally looking like the stripe homepage. Guess that was an older version, and now it's just a blog post, but it has had the exact same look.
Because there simply aren't enough names. Trademark doesn't care if you use the name Ford, for example, as long as you don't use it to sell cars. They care about "name + line of business", not just about "name".
This is scary, especially safari displaying only the name of the company and not the domain name.
I don't see how we could provide a totally safe network of sites (where you can trust the identity of every site you're visiting), without having a "safe internet" where all the sites are known in advance and you can't leave this walled internet. But I really don't like the idea.
Maybe something like keybase could help, where sites could link their identity to social network accounts (twitter, Facebook, GitHub) or other websites.. and the browser would verify those connections (but it still faces a UI challenge)
Keybase actually already allow validation of a domain name with dns record. If they could add validation of an tls (ssl) certificate and provide a browser extension that added their own indicator to the toolbar to validate that the domain is owned and secured by the correct entity that would work well.
Keybase already has your Public Key so to prove you own a domain it is sufficient to put a signature up and available in DNS to validate this claim.
An attacker does not have this validation signature and can thusly not arbitrarily sign sites as you.
I don't see how keybase would help for a Certificate Validation, especially since Keybase makes no actual attempts at indentifying you (that is a problem of your social circle on keybase)
It seems to me---though I could be wrong---that it's only a small subset of sites that are the primary high-value targets for phishing attempts. Could browser vendors make a significant improvement simply by keeping a list of major financial institutions, government agencies, huge employers, etc. and warning users before going to a site with a URL or certificate identity similar to those entities?
I think the hard part is how to tell if some site is "similar" to a sensitive site. Do you check just the owner ? (like in the example, but that would prevent any other company named stripe to own an EV certificate)
Or do you check if the domain is similar to another one?
This is a very hard problem. Maybe the similar name approach could work if it displayed just a warning to the user when he visited a site owned by someone with a similar name to a sensitive site.
That's what I was thinking of. A simple "hey, just so you know, this website has a pretty small edit distance from "paypal.com" (or ditto with certificate owner names). If you're trying to go to the big important financial institution that ain't it, but otherwise click here to carry on."
Not perfect, obvs, but would that be an improvement?
And even sometimes, you can have totally unrelated domains, but the site that looked exactly like PayPal, and people don't look at the domain (sometimes the site doesn't even have a certificate)..
If you want to throw machine learning at it, the browser could try to predict what site the user thinks they are on, and highlight any discrepancies.
The data collection necessary to get an accurate model would however be quite invasive, so I'm not quite sure whether I'd use a browser with that ability. Maybe just having visual fingerprints of the most visited sites and serving them as a static model would be enough.
Of course EV is broken -- of more like, people's mental model of the benefits that EV confers is broken. As noted in the article, an EV cert asserts that the domain name is controlled by a legal entity in some jurisdiction. This is a very distinct notion from the site that you've arrived at being the site that you were intending to visit, but people use it as a terrible, flawed proxy for such.
On the topic of certs, last year, when Google announced they were now a root CA [1], I remarked that this made a lot of sense, because "who better to say that Google is indeed Google than Google itself?" [2]
I went on to write that not everyone runs a root CA because coordination of trust between various parties is difficult, and so are the mechanics and practices of running a CA, but if your browser (and/or OS) is the final gatekeeper of the trust anyway, why not just push trust towards the edges and out of the middle? Certainly, the most-visited websites could easily be in this boat.
As it stands today, the most-visited websites already don't use EV, because DV certs are good enough for their needs. People trust their website by fiat, simply by mental associations about their domain names, an imperfect process that makes plausibly-looking domain names such an effective tool for phishing. But users already fall for phishing conducted from ridiculous domain names too, so there's not much point.
Although Google has announced its intent to seek trust as a root CA it has not received that trust from major trust stores. Most of the stores don't provide any tracking information but Mozilla operates entirely in the open, so you can see here that Google are some day down their list:
Mozilla's process takes about two years on average (Google know what they're doing so it might be 18 months, people who are hapless or clueless often take 5+ years and give up) and most other trust stores seem to take longer, although heaven only knows what they're doing since we can't see it.
It's worth mentioning that they also acquired two root certificates from GlobalSign that are already trusted by most root programs. Some of their sites are already using this trust chain.
So much for browsers that don't show the full URL. I think the dumbing down of such things has gone way too far and if a browser vendor believes that URLs are now something that can be safely abstracted away then that's not a browser that I would ever use.
One thing that browsers could do now to help with this is add the concept of a domain bookmark, with a similar interface to EV but added by the user. Then the user could a a domain bookmark of "My Bank" or whatever, and check for that when visiting any link claiming to be from your bank. Of course, banks like to use a bunch of random sounding domains so you need to do that a few times (when accessed via the main site)[note]. I check for a bookmark in firefox when typing a domain name, but something that works for the whole domain would be great.
The same basic idea with email is helpful as well, creating a visual distinction for senders you expect to receive mail from and unknown senders. I don't think it is perfectly reliable due to issues with email but it does catch all phishing attempts that I've seen personally.
The GNU Name System or similar would help in some cases, but I don't think it really solves this particular problem. To confirm that a site is one the user cares about, the best way to do that is for the user to indicate that a site is one they care about and then look for that in the future. Then they only need to get the correct site once.
[note] Some banks would still defeat this by creating short term marketing campaign domains and then allowing them to expire... I guess to deal with that there would need to be a way to mark the main long term domain and give other domains the ability to ask a different domain to vouch for them as from the same organization. Then the user could just add one domain bookmark and it would just work for all other domains from that organization. At least unless the bank forgets to update that list before the domain expires...
Simple. Don't use Safari or any browser that makes the users dumb by making it "friendly" to make them vulnerable to things like this. It's not that EV is broken - it's the bad UX decisions and the mentality behind it.
Correction:
Simple. Go to Safari's preferences > Advanced and check the box next to "Show full website address".
I'm definitely not defending Safari's UX choices for defaulting to hiding the website address. I disagree with Apple's decision. However, when there's a configurable way to solve the issue there's no reason to abandon the software.
I fail to see how something like "stripe-service.com" with an EV certificate showing "Stripe, Inc [US]" would be less likely to trick users in a phishing campaign.
I don't use Safari but if I did, I think I would fall for it if someone sets up a phishing website with Safari only showing "Stripe, Inc [US]" in the address bar, but I definitely will not if I was presented with the full URL of the site.
Yeah, we're talking about users who don't really understand phishing, and yet you want them to understand it enough to know not to use the browser that came with their macbook/iphone?
Could this problem be fixed by allowing registered trademarks to be incorporated into EV certificates, and prominently displaying the trademarked name? It seems as though Stripe isn't a registered trademark, but most companies that go for EV I imagine have a legally unique name. It could be incorporated in to the green lock by doing something like "Bank of America Corporation [US] (Bank of America ®)"
Forming a company duplicating a big name in another jurisdiction is a problem. It's a clear trademark violation and may be prosecutable as fraud. At least you know who to sue.
Ran this one through SiteTruth. It does display that the company is in Kentucky, but that's not too helpful.
The EV cert has something I haven't seen before - two StreetAddress fields:
streetAddress=STE 100
streetAddress=212 N. 2nd St
Is that allowed? It's out there in the wild now. The SiteTruth engine didn't handle that properly, and ignored the second field. So the picture of the location didn't appear. Something to fix.
The subject Distinguished Name can repeat fields, yes. Some aren't supposed to repeat but I don't see any obvious harm for those that basically just form a human readable postal address.
Note that for a real criminal enterprise these values are not likely to be useful. Best case they're a company doing secretarial stuff for thousands of clients they've never met. Worst case it's a building site.
One of the top comments there suggested that the solution lies in relying on DNS which provides "globally unique" names.
But the commercial CA system already relies on domainnames. That is its weakpoint.
The author at ian.sh shows how additional checks by third party CAs, e.g., business registration, do not necessarily solve the problem either.
The best proposals I have seen for solving the problem are ones that have no reliance on third parties, e.g. certificate vendors, domainname vendors, etc. Another way to think of non-reliance on third parties is "middlemen". If they are necessary, then the system is vulnerable.
It is a very old problem that apparently has never been fixed. Today solutions that try to avoid middlemen do exist. But comprehension of why this is necessary is apparently still small-scale because focus remains on the commercial CA business, which seems to be at odds with any system that needs no such middlemen.
This author, who many HN readers know, explains it much better than I can: http://sprunge.us/NHTK
Users or businesses can create and exchange their own public keys directly. (Think of HTTPS like SSH.) They do not have to rely on third parties to assist them.
One does not need a third party CA to perform effective encryption. Have you ever wondered if browser warnings are an insidious way to keep commercial CAs in business?
Public keys are globally unique. Names are not. One could combine them (e.g. key fingerprint plus name) to form an identifier that is better than a name alone.
Recap:
Names alone are not enough to perform effective disambiguation via ICANN DNS or major-browser sponsored CA system. Volunteer-supported Wikipedia actually does a better job of disambiguating names than these commercial services.
Public keys can be generated directly by the named entity they represent instead of by third parties. Middlemen are unnecessary and cause the system to be vulnerable.
For example, DNSCurve-enabled nameservers are in the form key.name.tld, cjdns addresses have a key fingerprint embdedded in the users IPv6 address, etc.
I highly recommend reading the excellent draft document from Usenet at the URL I posted, particularly the example of the "Western Wisconsin Computer Company". It is much clearer than my comment and my examples of the simple concept explained therein are probably not ideal (maybe even wrong).
From only a cursory review, I see cjdns as a network where one does not need a third party to: issue a name, issue a key, check a key against a name or a name against a key. Each user creates their own private key, their own public key and finally their own address from their own public key. Unless I am mistaken, users get public keys and addresses from other users, not from a third party.
Here in the UK there is another problem with EV certs, there is no way of registering a "trading name" or "doing business as (DBA) name" against a company so you can only have an EV cert issues against your actual registered business name. If that is different from your trading name and what you use as your domain name then they are less than worthless. For example, if the company is "Widgets of London Limited" but trade online as "Widgets Online" with the domain "widgetsonline.com" they cant get an EV cert with "Widgets Online" as the name - even if they own the registered trademark of it.
See https://certsimple.com/help/doing-business-as-or-trading-nam...
Maybe another solution to this is not to show just business name directly, force it to show the domain as well unless there is a registered trademark that is proven to be owned by the organisation and only then go the safari route of showing a shortened name?
> There will undoubtedly be many proposed solutions to this issue. Ultimately, though, any method that ends up giving users a legal entity is fatally flawed. As a result of how extended validation certificates work, browsers have few options to fix this. Having said that, they can take steps to ensure EV certificates do not override other critical parts of the user interface, like Safari does.
[0] Edit: Actually, on this note, might I suggest the HN link be changed to point to https://stripe.ian.sh/
This seems reasonable to me. If I had to chase you in court, I'd need your actual registered business name, and not your trading name. Further, there can be no verification of your trading name as there is no central registry or deduplication of trading names. If you could get a certificate naming your trading name, then so could a fraudster.
This does make trading names less useful on the Internet. As a consumer, I don't feel anything of value has been lost.
> ...unless there is a registered trademark that is proven to be owned by the organisation...
This doesn't work either since trademarks don't exist in a single namespace. A fraudster could register a trademark matching yours but for use in a different market.
How? Jimmy B User obviously didnt know the correct url, thats how he got to the wrong site. A url like "htts://stripe-payments.com" in this scenario would look reasonably legit to most people.
For countries that don't have national business registration, browsers perhaps need to show more than just [US] etc.
But even then - how do I know what state Stripe is registered in?
Jimmy B may well know the right URL, but have clicked a maliciously crafted link in a phishing email or something similar. Jimmy may also have made a typo and have a chance of spotting it in the address bar.
It's not a perfect solution, but it'd help.
So it was always the case there might be more than one stripe inc.
The problem is the browsers display of that information. Knowing this, why would you hide the domain of the website?
For a typical DV certificate, maybe the CA has done 3.2.2.4.6, so they have a log showing the DNS look-up they did from first principles (so it's the whole thing from the root, not just a cached single entry), then the HTTP transaction, with the Request Token inside it, and they've matched the Request Token against the expected value. That could easily be several kilobytes. The CA is required to store this, but burning it into the certificate is extra data all so that what, one person in a million can look at it, and go "Eh, that looks roughly like I'd expect" ?
For an EV certificate there's going to be stuff they found in a government data source, then the stuff from Dun & Bradstreet, then... what maybe a WAV file of a phone call to the number listed in D&B? PDF scans of headed notepaper? And it tells you... somebody, somewhere said this was fine. So what?
As I've stated on m.d.s.policy the ability to make companies in the US and UK that can't be traced back to their real owners without a heroic effort by law enforcement is not a bug it's a feature. Your government (if you live in the UK, the US, or even arguably the EU) tacitly supports the dirty business done by this route so long as they're able to disclaim any knowledge it's going on.
Quite often the mods will combine/replace a thread when this happens.
https://cdn.arstechnica.net/wp-content/uploads/2017/12/safar...
Ian was not impersonating the real Stripe.
I don't see how we could provide a totally safe network of sites (where you can trust the identity of every site you're visiting), without having a "safe internet" where all the sites are known in advance and you can't leave this walled internet. But I really don't like the idea.
Maybe something like keybase could help, where sites could link their identity to social network accounts (twitter, Facebook, GitHub) or other websites.. and the browser would verify those connections (but it still faces a UI challenge)
Keybase already has your Public Key so to prove you own a domain it is sufficient to put a signature up and available in DNS to validate this claim.
An attacker does not have this validation signature and can thusly not arbitrarily sign sites as you.
I don't see how keybase would help for a Certificate Validation, especially since Keybase makes no actual attempts at indentifying you (that is a problem of your social circle on keybase)
Or do you check if the domain is similar to another one?
This is a very hard problem. Maybe the similar name approach could work if it displayed just a warning to the user when he visited a site owned by someone with a similar name to a sensitive site.
Not perfect, obvs, but would that be an improvement?
Hard to find a solution to this scam problem
The data collection necessary to get an accurate model would however be quite invasive, so I'm not quite sure whether I'd use a browser with that ability. Maybe just having visual fingerprints of the most visited sites and serving them as a static model would be enough.
On the topic of certs, last year, when Google announced they were now a root CA [1], I remarked that this made a lot of sense, because "who better to say that Google is indeed Google than Google itself?" [2]
I went on to write that not everyone runs a root CA because coordination of trust between various parties is difficult, and so are the mechanics and practices of running a CA, but if your browser (and/or OS) is the final gatekeeper of the trust anyway, why not just push trust towards the edges and out of the middle? Certainly, the most-visited websites could easily be in this boat.
As it stands today, the most-visited websites already don't use EV, because DV certs are good enough for their needs. People trust their website by fiat, simply by mental associations about their domain names, an imperfect process that makes plausibly-looking domain names such an effective tool for phishing. But users already fall for phishing conducted from ridiculous domain names too, so there's not much point.
[1] https://pki.goog/ [2] https://news.ycombinator.com/item?id=13495262
https://wiki.mozilla.org/CA/Dashboard#Information_Verificati...
Mozilla's process takes about two years on average (Google know what they're doing so it might be 18 months, people who are hapless or clueless often take 5+ years and give up) and most other trust stores seem to take longer, although heaven only knows what they're doing since we can't see it.
See: https://wiki.mozilla.org/IDN_Display_Algorithm
The same basic idea with email is helpful as well, creating a visual distinction for senders you expect to receive mail from and unknown senders. I don't think it is perfectly reliable due to issues with email but it does catch all phishing attempts that I've seen personally.
The GNU Name System or similar would help in some cases, but I don't think it really solves this particular problem. To confirm that a site is one the user cares about, the best way to do that is for the user to indicate that a site is one they care about and then look for that in the future. Then they only need to get the correct site once.
[note] Some banks would still defeat this by creating short term marketing campaign domains and then allowing them to expire... I guess to deal with that there would need to be a way to mark the main long term domain and give other domains the ability to ask a different domain to vouch for them as from the same organization. Then the user could just add one domain bookmark and it would just work for all other domains from that organization. At least unless the bank forgets to update that list before the domain expires...
I'm definitely not defending Safari's UX choices for defaulting to hiding the website address. I disagree with Apple's decision. However, when there's a configurable way to solve the issue there's no reason to abandon the software.
You can re-enable the link if, like me, you'd like it to be quickly available.
[1]: https://bugs.chromium.org/p/chromium/issues/detail?id=718553
It still shows up for me but I'm on 62.0.3202.89 (haven't restarted recently).
Ran this one through SiteTruth. It does display that the company is in Kentucky, but that's not too helpful.
The EV cert has something I haven't seen before - two StreetAddress fields:
Is that allowed? It's out there in the wild now. The SiteTruth engine didn't handle that properly, and ignored the second field. So the picture of the location didn't appear. Something to fix.[1] http://www.sitetruth.com/fcgi/ratingdetails.fcgi?details=tru...
Note that for a real criminal enterprise these values are not likely to be useful. Best case they're a company doing secretarial stuff for thousands of clients they've never met. Worst case it's a building site.
Not unless they're in the same line of business. See https://www.nolo.com/legal-encyclopedia/question-trademark-i...
The Ars Technica link is just blogspam.
One of the top comments there suggested that the solution lies in relying on DNS which provides "globally unique" names.
But the commercial CA system already relies on domainnames. That is its weakpoint.
The author at ian.sh shows how additional checks by third party CAs, e.g., business registration, do not necessarily solve the problem either.
The best proposals I have seen for solving the problem are ones that have no reliance on third parties, e.g. certificate vendors, domainname vendors, etc. Another way to think of non-reliance on third parties is "middlemen". If they are necessary, then the system is vulnerable.
It is a very old problem that apparently has never been fixed. Today solutions that try to avoid middlemen do exist. But comprehension of why this is necessary is apparently still small-scale because focus remains on the commercial CA business, which seems to be at odds with any system that needs no such middlemen.
This author, who many HN readers know, explains it much better than I can: http://sprunge.us/NHTK
Users or businesses can create and exchange their own public keys directly. (Think of HTTPS like SSH.) They do not have to rely on third parties to assist them.
One does not need a third party CA to perform effective encryption. Have you ever wondered if browser warnings are an insidious way to keep commercial CAs in business?
Public keys are globally unique. Names are not. One could combine them (e.g. key fingerprint plus name) to form an identifier that is better than a name alone.
Recap:
Names alone are not enough to perform effective disambiguation via ICANN DNS or major-browser sponsored CA system. Volunteer-supported Wikipedia actually does a better job of disambiguating names than these commercial services.
Public keys can be generated directly by the named entity they represent instead of by third parties. Middlemen are unnecessary and cause the system to be vulnerable.
s/instead of/in addition to/
For example, DNSCurve-enabled nameservers are in the form key.name.tld, cjdns addresses have a key fingerprint embdedded in the users IPv6 address, etc.
> cjdns addresses have a key fingerprint embdedded in the users IPv6 address, etc.
Very cool idea! I'll read more about this...
As for cjdns,
https://github.com/cjdelisle/cjdns/blob/master/doc/notes/cry...
From only a cursory review, I see cjdns as a network where one does not need a third party to: issue a name, issue a key, check a key against a name or a name against a key. Each user creates their own private key, their own public key and finally their own address from their own public key. Unless I am mistaken, users get public keys and addresses from other users, not from a third party.
Alternate:
http://ix.io/D2F (html)