Re: Question on necessity of SSL_CTX_set_client_CA_list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxx 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
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux