[openssl-users] Question on necessity of SSL_CTX_set_client_CA_list

[Blumenthal, Uri - 0553 - MITLL]

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.

Regards,
Uri

Sent from my iPhone

> On Dec 7, 2018, at 17:02, Kyle Hamilton <aerowolf at gmail.com> wrote:
> 
> CAs *do* verify the attributes they certify.  That they're not presented as such is not the fault of the CAs, but rather of the browsers who insist on not changing or improving their UI.
> 
> The thing is, if I run a website with a forum that I don't ask for money on and don't want any transactions happening on, why should I have to pay for the same level of certainty of my identity that a company like Amazon needs?
> 
> (Why does Amazon need that much certainty? Well, I could set up wireless access points around coffee shops in December, point the DNS provided at those WAPs to my own server and run a fake amazon.com site to capture account credentials and credit cards. Without EV, that's a plausible attack. Especially with SSL being not-by-default, someone could type amazon.com and it can be intercepted without showing any certificate warning -- which then allows a redirect to a lookalike amazon.com name that could get certified by something like LetsEncrypt.)
> 
> Plus, clouds have had a protocol available for doing queries to certs and keys held by other parties for several years. Cloudflare developed this protocol for banks, for whom loss of control of the certificate key is a reportable event, but who also often need DDoS protection. There's no reason it can't be extended to other clouds and sites -- unless Cloudflare patented it and wants royalties, in which case their rent-seeking is destroying the security of the web by convincing cloud salesmen to say that EV is too much trouble to deal with and thus should be killed off in the marketplace.
> 
> Demanding that EV be perfect and dropping support for it if it has any found vulnerability falls into a class of human behavior known as "letting the perfect be the enemy of the good", which is also known as "cutting off the nose to spite the face".  It still cuts down on a huge number of potential attacks, and doing away with it allows those attacks to flourish again. (Which, by the way, is what organized crime would prefer to permit.)
> 
> -Kyle H
> 
> 
>> On Thu, Dec 6, 2018, 14:07 Blumenthal, Uri - 0553 - MITLL <uri at ll.mit.edu wrote:
>> >    > Quoting from Peter Gutmann's "Engineering Security",
>> >    > section "EV Certificates: PKI-me-Harder"
>> >    >
>> >    >      Indeed, cynics would say that this was exactly the problem that
>> >    >      certificates and CAs were supposed to solve in the first place, and
>> >    >      that “high-assurance” certificates are just a way of charging a
>> >    >      second time for an existing service.
>> >    
>> >    Peter Gutman, for all his talents, dislikes PKI with a vengeance.
>> >     EV is a standard for OV certificates done right.  Which involves more
>> >    thorough identity checks, stricter rules for the CAs to follow etc.
>> >  
>> >     The real point of EV certificates is to separate CAs that do a good
>> >    job from those that do a more sloppy job, without completely distrusting
>> >    the mediocre CA operations.
>> 
>> So, a CA that's supposed to validate its customer before issuing a certificate, may do a "more sloppy job" if he doesn't cough up some extra money.
>> 
>> I think Peter is exactly right here. CA either do their job, or they don't. If they agree to certify a set of attributes, they ought to verify each one of them.
>> 
>> 
>> -- 
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181207/24af6e23/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5801 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181207/24af6e23/attachment.bin>