
Extended Validation is Broken - rrreese
https://stripe.ian.sh
======
samwillis
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.

See [https://certsimple.com/help/doing-business-as-or-trading-
nam...](https://certsimple.com/help/doing-business-as-or-trading-names)

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?

~~~
lucideer
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/](https://stripe.ian.sh/)

------
stephenr
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?

~~~
ceejayoz
> 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.

It's not a perfect solution, but it'd _help_.

------
jstanley
Check it out here: [https://stripe.ian.sh/](https://stripe.ian.sh/) \- it has
an EV cert that makes the browser show "Stripe, Inc" next to the padlock.

~~~
wiradikusuma
"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?

~~~
mikeokner
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.

~~~
rgbrenner
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.

~~~
mikeokner
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.

~~~
rgbrenner
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.

------
cdancette
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)

~~~
samwillis
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.

~~~
zaarn
There is a different use case though.

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)

------
niftich
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.

[1] [https://pki.goog/](https://pki.goog/) [2]
[https://news.ycombinator.com/item?id=13495262](https://news.ycombinator.com/item?id=13495262)

~~~
tialaramex
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:

[https://wiki.mozilla.org/CA/Dashboard#Information_Verificati...](https://wiki.mozilla.org/CA/Dashboard#Information_Verification)

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.

~~~
pfg
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.

------
jacquesm
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.

~~~
amelius
Even the url can contain special unicode characters that look extremely
similar to different ascii characters.

~~~
jacquesm
That's true, and it would be good to highlight such characters in a way that
makes it obvious that they are not what they seem to be.

~~~
dullgiulio
There are already rules to highlight such domains (the domain is shown in its
punycode form when it violates the rules).

See:
[https://wiki.mozilla.org/IDN_Display_Algorithm](https://wiki.mozilla.org/IDN_Display_Algorithm)

------
jimrandomh
This is a security vulnerability in Safari, and should be reported and
assigned a CVE as such.

------
joveian
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...

------
jchiu1106
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.

~~~
Willamin
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.

~~~
neonhomer
Mobile Safari seems to lack that option, as least as of iOS 10.

------
jdavis703
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 ®)"

------
Animats
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.

[1]
[http://www.sitetruth.com/fcgi/ratingdetails.fcgi?details=tru...](http://www.sitetruth.com/fcgi/ratingdetails.fcgi?details=true&url=stripe.ian.sh)

~~~
tialaramex
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.

------
ComputerGuru
This should just link to the site:
[https://stripe.ian.sh/](https://stripe.ian.sh/)

The Ars Technica link is just blogspam.

~~~
sctb
Thanks! We've updated the link from [https://arstechnica.com/information-
technology/2017/12/nope-...](https://arstechnica.com/information-
technology/2017/12/nope-this-isnt-the-https-validated-stripe-website-you-
think-it-is/).

~~~
ComputerGuru
Much appreciated, good sir.

------
feelin_googley
The OP was originally pointing to ArsTechnica.

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](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.

~~~
Shoothe
Wait, are you suggesting using public key fingerprints instead of easily
memorized names? Just like onion addresses?

~~~
feelin_googley
Please note the word "plus" in the comment.

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.

~~~
Shoothe
That little word changes my option on this proposal.

> cjdns addresses have a key fingerprint embdedded in the users IPv6 address,
> etc.

Very cool idea! I'll read more about this...

~~~
feelin_googley
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).

As for cjdns,

[https://github.com/cjdelisle/cjdns/blob/master/doc/notes/cry...](https://github.com/cjdelisle/cjdns/blob/master/doc/notes/cryptography.md)

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.

------
amelius
Why can't cybersecurity analysts get such simple things right?

~~~
peterwwillis
This has nothing to do with security analysts.

