Re: [openssl-users] Question on necessity of SSL_CTX_set_client_CA_list
> On Dec 6, 2018, at 5:56 PM, Jakob Bohm via openssl-users > wrote: > >> While the point of EV was that it certified a binding to a (domain + >> business name) >> rather than just a domain with DV, it turned out that displaying the >> business name >> was also subject to abuse, and the security gain proved elusive. >> >> https://www.troyhunt.com/extended-validation-certificates-are-dead/ > > A traveling salesman for a cloud provider. That's an ad-hominem argument. Just because he may have an agenda, does not mean he's wrong. One might wish he were wrong, but perhaps the market has spoken otherwise. Or perhaps he really is wrong, we'll see... -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Question on necessity of SSL_CTX_set_client_CA_list
On 06/12/2018 21:16, Viktor Dukhovni wrote: On Dec 6, 2018, at 3:06 PM, Blumenthal, Uri - 0553 - MITLL wrote: 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. No, Uri you get it wrong. Different levels of certainty is the point. Consider it like this: DV: A regular printed business card that you can get from a vending machine, proves very little. The CA just checks that the person or robot requesting the certificate has some semblance of control over the domain name at the time of issuance. Price is as low as $0. OV: A debit card with the supposed owners name on it, available from a number of companies that do minimal checking, but still a better ID proof than a business card. The CA must check that the company name and address are true, using some basic steps such as checking that a company by that name exists at that address and confirms they are the ones requesting the certificate. There is no check that the company name is an official name or that the company has a business license etc. A traditional lemonade stand run by children can potentially get an OV certificate if they stay in one place for the time it takes to get the certificate. (A CA agent visiting the company site is enough checking of company existence for OV). EV: A proper photo ID with serious identity checking before being issued, like a government passport. Includes the holders legal name and government ID number (literally), which can be used to look up the subjects legal status. The CA must check public records, and do some hard checks that the request is officially from that company. There is a 50+ pages official specification listing how every tidbit of this information must be checked. The CA cannot limit its own liability for certain failures to less than $2000. Each step up the ladder gives the user more certainty the person/website is who it says it is, but is more expensive and difficult to obtain for the person/website. Each step also costs more money for the CA to check, because there is more work to do. The "make it look green" and "fights crime" slogans were just the old marketing campaign, repeated endlessly as a more efficient sales pressure than the real explanation. While the point of EV was that it certified a binding to a (domain + business name) rather than just a domain with DV, it turned out that displaying the business name was also subject to abuse, and the security gain proved elusive. https://www.troyhunt.com/extended-validation-certificates-are-dead/ A traveling salesman for a cloud provider. 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
Re: [openssl-users] Question on necessity of SSL_CTX_set_client_CA_list
> On Dec 6, 2018, at 3:06 PM, Blumenthal, Uri - 0553 - MITLL > wrote: > > 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. While the point of EV was that it certified a binding to a (domain + business name) rather than just a domain with DV, it turned out that displaying the business name was also subject to abuse, and the security gain proved elusive. https://www.troyhunt.com/extended-validation-certificates-are-dead/ -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Question on necessity of SSL_CTX_set_client_CA_list
>> 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. smime.p7s Description: S/MIME cryptographic signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Question on necessity of SSL_CTX_set_client_CA_list
On 06/12/2018 11:48, Michael Ströder wrote: On 12/6/18 10:03 AM, Jakob Bohm via openssl-users wrote: On 05/12/2018 17:59, Viktor Dukhovni wrote: IIRC Apple's Safari is ending support for EV, and some say that EV has failed, and are not sorry to see it go. This is very bad for security. So far the only real failures have been: 1. Some cloud provider(s) actively want to reduce all TLS security to the anonymous form provided by Let's encrypt, and are doing their worst to sabotage EV providing CAs. 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. I fully agree with the above and I'm also for removing this crap from the browser UI. 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. Due to market forces, the good CAs also offer the weaker certificate types at a lower price to compete with the mediocre CAs that are aren't good/thorough enough to do the full job. The way EV certs are highlighted in Browsers (Green bar etc.) was a way to create market demand for the higher quality. They could be indicated in some other useful way of cause, but the distinguishment between "The CA did something to check the name and real world address in the certificate" (OV) versus "The CA checked the name and and real world address thoroughly in accordance with the higher quality standard" (EV) is still of some significance. If you look at that long list of CA roots preinstalled in a typical browser, only a minority are authorized, trusted and audited to issue to the higher EV standard. 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
Re: [openssl-users] Question on necessity of SSL_CTX_set_client_CA_list
On 12/6/18 10:03 AM, Jakob Bohm via openssl-users wrote: > On 05/12/2018 17:59, Viktor Dukhovni wrote: >> IIRC Apple's Safari is ending support for EV, and some say that EV >> has failed, and are not sorry to see it go. > > This is very bad for security. So far the only real failures have > been: > > 1. Some cloud provider(s) actively want to reduce all TLS security to > the anonymous form provided by Let's encrypt, and are doing their worst > to sabotage EV providing CAs. 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. I fully agree with the above and I'm also for removing this crap from the browser UI. Ciao, Michael. smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] AssAccess was passed with no amendments
Does OpenSSL have a policy stance on government enforced back doors ? -- Regards, Mark A. Lane Cryptopocalypse NOW 01 04 2016 Volumes 0.0 -> 10.0 Now available through iTunes - iBooks @ https://itunes.apple.com/au/author/mark-a.-lane/id1100062966?mt=11 © Mark A. Lane 1980 - 2018, All Rights Reserved. © FooCrypt 1980 - 2018, All Rights Reserved. © FooCrypt, A Tale of Cynical Cyclical Encryption. 1980 - 2018, All Rights Reserved. © Cryptopocalypse 1980 - 2018, All Rights Reserved. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [EXTERNAL] Re: Self-signed error when using SSL_CTX_load_verify_locations CApath
On 05/12/2018 00:50, Viktor Dukhovni wrote: On Tue, Dec 04, 2018 at 04:15:11PM +0100, Jakob Bohm via openssl-users wrote: Care to create a PR against the "master" branch? Something along the lines of: "Provided chain ends with untrusted self-signed certificate" or better. Here "untrusted" might mean not trusted for the requested purpose, but more precise is not always more clear. Perhaps s/untrusted/unknown/ as in "Provided chain ends with unknown self-signed certificate". I don't see why "unknown" is better, it could under certain conditions be "known", but not trusted. Unknown would differ from untrusted in cases where there is some setting indicating that some certificates in the CA directory are trusted only for some/no purposes. This could (in current or future code) represent things such as the trust bits in "Trusted Certificate" files. Or even better, two different error codes: - "Only self-signed end certificate provided" - "Provided chain ends with unknown root certificate" That already exists: crypto/x509/x509_txt.c: case X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT: return "self signed certificate"; case X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN: return "self signed certificate in certificate chain"; In that case, maybe change the text to: "Provided chain ends with an unknown and thus untrusted root certificate" This would capture both the fact that the root is unknown (not in the CA stores configured/loaded) and that this is the specific fact causing it to be untrusted. 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
Re: [openssl-users] Question on necessity of SSL_CTX_set_client_CA_list
On 05/12/2018 17:59, Viktor Dukhovni wrote: On Dec 5, 2018, at 4:49 AM, Jan Just Keijser wrote: The only reason to use OCSP I currently have is in Firefox: if you turn off "Query OCSP responder servers" in Firefox then EV certificates will no longer show up with their owner/domain name. IIRC Apple's Safari is ending support for EV, and some say that EV has failed, and are not sorry to see it go. This is very bad for security. So far the only real failures have been: 1. Some cloud provider(s) actively want to reduce all TLS security to the anonymous form provided by Let's encrypt, and are doing their worst to sabotage EV providing CAs. 2. As part of this campaign, those same cloud provider(s) take every opportunity to declare EV (and even OV) certificates as worthless and irrelevant. 3. At least one of those cloud provider(s) publishes a widely used "browser", in which they have preemptively removed support. Apple being tricked into removing support (contrary to their public hard stance on user security) is sad. Now the question is: does Firefox get OCSP "right" ;) ? Very likely yes. The Firefox TLS stack is maintained by experts. [ Also, FWIW, Firefox uses the "nss" library, not OpenSSL. ] However Firefox code also contains lots of idiotic usability bugs, even in the code that talks to the TLS stack. It is quite possible that the "OCSP must be on" rule is another bad usability hangover from the set of badly thought out UI changes made to initially promote EV certificates, just like the hiding of company names from non-EV certificates that actually contain them (so called OV certificates). 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
