Question on necessity of SSL_CTX_set_client_CA_list

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Question on necessity of SSL_CTX_set_client_CA_list

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf Of Blumenthal, Uri - 0553 - MITLL
> Sent: Friday, December 07, 2018 15:30

> If there's a non-EV CA that would give you a cert for DNS name amazon.com - I'd like to make sure it's in my list and
> marked Not Trusted.

Wrong threat model, I think. While it's certainly possible that someone could trick or coerce one of the (many) CAs trusted by popular browsers into issuing a DV certificate for *.amazon.com or similar, Certificate Transparency would (eventually) catch that.

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 (Cyrillic small letter a and small letter o are both applicable here) to catch the vast majority of users who haven't enabled raw punycode display (assuming their browser even supports it). Phishing is easy with a forged Amazon email about any purchase - users will tend to think someone has hacked their Amazon account and follow the link to investigate without questioning the provenance of the link itself.

Part of the point of EV certificates was supposed to be making the difference in trust visible to end users. If user agents ignore the EV distinction, then I for one don't see how EV certificates are worth a premium. Stronger requirements don't accomplish anything if those requirements can't be verified by the vast majority of users.

--
Michael Wojcik
Distinguished Engineer, Micro Focus


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Question on necessity of SSL_CTX_set_client_CA_list

Michael Ströder
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?

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

Ciao, Michael.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Question on necessity of SSL_CTX_set_client_CA_list

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf
> Of Michael Ströder
> Sent: Saturday, December 08, 2018 06:59
>
> 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?
>
> => 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.

Oh, I agree (at least on the latter point - I'm not sure how concerned I am about homograph attacks on the subject DN, since the common UAs are verifiying subjAltName values and ignoring the DN). That's why I wrote "was *supposed* to be". I don't think EV certificates accomplished this goal.

I've never felt EV certificates were very useful, and they got progressively worse over time. Remember back in July when Entrust's Chris Baily put language on the CA/BF ballot (Ballot 255, specifically, if anyone wants to look it up) to restrict EV certificates to entities that had been incorporated for at least 18 months? That's the kind of terrible thinking that the EV process produced.

The Stripe certificate fiasco that led to Baily's proposal is another example of why EV certificates Just Don't Work. The idea of having different certificates at different trust levels might be salvageable, but the EV implementation put the burden of evaluating those trust levels on the user (because user agents just passed it on to them), and the vast majority of users aren't in any position to do that. Nor were they in any position to determine how those trust levels ought to affect their threat model (that was the hole exploited by the Stripe attack). A site with a legitimate EV certificate might still misrepresent itself, perform hostile actions, or be vulnerable to attack (or already subverted) - EV says nothing about those risks.

--
Michael Wojcik
Distinguished Engineer, Micro Focus

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Question on necessity of SSL_CTX_set_client_CA_list

OpenSSL - User mailing list
On 10/12/2018 14:41, Michael Wojcik wrote:

>> From: openssl-users [mailto:[hidden email]] On Behalf
>> Of Michael Ströder
>> Sent: Saturday, December 08, 2018 06:59
>>
>> 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?
>>
>> => 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.
> Oh, I agree (at least on the latter point - I'm not sure how concerned I am about homograph attacks on the subject DN, since the common UAs are verifiying subjAltName values and ignoring the DN). That's why I wrote "was *supposed* to be". I don't think EV certificates accomplished this goal.
>
> I've never felt EV certificates were very useful, and they got progressively worse over time. Remember back in July when Entrust's Chris Baily put language on the CA/BF ballot (Ballot 255, specifically, if anyone wants to look it up) to restrict EV certificates to entities that had been incorporated for at least 18 months? That's the kind of terrible thinking that the EV process produced.
>
> The Stripe certificate fiasco that led to Baily's proposal is another example of why EV certificates Just Don't Work. The idea of having different certificates at different trust levels might be salvageable, but the EV implementation put the burden of evaluating those trust levels on the user (because user agents just passed it on to them), and the vast majority of users aren't in any position to do that. Nor were they in any position to determine how those trust levels ought to affect their threat model (that was the hole exploited by the Stripe attack). A site with a legitimate EV certificate might still misrepresent itself, perform hostile actions, or be vulnerable to attack (or already subverted) - EV says nothing about those risks.
The Stripe certificate fiasco relied heavily on browsers not displaying
the EV certificate fields (specificlly Jurisdiction of incorporation)
correctly along with the name, as clearly spelled out in the EV
specification.

That Jurisdiction field along with the uniqueness checks done by the
authorities of the jurisdiction is what is supposed to prevent
homographs in the O field.  For example, using Cyrillic letters in a
de jure company name is unlikely to be allowed outside the Cyrillic
using jurisdictions (former USSR, Serbia, maybe Bosnia and Montenegro).
  If displayed, users should readily notice the wrong country in the
green bar.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Question on necessity of SSL_CTX_set_client_CA_list

Kyle Hamilton
In reply to this post by Michael Ströder
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 <[hidden email] 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
12