[openssl-users] Question on necessity of SSL_CTX_set_client_CA_list

[Kyle Hamilton]

Because only showing the O= is insufficient, you also need to show the
jurisdiction the O= is based in. (In the case of Amazon, it's a Delaware
corporation.)

The fact that browsers are getting tricked into thinking EV doesn't help is
only because their UX designers refuse to allow the information which is
necessary for actual trust to be displayed. It's not the fault of the CAs
or the EV guidelines, it's fully within the hands of the browsers to fix.

But they're worried about "providing free advertising for the CAs" (when I
suggested putting the name of the certifier on the chrome,  so that any
change would raise a flag in the users' mind) or "information overload for
the users" and "insufficient space for other important things" (when I
suggested putting more of the Subject DN on the chrome), even though those
are things that would legitimately put the onus of being tricked fairly on
the user, and off of the browsers which currently don't readily provide the
information.

Regardless, in my view it really doesn't matter. I lost faith in the
browsers being willing to continue to improve things (i.e., work against
the identity homograph arms race) long ago. So now they want to backslide?
I've done my duty to try to convince them to continue to evolve against the
threat landscape. The onus of and blame for their unwillingness to do so is
on them.  Now, I guess we'll only get to see how much of it might stick in
court.

On Sat, Dec 8, 2018, 05:59 Michael Ströder <michael at stroeder.com wrote:

> On 12/7/18 11:44 PM, Michael Wojcik wrote:
> > Homograph attacks combined with phishing would be much cheaper and
> > easier. Get a DV certificate from Let's Encrypt for anazom.com or
> > amazom.com, or any of the Unicode homograph possibilies>
> > Part of the point of EV certificates was supposed to be making the
> > difference in trust visible to end users.
> And how do you avoid such homograph attack on subject DN attribute "O"
> (organization's name) when display the holy EV green sign?
>

By including the jurisdiction the O is organized in, of course.  O=Amazon
Inc,ST=Delaware,C=US.  (That's the point of hierarchical names, after all.
It's to reduce namespace collisions in spaces -- like independent political
entities -- which don't often cooperate together to inhibit problems like
these.)

Interesting note: I could register a corporation named "Bank of America
Corporation" in any state BofA doesn't currently have a presence, to obtain
a potentially EV-valid certificate, and their only recourse might be a
trademark lawsuit.  If I registered it in a foreign nation, they wouldn't
have any recourse at all unless they already had a presence in that
nation.  (Though they might try to convince the feds to prosecute me for
attempted fraud, even if I didn't do anything to actually attempt or
complete a fraud under that name.)  Does this mean that EV is useless? No,
it means that the overarching legal regime enables attacks that
certificates already provide the means to combat -- but only if the
certificate-consuming software properly implements it.  The idea that a
browser thinks EV is useless is worth nothing.  It just means that they
won't invest into this area of security the way they will into preventing
their processes from being hijacked by arbitrary code.

Should they have to invest in this way? I don't know. They took on the role
on their own, either to try to build trust in web-based commerce (where
they succeeded to the tune of tens of billions of dollars in economic
activity every year) or because they had to try to "keep up with the
Joneses" (i.e., Mozilla and Microsoft and Google, who were doing it for the
more altruistic reason). I can't judge whether they "should". I just know
enough to recognize what they "did".


> => EV certs also don't help in this case.
>
> Also in case of amazon.com most users know the pure domain name but not
> the *exact* company name, not to speak of the multitude of names of all
> the subsidiaries.
>

Subsidiary names are relatively irrelevant, as long as the same subsidiary
name shows up when they do the same thing. If it turns out that there's a
need for them to become relevant, a DNS record with the expected Subject DN
could be published, or a sitemap with the expected name of the subsidiary
in question could be made available, or any of a host of other options
could be explored and done. (And let's not forget the homograph attack
enabled by the lack of https-by-default.)

These arguments you make are arguments for letting the nonexistent perfect
be the enemy of the existing good. They're also arguments for not trying to
work toward the hypothetical ideal, and for throwing the baby out with the
bathwater.


> Ciao, Michael.
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181211/33db6ac3/attachment-0001.html>