Re: [openssl-users] Question on necessity of SSL_CTX_set_client_CA_list
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 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
Re: [openssl-users] Question on necessity of SSL_CTX_set_client_CA_list
On 10/12/2018 14:41, Michael Wojcik wrote: From: openssl-users [mailto:openssl-users-boun...@openssl.org] 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
Re: [openssl-users] Question on necessity of SSL_CTX_set_client_CA_list
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] 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
Re: [openssl-users] Question on necessity of SSL_CTX_set_client_CA_list
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
Re: [openssl-users] Question on necessity of SSL_CTX_set_client_CA_list
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] 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
Re: [openssl-users] Question on necessity of SSL_CTX_set_client_CA_list
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 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 > 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 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
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 >> 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
Re: [openssl-users] Question on necessity of SSL_CTX_set_client_CA_list
On 12/6/18 11:56 PM, Jakob Bohm via openssl-users wrote: > Different levels of certainty is the point. Which never worked well in practice, no matter how hard people tried to clearly define levels if certainty. Ciao, Michael. -- 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 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
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
Re: [openssl-users] Question on necessity of SSL_CTX_set_client_CA_list
> 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. > 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. ] -- 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
Hi, On 03/12/18 21:40, Viktor Dukhovni wrote: On Dec 3, 2018, at 3:35 PM, Charles Mills wrote: OCSP and OCSP stapling are currently higher on my wish list than this. Good luck with OCSP, the documentation could definitely be better, and various projects get it wrong. IIRC curl gets OCSP right, so you could look there for example code, some other projects go through the motions, but don't always achieve a robust result. [ FWIW, I don't care much for OCSP, it's often not required, so it is then not clear what security properties it provides. ] 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. Now the question is: does Firefox get OCSP "right" ;) ? cheers, JJK / Jan Just Keijser -- 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
Those darned customers are asking for it! I do understand the privacy exposure. Don't know if the customers do or do not. Charles -Original Message- From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Viktor Dukhovni Sent: Monday, December 3, 2018 12:40 PM To: openssl-users@openssl.org Subject: Re: [openssl-users] Question on necessity of SSL_CTX_set_client_CA_list > On Dec 3, 2018, at 3:35 PM, Charles Mills wrote: > > OCSP and OCSP stapling are currently higher on my wish list than this. Good luck with OCSP, the documentation could definitely be better, and various projects get it wrong. IIRC curl gets OCSP right, so you could look there for example code, some other projects go through the motions, but don't always achieve a robust result. [ FWIW, I don't care much for OCSP, it's often not required, so it is then not clear what security properties it provides. ] -- 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 3, 2018, at 3:35 PM, Charles Mills wrote: > > OCSP and OCSP stapling are currently higher on my wish list than this. Good luck with OCSP, the documentation could definitely be better, and various projects get it wrong. IIRC curl gets OCSP right, so you could look there for example code, some other projects go through the motions, but don't always achieve a robust result. [ FWIW, I don't care much for OCSP, it's often not required, so it is then not clear what security properties it provides. ] -- 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
> zOS does, for example, at least if you're using the RACF security provider. Ha! Spoken like a Micro Focus guy! One of the most likely clients for this server is in fact implemented on z/OS. Just FYI, the key variable is not so much RACF: (a.) RACF is just (in this case) a certificate store, not a TLS implementation; and (b.) I think the other two ESM's (CA TSS and ACF2) are 99% equivalent in their certificate facilities. The TLS implementation is named System SSL (sometimes known as GSK). That is the TLS library, roughly parallel to OpenSSL. (In fact I don't know of any other TLS implementation on z/OS other than the OpenSSL port -- but there could be some.) GSK also implements its own certificate store, but I don't think it is widely used in production. Yes, there would be lots of certificates in the certificate store, but at least in the case of the client I wrote, you configure it in advance to use a particular named certificate, so the server application itself does not have any choice at run time. It is "one certificate, take it or leave it." Thanks for the heads-up on Windows. I develop for both platforms, but I am much less familiar with all of the ins and outs of Windows. OCSP and OCSP stapling are currently higher on my wish list than this. Charles -Original Message- From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Michael Wojcik Sent: Monday, December 3, 2018 10:58 AM To: openssl-users@openssl.org Subject: Re: [openssl-users] Question on necessity of SSL_CTX_set_client_CA_list > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of Charles Mills > Sent: Monday, December 03, 2018 10:55 > > Got it. Thanks. I would think the basic client case is "one certificate, one CA" I'm going to disagree somewhat with this assumption, but not necessarily with your decision. That assumption is probably safe for some use cases, but not all. For example, Windows-based clients that use Microsoft's TLS implementation (SChannel, via CAPI or CNG or any of the various wrapper APIs, including the .NET Framework) have access to all the "personal" certificates in the Windows per-machine and per-user certificate stores. In a Windows domain environment, certificates may be added to those stores by central administration, as well as being created or added locally. So such clients could have quite a few client certificates available to them. Some other TLS implementations can optionally use the Windows certificate stores. I believe Netscape's NSS can be configured to do so, for example. A suitable JSSE provider is included with the standard Windows JRE and JDK distributions. And OpenSSL itself has a CAPI engine that can (probably) be used to pull client certificates from the Windows stores. (I say "probably" because when we went to use the OpenSSL CAPI engine some years ago, we ran into some issues caused by Microsoft's awkward provider mechanism and how it interacts with private-key storage, and I ended up enhancing the OpenSSL CAPI module in various ways. So I don't recall what exactly works with it out of the box.) There are other environments which similarly provide centralized storage of certificates (and corresponding private keys) to all clients. zOS does, for example, at least if you're using the RACF security provider. Perhaps more importantly, as Viktor noted, some clients won't send a certificate at all unless they have one signed by a CA on the server's list, or at least only if the server sends a non-empty list. The list is also useful for clients that want to help the user select from among a set of certificates. > so I think I will roll with what we have (especially since the product has been > out there for years with no reported problems in this area -- although I think > client certificate usage is rare) but keep the issue in mind if a problem comes > up. Despite what I wrote above, the important thing, of course, is what your users need. If they haven't needed a server that sends a CA list, there's a good chance they won't need one any time soon. Often there are better things to address first. TLS configuration is important, but certainly for the software projects I work on there are any number of important areas for further work. You can't do everything at once. -- Michael Wojcik Distinguished Engineer, Micro Focus -- 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
Re: [openssl-users] Question on necessity of SSL_CTX_set_client_CA_list
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of Charles Mills > Sent: Monday, December 03, 2018 10:55 > > Got it. Thanks. I would think the basic client case is "one certificate, one > CA" I'm going to disagree somewhat with this assumption, but not necessarily with your decision. That assumption is probably safe for some use cases, but not all. For example, Windows-based clients that use Microsoft's TLS implementation (SChannel, via CAPI or CNG or any of the various wrapper APIs, including the .NET Framework) have access to all the "personal" certificates in the Windows per-machine and per-user certificate stores. In a Windows domain environment, certificates may be added to those stores by central administration, as well as being created or added locally. So such clients could have quite a few client certificates available to them. Some other TLS implementations can optionally use the Windows certificate stores. I believe Netscape's NSS can be configured to do so, for example. A suitable JSSE provider is included with the standard Windows JRE and JDK distributions. And OpenSSL itself has a CAPI engine that can (probably) be used to pull client certificates from the Windows stores. (I say "probably" because when we went to use the OpenSSL CAPI engine some years ago, we ran into some issues caused by Microsoft's awkward provider mechanism and how it interacts with private-key storage, and I ended up enhancing the OpenSSL CAPI module in various ways. So I don't recall what exactly works with it out of the box.) There are other environments which similarly provide centralized storage of certificates (and corresponding private keys) to all clients. zOS does, for example, at least if you're using the RACF security provider. Perhaps more importantly, as Viktor noted, some clients won't send a certificate at all unless they have one signed by a CA on the server's list, or at least only if the server sends a non-empty list. The list is also useful for clients that want to help the user select from among a set of certificates. > so I think I will roll with what we have (especially since the product has > been > out there for years with no reported problems in this area -- although I think > client certificate usage is rare) but keep the issue in mind if a problem > comes > up. Despite what I wrote above, the important thing, of course, is what your users need. If they haven't needed a server that sends a CA list, there's a good chance they won't need one any time soon. Often there are better things to address first. TLS configuration is important, but certainly for the software projects I work on there are any number of important areas for further work. You can't do everything at once. -- Michael Wojcik Distinguished Engineer, Micro Focus -- 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
Got it. Thanks. I would think the basic client case is "one certificate, one CA" so I think I will roll with what we have (especially since the product has been out there for years with no reported problems in this area -- although I think client certificate usage is rare) but keep the issue in mind if a problem comes up. Charles -Original Message- From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Viktor Dukhovni Sent: Sunday, December 2, 2018 5:50 PM To: openssl-users@openssl.org Subject: Re: [openssl-users] Question on necessity of SSL_CTX_set_client_CA_list > On Dec 2, 2018, at 7:38 PM, Charles Mills wrote: > > I have an OpenSSL (v1.1.0f) server application that processes client > certificates. > > The doc for SSL_CTX_load_verify_locations() states “In server mode, when > requesting a client certificate, the server must send the list of CAs of > which it will accept client certificates. This list is not influenced by the > contents of CAfile or CApath and must explicitly be set using the > SSL_CTX_set_client_CA_list family of functions.” > > The application makes no calls to SSL_CTX_set_client_CA_list() yet receives > client certificates without errors. > > Can someone please explain the discrepancy. I’m especially wondering if I > have set a trap that will spring down the road: “yes it works, but if a user > does X then it will not work.” The default list is empty. Some client implementations, IIRC Java's TLS stack or at least some Java TLS toolkits, will not use a client certificate unless the server's list is non-empty, and perhaps may also require that it include a CA name that matches an issuer of their certificate. Other clients have but one default certificate and use it regardless of the server's CA list. Your mileage may vary. -- Viktor. -- 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
Re: [openssl-users] Question on necessity of SSL_CTX_set_client_CA_list
> On Dec 2, 2018, at 7:38 PM, Charles Mills wrote: > > I have an OpenSSL (v1.1.0f) server application that processes client > certificates. > > The doc for SSL_CTX_load_verify_locations() states “In server mode, when > requesting a client certificate, the server must send the list of CAs of > which it will accept client certificates. This list is not influenced by the > contents of CAfile or CApath and must explicitly be set using the > SSL_CTX_set_client_CA_list family of functions.” > > The application makes no calls to SSL_CTX_set_client_CA_list() yet receives > client certificates without errors. > > Can someone please explain the discrepancy. I’m especially wondering if I > have set a trap that will spring down the road: “yes it works, but if a user > does X then it will not work.” The default list is empty. Some client implementations, IIRC Java's TLS stack or at least some Java TLS toolkits, will not use a client certificate unless the server's list is non-empty, and perhaps may also require that it include a CA name that matches an issuer of their certificate. Other clients have but one default certificate and use it regardless of the server's CA list. Your mileage may vary. -- 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
Do I need to say no calls to SSL_CTX_set_client_CA_list() nor any of the three related functions listed on the man page? Charles From: Charles Mills [mailto:charl...@mcn.org] Sent: Sunday, December 2, 2018 4:38 PM To: 'openssl-users@openssl.org' Subject: Question on necessity of SSL_CTX_set_client_CA_list I have an OpenSSL (v1.1.0f) server application that processes client certificates. The doc for SSL_CTX_load_verify_locations() states "In server mode, when requesting a client certificate, the server must send the list of CAs of which it will accept client certificates. This list is not influenced by the contents of CAfile or CApath and must explicitly be set using the SSL_CTX_set_client_CA_list family of functions." The application makes no calls to SSL_CTX_set_client_CA_list() yet receives client certificates without errors. Can someone please explain the discrepancy. I'm especially wondering if I have set a trap that will spring down the road: "yes it works, but if a user does X then it will not work." Thanks! Charles -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
