Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On 01/11/13 23:00, fhw...@gmail.com wrote: > Or to put it another way, everyone could stop issuing CRLs immediately > and have no appreciable impact on Internet security. I think that would > surprise many people. I don't think that's true, because direct client download of the CRL is not the only mechanism by which information in CRLs could get to clients. See Google's CRLsets, for example. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On 11/02/2013 02:00 AM, From Brian Smith: Does the end-entity certificate have an EV policy OID from any of our EV CAs? If so, verify that the certificate is valid for that policy OID, trusting only that CA's root. During this validation, check OCSP, and fall back to CRLs using CRLDP. Thanks for confirming this, Brian. The normal certificate checking path does not do CRL fetching, and it *never* has. So, for any CA that isn't in our EV program, Firefox has never done CRL fetching. But the code would actually exist to do that in that case. The CABForum EV guidelines have required EV CAs to support OCSP for a very long time. Absolutely. So, there's no justification for Firefox to fall back to CRL fetching for EV certificate verification any more. I don't really agree with that however - I've been an advocate to certificate status checking along the lines Firefox apparently has done for EV certificates. No infrastructure can be 100% perfect and for this I think the fallback to CRLs is quite useful. In numbers I assume that's small a minority and in case of EV I also assume that the CRLs are fairly thin, not affecting performance a lot. Of course I'd like to see this for all certificates, not only EV really. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On Fri, Nov 1, 2013 at 4:00 PM, wrote: > Seriously, though, anyone who has ever issued a CRL was basically wasting > valuable electrons on something that doesn't get used (by FF--don't know > about the others). > > Or to put it another way, everyone could stop issuing CRLs immediately and > have no appreciable impact on Internet security. I think that would > surprise many people. > I agree with everything quoted above. Don't waste your time with CRLs if you care only about browsers. Work on deploying OCSP stapling if you think revocation checking is important. Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On Fri, Nov 1, 2013 at 4:29 PM, wrote: > And...this is a great way for hackers, fraudsters, and the NSA (is there > a difference?) to attack users of Firefox. All I have to do is steal a > private key, grab the cert chain, and I can go about setting up a fake site > that will ensnare hapless surfers. It might not be a perfect attack but it > doesn't need to be in order to be "successful". > Hi, I suggest that you go back and re-read my earlier messages in this thread. It isn't black-and-white. Basically, all this revocation checking stuff--OCSP and CRLs--are mostly giving people a false sense of security. I have found that, whenever I explain to people exactly how it works, and more importantly when and how it *doesn't* work, most people tend to agree that it is a waste of effort for us to be doing OCSP or CRL fetching at all. > I keep looking for someone at Mozilla to say this is a big deal and that > it can be fixed by a date certain. Instead all I've been able to gather is > that they will implement a better solution at some point and then...? > We are actively implementing better solutions now. We're working to make OCSP stapling work. We're actively working on Must-Staple functionality to make revocation checking clearly meaningful in terms of security. We're working (on this mailing list) with CAs to define when and how CAs notify us about security-critical revocations, to work around the serious deficiencies in how browsers (not just Firefox) have done revocation checking through OCSP and CRL fetching. If I may speak frankly, for once: The transition from revocation checking mechanisms that almost never do anything useful to revocation checking mechanisms that are reliable and effective is not going to be 100% smooth. We need to be willing to break some eggs and take some risks in order to get to a better, reasonable, place. We (Firefox, Chrome, and other browsers) are not in a reasonable place now. Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On Fri, Nov 1, 2013 at 2:08 PM, Eddy Nigg wrote: > On 10/31/2013 09:41 PM, From Kathleen Wilson: >> >> That's true for non-EV. >> >> The validation path for EV is different. > > Which developer can confirm this? Where is the code for it? It's just news > for me and I'm a bit surprised, but enterily possible. Here is the logic we *currently* use: Does the end-entity certificate have an EV policy OID from any of our EV CAs? If so, verify that the certificate is valid for that policy OID, trusting only that CA's root. During this validation, check OCSP, and fall back to CRLs using CRLDP. If that validation succeeds, then return "Good EV certificate." If that validation fails, check the certificate using the normal certificate checking path. The normal certificate checking path does not do CRL fetching, and it *never* has. So, for any CA that isn't in our EV program, Firefox has never done CRL fetching. The CABForum EV guidelines have required EV CAs to support OCSP for a very long time. So, there's no justification for Firefox to fall back to CRL fetching for EV certificate verification any more. Accordingly, to avoid various problems that CRLs pose on us, our users, and on CAs, we'll stop doing the fallback to CRLs for EV certificates very soon. Once that happens, for all practical purposes, Firefox will not have anything to do with CRLs. The only exception is that, if you use some specialized tools to important CRLs into Firefox's certificate database, then Firefox will recognize those specially-imported CRLs for a while. However, it is likely that that will stop too, when we switch to the new certificate validation library. The source code for this is here: http://hg.mozilla.org/mozilla-central/annotate/ad2a5a4f53ec/security/manager/ssl/src/CertVerifier.cpp#l150 Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
And...this is a great way for hackers, fraudsters, and the NSA (is there a difference?) to attack users of Firefox. All I have to do is steal a private key, grab the cert chain, and I can go about setting up a fake site that will ensnare hapless surfers. It might not be a perfect attack but it doesn't need to be in order to be "successful".I keep looking for someone at Mozilla to say this is a big deal and that it can be fixed by a date certain. Instead all I've been able to gather is that they will implement a better solution at some point and then...? From: Eddy NiggSent: Friday, November 1, 2013 6:04 PMTo: mozilla-dev-security-pol...@lists.mozilla.orgSubject: Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?On 11/02/2013 01:00 AM, From fhw...@gmail.com:> Or to put it another way, everyone could stop issuing CRLs immediately > and have no appreciable impact on Internet security. I think that > would surprise many people. Obviously it would have an impact on other browsers and systems. But true, it wouldn't affect Firefox and friends (this time in the negative way). It's however nothing new, it would be news to me that it checks any CRL at all.-- RegardsSigner: Eddy Nigg, StartCom Ltd.XMPP:start...@startcom.orgBlog: http://blog.startcom.org/Twitter: http://twitter.com/eddy_nigg___dev-security-policy mailing listdev-security-policy@lists.mozilla.orghttps://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On 11/02/2013 01:00 AM, From fhw...@gmail.com: Or to put it another way, everyone could stop issuing CRLs immediately and have no appreciable impact on Internet security. I think that would surprise many people. Obviously it would have an impact on other browsers and systems. But true, it wouldn't affect Firefox and friends (this time in the negative way). It's however nothing new, it would be news to me that it checks any CRL at all. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
Perhaps instead I should have said it's a minus-seventeen-years exploit? :-) Seriously, though, anyone who has ever issued a CRL was basically wasting valuable electrons on something that doesn't get used (by FF--don't know about the others).Or to put it another way, everyone could stop issuing CRLs immediately and have no appreciable impact on Internet security. I think that would surprise many people. From: Eddy NiggSent: Friday, November 1, 2013 5:48 PMTo: mozilla-dev-security-pol...@lists.mozilla.orgSubject: Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?On 11/02/2013 12:32 AM, From fhw...@gmail.com:> So if this really is the case, it seems to me that this constitutes a > zero day vulnerability in Firefox. I don't mean to sound alarmist > but...???>It's not since it's always been like this and one of the reasons CAs must provide OCSP revocation capability. It would be however /nice/ to have a CRL fallback...-- RegardsSigner: Eddy Nigg, StartCom Ltd.XMPP:start...@startcom.orgBlog: http://blog.startcom.org/Twitter: http://twitter.com/eddy_nigg___dev-security-policy mailing listdev-security-policy@lists.mozilla.orghttps://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On 11/02/2013 12:32 AM, From fhw...@gmail.com: So if this really is the case, it seems to me that this constitutes a zero day vulnerability in Firefox. I don't mean to sound alarmist but...??? It's not since it's always been like this and one of the reasons CAs must provide OCSP revocation capability. It would be however /nice/ to have a CRL fallback... -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
So if this really is the case, it seems to me that this constitutes a zero day vulnerability in Firefox. I don't mean to sound alarmist but...??? From: Eddy NiggThanks for confirming -Kathleen, Firefox by default doesn't use CRLs. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On 10/31/2013 09:41 PM, From Kathleen Wilson: That's true for non-EV. The validation path for EV is different. Which developer can confirm this? Where is the code for it? It's just news for me and I'm a bit surprised, but enterily possible. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On 10/31/2013 04:40 PM, From Jean-Marc Desperrier: Eddy Nigg a écrit : If Firefox really uses the CRLDP No, it has never used the CRLDP to download the CRL. People need to import the CRL manually and then activate the auto-update, and nobody does it. What's more if the CRL becomes outdated for some reason, there will be no warning. Thanks for confirming -Kathleen, Firefox by default doesn't use CRLs. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On 10/31/13 7:40 AM, Jean-Marc Desperrier wrote: Eddy Nigg a écrit : If Firefox really uses the CRLDP No, it has never used the CRLDP to download the CRL. People need to import the CRL manually and then activate the auto-update, and nobody does it. What's more if the CRL becomes outdated for some reason, there will be no warning. That's true for non-EV. The validation path for EV is different. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
Eddy Nigg a écrit : If Firefox really uses the CRLDP No, it has never used the CRLDP to download the CRL. People need to import the CRL manually and then activate the auto-update, and nobody does it. What's more if the CRL becomes outdated for some reason, there will be no warning. The effective solution is rather to implement support for Google's CRLSets within the Mozilla products : https://sites.google.com/a/chromium.org/dev/Home/chromium-security/crlsets ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On 10/29/2013 04:26 PM, From Gervase Markham: To illuminate the debate: are you able to quote a case study from the Web PKI where a relying party has successfully claimed on such a warranty? And if not can we remove SSL please from the browsers? We don't need that in that case since nobody was a victim (of a system that apparently seems to work) who had to make claims against a CA. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On 28/10/13 19:27, Stephen Davidson wrote: > Virtually every CA relying party agreement (RPA) that I know > stipulates that a user must validate the SSL using CRL or OCSP in > order to place any reliance on the certificate. > > Removal of that capability from browsers renders those RPAs useless, > and effectively removes warranties from the SSL sector. To illuminate the debate: are you able to quote a case study from the Web PKI where a relying party has successfully claimed on such a warranty? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On 10/28/2013 09:51 PM, From Brian Smith: On Mon, Oct 28, 2013 at 12:27 PM, Stephen Davidson wrote: Virtually every CA relying party agreement (RPA) that I know stipulates that a user must validate the SSL using CRL or OCSP in order to place any reliance on the certificate. Removal of that capability from browsers renders those RPAs useless, and effectively removes warranties from the SSL sector. Aren't these RPAs already useless? Anyway, AFAICT Mozilla didn't agree to any RPA agreement with any CA. Also, our users have not agreed to any such agreements. Perhaps it worthwhile to clarify this by forbidding such requirements on relying parties as part of our CA policy. Actually you did by adding a root who's policy Mozilla ought to know fairly well. Mozilla is a relying and/or acts as a relying party on parts of the obligations and on behalf of the user. A user using a software that doesn't check revocation (knowingly) may NOT rely on a certificate. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On Mon, Oct 28, 2013 at 12:54 PM, Jeremy Rowley wrote: > Depends on what you mean by "matter". I'd say it matters to a FireFox user > to know whether a site has the potential for a MITM attack even if the MITM > attack isn't currently underway. Why? Let's say we had a system that could perfectly prevent every attack, but it could only do so at the exact instant that an attack took place. Would you consider that to be an unacceptable alternative to the current system? Or, are you just saying that, given the flaws in the current system, it is better to be proactive about revocation checking. > You said "No harm, no foul", but that > assumes no harm only encompasses immediate harm instead of both immediate > and potential harm. There is harm by allowing a revoked certificate to > continue to be trusted even if that harm is not immediately recognized. There's always some potential for a MITM attack even if we did hard-fail revocation checking on every connection. So, the question isn't whether there's potential for a MitM attack, but whether there's potential for a MitM attack that revocation checking would actually be able to prevent. That means we need to consider how realistic it is for such an attack to take place, and how likely it is that a revocation check would prevent that attack. I hope you can understand how a software engineer would have trouble arguing in favor of such an expensive feature as CRL fetching (or even OCSP fetching) without a valid argument in favor of doing it. Right now we're lacking valid arguments for doing it. Cheers, Brian ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
Depends on what you mean by "matter". I'd say it matters to a FireFox user to know whether a site has the potential for a MITM attack even if the MITM attack isn't currently underway. You said "No harm, no foul", but that assumes no harm only encompasses immediate harm instead of both immediate and potential harm. There is harm by allowing a revoked certificate to continue to be trusted even if that harm is not immediately recognized. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Brian Smith Sent: Monday, October 28, 2013 1:43 PM To: Jeremy Rowley Cc: dev-security-policy@lists.mozilla.org; Rick Andrews Subject: Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences? On Mon, Oct 28, 2013 at 12:28 PM, Jeremy Rowley wrote: > There are lots of occasions: > 1) Where a server with a private key is missing but there isn't yet an > active attack > 2) Where the key was compromised > 3) Where an error occurred and the certificate information identified > the wrong entity > 4) Where the certificate was issued in accordance with the > then-applicable standards but standards have made the certificate > untrustworthy (internal names, 1024, SHA1) > 5) Where the certificate profile is incorrect (lacks the appropriate > EKU or requested with incomplete information) > > All of these are security concerns that don't have an active attacker > and where even a soft-fail revocation effectively mitigates the risk. Those all seem like valid reasons to revoke a certificate. But, those aren't reasons for checking that a certificate has been revoked. In order for the revocation to actually matter to a normal Firefox user, the user must find himself in a scenerio like the one I previously described, right? Cheers, Brian > -Original Message- > From: dev-security-policy > [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.m > ozilla > .org] On Behalf Of Brian Smith > Sent: Monday, October 28, 2013 1:14 PM > To: Rick Andrews > Cc: dev-security-policy@lists.mozilla.org > Subject: Re: Netcraft blog, violations of CABF Baseline Requirements, > any consequences? > > On Mon, Oct 28, 2013 at 11:31 AM, Rick Andrews > > wrote: >> Brian, you seem to be saying that revocation checking adds value only >> when > there's an attacker involved. If that's your point, I disagree. There > are cases in which a CA revokes a certificate because the site has > misrepresented itself, and revocation serves as a warning to the client. > > Thanks for the clarification. Could you give an example where such a > revocation would be useful to know about to a Firefox user to the > extent where the cost of doing the revocation checking is justified? > So far, I'm of the opinion when there's no attacker, there's no > problem (no harm, no foul). > > Cheers, > Brian > -- > Mozilla Networking/Crypto/Security (Necko/NSS/PSM) > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On Mon, Oct 28, 2013 at 12:27 PM, Stephen Davidson wrote: > Virtually every CA relying party agreement (RPA) that I know stipulates that > a user must validate the SSL using CRL or OCSP in order to place any reliance > on the certificate. > > Removal of that capability from browsers renders those RPAs useless, and > effectively removes warranties from the SSL sector. Aren't these RPAs already useless? Anyway, AFAICT Mozilla didn't agree to any RPA agreement with any CA. Also, our users have not agreed to any such agreements. Perhaps it worthwhile to clarify this by forbidding such requirements on relying parties as part of our CA policy. Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On Mon, Oct 28, 2013 at 12:28 PM, Jeremy Rowley wrote: > There are lots of occasions: > 1) Where a server with a private key is missing but there isn't yet an > active attack > 2) Where the key was compromised > 3) Where an error occurred and the certificate information identified the > wrong entity > 4) Where the certificate was issued in accordance with the then-applicable > standards but standards have made the certificate untrustworthy (internal > names, 1024, SHA1) > 5) Where the certificate profile is incorrect (lacks the appropriate EKU or > requested with incomplete information) > > All of these are security concerns that don't have an active attacker and > where even a soft-fail revocation effectively mitigates the risk. Those all seem like valid reasons to revoke a certificate. But, those aren't reasons for checking that a certificate has been revoked. In order for the revocation to actually matter to a normal Firefox user, the user must find himself in a scenerio like the one I previously described, right? Cheers, Brian > -Original Message- > From: dev-security-policy > [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla > .org] On Behalf Of Brian Smith > Sent: Monday, October 28, 2013 1:14 PM > To: Rick Andrews > Cc: dev-security-policy@lists.mozilla.org > Subject: Re: Netcraft blog, violations of CABF Baseline Requirements, any > consequences? > > On Mon, Oct 28, 2013 at 11:31 AM, Rick Andrews > wrote: >> Brian, you seem to be saying that revocation checking adds value only when > there's an attacker involved. If that's your point, I disagree. There are > cases in which a CA revokes a certificate because the site has > misrepresented itself, and revocation serves as a warning to the client. > > Thanks for the clarification. Could you give an example where such a > revocation would be useful to know about to a Firefox user to the extent > where the cost of doing the revocation checking is justified? > So far, I'm of the opinion when there's no attacker, there's no problem (no > harm, no foul). > > Cheers, > Brian > -- > Mozilla Networking/Crypto/Security (Necko/NSS/PSM) > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
Of course, hard-fail will always provide a more robust mitigation mechanism. However, with browsers unwilling to provide hard fail, notification of a suspected problem/risk is preferable to none. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Jeremy Rowley Sent: Monday, October 28, 2013 1:29 PM To: 'Brian Smith'; 'Rick Andrews' Cc: dev-security-policy@lists.mozilla.org Subject: RE: Netcraft blog, violations of CABF Baseline Requirements, any consequences? There are lots of occasions: 1) Where a server with a private key is missing but there isn't yet an active attack 2) Where the key was compromised 3) Where an error occurred and the certificate information identified the wrong entity 4) Where the certificate was issued in accordance with the then-applicable standards but standards have made the certificate untrustworthy (internal names, 1024, SHA1) 5) Where the certificate profile is incorrect (lacks the appropriate EKU or requested with incomplete information) All of these are security concerns that don't have an active attacker and where even a soft-fail revocation effectively mitigates the risk. Jeremy -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Brian Smith Sent: Monday, October 28, 2013 1:14 PM To: Rick Andrews Cc: dev-security-policy@lists.mozilla.org Subject: Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences? On Mon, Oct 28, 2013 at 11:31 AM, Rick Andrews wrote: > Brian, you seem to be saying that revocation checking adds value only > when there's an attacker involved. If that's your point, I disagree. There are cases in which a CA revokes a certificate because the site has misrepresented itself, and revocation serves as a warning to the client. Thanks for the clarification. Could you give an example where such a revocation would be useful to know about to a Firefox user to the extent where the cost of doing the revocation checking is justified? So far, I'm of the opinion when there's no attacker, there's no problem (no harm, no foul). Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
There are lots of occasions: 1) Where a server with a private key is missing but there isn't yet an active attack 2) Where the key was compromised 3) Where an error occurred and the certificate information identified the wrong entity 4) Where the certificate was issued in accordance with the then-applicable standards but standards have made the certificate untrustworthy (internal names, 1024, SHA1) 5) Where the certificate profile is incorrect (lacks the appropriate EKU or requested with incomplete information) All of these are security concerns that don't have an active attacker and where even a soft-fail revocation effectively mitigates the risk. Jeremy -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Brian Smith Sent: Monday, October 28, 2013 1:14 PM To: Rick Andrews Cc: dev-security-policy@lists.mozilla.org Subject: Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences? On Mon, Oct 28, 2013 at 11:31 AM, Rick Andrews wrote: > Brian, you seem to be saying that revocation checking adds value only when there's an attacker involved. If that's your point, I disagree. There are cases in which a CA revokes a certificate because the site has misrepresented itself, and revocation serves as a warning to the client. Thanks for the clarification. Could you give an example where such a revocation would be useful to know about to a Firefox user to the extent where the cost of doing the revocation checking is justified? So far, I'm of the opinion when there's no attacker, there's no problem (no harm, no foul). Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
Virtually every CA relying party agreement (RPA) that I know stipulates that a user must validate the SSL using CRL or OCSP in order to place any reliance on the certificate. Removal of that capability from browsers renders those RPAs useless, and effectively removes warranties from the SSL sector. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+s.davidson=quovadisglobal@lists.mozilla.org] On Behalf Of Brian Smith Sent: Monday, October 28, 2013 4:15 PM To: Rick Andrews Cc: dev-security-policy@lists.mozilla.org Subject: Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences? On Mon, Oct 28, 2013 at 11:31 AM, Rick Andrews wrote: > Brian, you seem to be saying that revocation checking adds value only when > there's an attacker involved. If that's your point, I disagree. There are > cases in which a CA revokes a certificate because the site has misrepresented > itself, and revocation serves as a warning to the client. Thanks for the clarification. Could you give an example where such a revocation would be useful to know about to a Firefox user to the extent where the cost of doing the revocation checking is justified? So far, I'm of the opinion when there's no attacker, there's no problem (no harm, no foul). Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On Mon, Oct 28, 2013 at 11:31 AM, Rick Andrews wrote: > Brian, you seem to be saying that revocation checking adds value only when > there's an attacker involved. If that's your point, I disagree. There are > cases in which a CA revokes a certificate because the site has misrepresented > itself, and revocation serves as a warning to the client. Thanks for the clarification. Could you give an example where such a revocation would be useful to know about to a Firefox user to the extent where the cost of doing the revocation checking is justified? So far, I'm of the opinion when there's no attacker, there's no problem (no harm, no foul). Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
Brian, you seem to be saying that revocation checking adds value only when there's an attacker involved. If that's your point, I disagree. There are cases in which a CA revokes a certificate because the site has misrepresented itself, and revocation serves as a warning to the client. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On Fri, Oct 25, 2013 at 1:47 PM, Rick Andrews wrote: > I agree with Jeremy that there are security benefits to revocation checking, > even without hard-fail, and that they are not illusions. If a CA can serve an > OCSP response to a browser before the browser gives up, the user may be > alerted to a revoked certificate and may then choose to avoid the web site. A > number of CAs have been actively working to improve the performance of their > CA infrastructures, and have made significant improvements. Could you please quantify the security gain of soft-fail revocation fetching? How often is it the case where ALL of the these are true: 0. The attacker is using a certificate that is valid in all respects EXCEPT it has been revoked. 1. The attacker can manipulate the connection between the browser and the website the user is visiting 2. The attacker CANNOT block an OCSP request or the response 3. The attacker does not have access to a non-expired OCSP response for the certificate it is using? (Often these are valid for up to 10 days, so an attacker could use an OCSP response that is up to 10 days old.) 4. The attacker cannot trick the browser into reporting an overridable cert error (e.g. by omitting the intermediate certificate from the cert chain, or by using an expired certificate for which revocation information is no longer available) that would mask/prevent the detection of the revocation OR the user would not click through the cert errror? 5. The attack results in non-trivial injury to the end-user. For example, a user who is curious about the LavaBit incident, but not a LavaBit user, and browsed to https://lavabit.com without getting the "revoked" error is not injured. An actual LavaBit uesr would be. Perhaps a good proxy for this would be "Could the end-user have a reasonable case for a lawsuit to recover damages?" 6. In the case of mis-issuance: the CA could not contact the browser vendor in time to have the browser vendor send out an update (CRLSet update, or whatever) to block the mis-issued certificate before the user was harmed. 7. Regarding CRLs: The revocation of the mis-used certificate is available via CRL but not via OCSP and the certificate is an EV certificate AND the CRL was of a reasonable size for a (mobile) browser to process. It isn't clear that this is, or is likely to become, a common enough occurrence to justify even the performance costs and other negative side effects of of OCSP fetching, let alone CRL fetching. I think it would be useful to look at a case study from the past where all of the above was true. Then we can explore what we could have done better in that scenerio. What case study could we use? Also, in this unlikely scenerio, who is at fault? Along the lines of a lawsuit, who would the end-user be likely to successfully sue for damages? If the CA mis-issued the certificate, it is clearly the CAs fault. CAs must not mis-issue certificates. If the CA knows that it must support OCSP for EV certificates and it chooses not to, it is clearly the CA's fault. If the website lost control of its private key, it is clearly the website's fault. Websites need to protect their private keys. OCSP and CRL fetching isn't free to users. We have to make sure that the costs of revocation checking are in line with the benefits. I don't see how the costs of CRL fetching are in line with the benefits that it provides now. Also, I think we can come up with better ways of getting the benefits while minimizing the costs to users, and that is exactly what I am working on along with others at Mozilla. Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On 10/25/2013 11:47 PM, From Rick Andrews: A number of CAs have been actively working to improve the performance of their CA infrastructures, and have made significant improvements. For reference: https://revocation-report.x509labs.com/ ( just that the cert expired there :-) ) -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
> Yes, surely only someone insidious and evil and who hates Freedom would > > ever support such an security-hostile idea as a 1-4KB OCSP response, > > rather than a 50MB CRL. It's likely that the Legion of Cryptographic Doom > > have compromised OCSP, likely using the World Bank to infiltrate the IETF > > with members of the Secret Illuminati (which even the regular Illuminati > > don't know about), and only CRLs can save us from the impending saucer > > people who will break our crypto and control our minds with houseplants. Please keep it civil, Ryan. I'm afraid you've stooped to the same level as the person you were criticizing. > > Please keep it civil, Michael, and please provide technical discussions, > > rather than emotional pleas or accusations. > > > > OCSP and CRLs both represent ways to obtain revocation information. Thus, > > for EV, it's should "always" be possible to obtain fresh information. > > > > CRLs and OCSP offer no security advantage unless enabled for 'hard fail', > > which cannot be enabled by default, and which few users (if any) have ever > > enabled. The security gains absent hard fail are illusions (... not > > tricks), and so Firefox, which was not implemented hard-fail by default > > and will not implement hard fail by default, it's a perfectly practical > > decision. I agree with Jeremy that there are security benefits to revocation checking, even without hard-fail, and that they are not illusions. If a CA can serve an OCSP response to a browser before the browser gives up, the user may be alerted to a revoked certificate and may then choose to avoid the web site. A number of CAs have been actively working to improve the performance of their CA infrastructures, and have made significant improvements. -Rick ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
Strongly disagree that the security benefits are illusions. Granted, they are not as great as with hard fail, but they do provide some benefits over absolutely no revocation mechanisms. Even with the soft-fail methods currently used, they at least require an extended isolation of the user from the revocation server. Jeremy -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Ryan Sleevi Sent: Thursday, October 24, 2013 4:46 PM To: "Michael Ströder" Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences? On Thu, October 24, 2013 2:47 pm, Michael Ströder wrote: > Kathleen Wilson wrote: > > In the case of EV certs, Mozilla is still checking the CRL when the > > OCSP URI is not provided. > > Which CRL? Where does it come from? > > > Though, I believe the plan is to stop checking CRL in the future... > > https://bugzilla.mozilla.org/show_bug.cgi?id=585122#c34 > > "Instead of checking explicitly for an OCSP responder URI in the AIA > > extension, let's simply remove the support for downloading CRLs from > > Firefox's EV checking. That will have the effect of enforcing that > > all certs in the chain have an OCSP AIA extension, except possibly > > for the end-entity certificate if the server stapled the end-entity > > OCSP response. I agree with the CA representatives that a missing > > OCSP AIA URL isn't harmful when a stapled OCSP response is provided. > > So, I am OK with allowing that exception, at least for now." > > Anyone writing such a non-sense surely is on NSA's payroll. > > Ciao, Michael. > Yes, surely only someone insidious and evil and who hates Freedom would ever support such an security-hostile idea as a 1-4KB OCSP response, rather than a 50MB CRL. It's likely that the Legion of Cryptographic Doom have compromised OCSP, likely using the World Bank to infiltrate the IETF with members of the Secret Illuminati (which even the regular Illuminati don't know about), and only CRLs can save us from the impending saucer people who will break our crypto and control our minds with houseplants. Please keep it civil, Michael, and please provide technical discussions, rather than emotional pleas or accusations. OCSP and CRLs both represent ways to obtain revocation information. Thus, for EV, it's should "always" be possible to obtain fresh information. CRLs and OCSP offer no security advantage unless enabled for 'hard fail', which cannot be enabled by default, and which few users (if any) have ever enabled. The security gains absent hard fail are illusions (... not tricks), and so Firefox, which was not implemented hard-fail by default and will not implement hard fail by default, it's a perfectly practical decision. If you would like to discuss the technical concerns behind such a thing, might I encourage you to discuss on mozilla.dev.tech.crypto - or with the Firefox developers - focusing on technical arguments rather than accusing people of having some hidden agenda to harm the Internet? Or I suppose I'm also on the NSA payroll for suggesting at this point, you're sounding like a troll, rather than an informed user? Cheers, Ryan ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On 10/24/13 11:45 AM, Eddy Nigg wrote: On 10/24/2013 08:01 PM, From Kathleen Wilson: For EV certs Firefox has always checked the CRL when the OCSP AIA URI was not provided. EV treatment would not be given if current revocation information was not obtained. If Firefox really uses the CRLDP, then I suggest to keep that option still open meaning if no stapled OCSP response, use the normal pointers and if that fails use CRL. Remove EV (and the "secure" UI indicators if you want from any other certificate) when certificate status can't be verified. Please feel free to comment in bug #585122. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On Thu, October 24, 2013 2:47 pm, Michael Ströder wrote: > Kathleen Wilson wrote: > > In the case of EV certs, Mozilla is still checking the CRL when the OCSP > > URI > > is not provided. > > Which CRL? Where does it come from? > > > Though, I believe the plan is to stop checking CRL in the > > future... > > https://bugzilla.mozilla.org/show_bug.cgi?id=585122#c34 > > "Instead of checking explicitly for an OCSP responder URI in the AIA > > extension, let's simply remove the support for downloading CRLs from > > Firefox's > > EV checking. That will have the effect of enforcing that all certs in > > the > > chain have an OCSP AIA extension, except possibly for the end-entity > > certificate if the server stapled the end-entity OCSP response. I agree > > with > > the CA representatives that a missing OCSP AIA URL isn't harmful when a > > stapled OCSP response is provided. So, I am OK with allowing that > > exception, > > at least for now." > > Anyone writing such a non-sense surely is on NSA's payroll. > > Ciao, Michael. > Yes, surely only someone insidious and evil and who hates Freedom would ever support such an security-hostile idea as a 1-4KB OCSP response, rather than a 50MB CRL. It's likely that the Legion of Cryptographic Doom have compromised OCSP, likely using the World Bank to infiltrate the IETF with members of the Secret Illuminati (which even the regular Illuminati don't know about), and only CRLs can save us from the impending saucer people who will break our crypto and control our minds with houseplants. Please keep it civil, Michael, and please provide technical discussions, rather than emotional pleas or accusations. OCSP and CRLs both represent ways to obtain revocation information. Thus, for EV, it's should "always" be possible to obtain fresh information. CRLs and OCSP offer no security advantage unless enabled for 'hard fail', which cannot be enabled by default, and which few users (if any) have ever enabled. The security gains absent hard fail are illusions (... not tricks), and so Firefox, which was not implemented hard-fail by default and will not implement hard fail by default, it's a perfectly practical decision. If you would like to discuss the technical concerns behind such a thing, might I encourage you to discuss on mozilla.dev.tech.crypto - or with the Firefox developers - focusing on technical arguments rather than accusing people of having some hidden agenda to harm the Internet? Or I suppose I'm also on the NSA payroll for suggesting at this point, you're sounding like a troll, rather than an informed user? Cheers, Ryan ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
Kathleen Wilson wrote: > In the case of EV certs, Mozilla is still checking the CRL when the OCSP URI > is not provided. Which CRL? Where does it come from? > Though, I believe the plan is to stop checking CRL in the > future... > https://bugzilla.mozilla.org/show_bug.cgi?id=585122#c34 > "Instead of checking explicitly for an OCSP responder URI in the AIA > extension, let's simply remove the support for downloading CRLs from Firefox's > EV checking. That will have the effect of enforcing that all certs in the > chain have an OCSP AIA extension, except possibly for the end-entity > certificate if the server stapled the end-entity OCSP response. I agree with > the CA representatives that a missing OCSP AIA URL isn't harmful when a > stapled OCSP response is provided. So, I am OK with allowing that exception, > at least for now." Anyone writing such a non-sense surely is on NSA's payroll. Ciao, Michael. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
Kathleen Wilson wrote: >> And since CRL support was dropped in recent Firefox/Seamonkey >> releases there's >> no revocation checking mechanism for those certs at all. > > That's not technically accurate for EV certificates. The user interface to > manually import CRLs was dropped, but CRLs are still being checked. Currently > for EV certs, if the OCSP URI is not present, then the CRL is checked. ??? Yes, the CRL import UI was dropped and AFAIK there's no support for CRLDP extension. So how is the right CRL imported? Ciao, Michael. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On 10/24/2013 08:01 PM, From Kathleen Wilson: For EV certs Firefox has always checked the CRL when the OCSP AIA URI was not provided. EV treatment would not be given if current revocation information was not obtained. If Firefox really uses the CRLDP, then I suggest to keep that option still open meaning if no stapled OCSP response, use the normal pointers and if that fails use CRL. Remove EV (and the "secure" UI indicators if you want from any other certificate) when certificate status can't be verified. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On 10/23/13 3:14 PM, Eddy Nigg wrote: In the case of EV certs, Mozilla is still checking the CRL when the OCSP URI is not provided. Since when does Firefox check CRLs? I believe it never did except if configured manually (which is probably almost never). For EV certs Firefox has always checked the CRL when the OCSP AIA URI was not provided. EV treatment would not be given if current revocation information was not obtained. However, the code change to remove the CRL check is now targeted for Firefox 28. https://bugzilla.mozilla.org/show_bug.cgi?id=585122#c34 This will have the affect of requiring OCSP for EV certs. If a valid OCSP response is not obtained (either via OCSP stapling or via the OCSP AIA URI), then EV treatment will not be given. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On 10/24/2013 08:30 AM, From Ben Wilson: So long story short, yes, the OCSP URI does need to be in the AIA of the certificate. Thanks Ben, that's perfect. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
>>On 10/23/13 12:31 PM, Kathleen Wilson wrote: >>> On 10/22/13 1:19 PM, Eddy Nigg wrote: >>> >>> I've been on the sidelines for most of this and other discussions >>> here, however I don't think this is correct at all - if the server >>> doesn't provide a correct stapled response, the browser must still be >>> able to find the OCSP response on its own. Additionally servers >>> usually will use the exact same information to find a valid OCSP >>> response to include as a browser would, and this response must be fairly frequently updated too. >>> Except if the server admin bothers to configure that manually which I >>> doubt over the longer term for most. >> >> >> I'm not sure I understand your message. Are you saying that even if >> OCSP stapling is used, the certs must have the OCSP URI in them, in >> case the server's stapled response doesn't work, and the browser needs >> to fallback to the OCSP URI in the cert? >> Kathleen and Eddy, As you and others may know, but for the benefit of others, I have a draft ballot with the CA/Browser Forum (Ballot 103) to clarify a nuance that I believe was incorrectly expressed concerning OCSP stapling when the Baseline Requirements were adopted. Soon after adoption, we created a punch-list of items to fix. Issue 7 was to clarify the use of the AIA for OCSP and make it a firm requirement.) Section 13.2.1 and Appendix B of the BRs contemplated that OCSP stapling could be used instead of the OCSP AIA for "high traffic sites" if the CA and the Server could ensure that the OCSP response was stapled. However, existing client capabilities were not adequately discussed or addressed, including several important facts - this works only where the server can confirm that all browsers connecting (via the certificate without the OCSP AIA) support stapling; that it might work if the site could control which browsers were used to connect to the site; that the most efficient known way for a server to support OCSP stapling is to obtain fresh OCSP responses using the AIA URI contained in the certificate itself; the browser needs to be able to fall back to the OCSP URI if the server fails to staple; and that the benefits of putting the AIA for OCSP in the certificate far outweigh any perceived benefit of leaving it out. Some may argue that compliance with section 13.2.1 is theoretically possible, but I am not aware of any CA-subscriber combination that can claim full compliance -- especially since OCSP stapling, this exception, and the BRs themselves are relatively new. So long story short, yes, the OCSP URI does need to be in the AIA of the certificate. Thanks, Ben smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On 10/23/2013 10:31 PM, From Kathleen Wilson: I'm not sure I understand your message. Are you saying that even if OCSP stapling is used, the certs must have the OCSP URI in them, in case the server's stapled response doesn't work, and the browser needs to fallback to the OCSP URI in the cert? Yes, exactly. Also servers can be configured the easiest by having it simply use the included OCSP URI in the certificate. In the case of EV certs, Mozilla is still checking the CRL when the OCSP URI is not provided. Since when does Firefox check CRLs? I believe it never did except if configured manually (which is probably almost never). Are you saying that (instead of the above proposal) the revocation checking should do the following? 1) Check for OCSP stapling response from server. 2) If cannot get a valid OCSP stapling response, then use OCSP URI in AIA to try to get OCSP response. 3) If these attempts fail, then check CRL. 4) If both OCSP and CRL fail, then EV treatment will not be given. That really would be perfect (I think the best it can get with current implementations). However IMO the fallback to normal OCSP is a must. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On 10/23/13 12:31 PM, Kathleen Wilson wrote: On 10/22/13 1:19 PM, Eddy Nigg wrote: I've been on the sidelines for most of this and other discussions here, however I don't think this is correct at all - if the server doesn't provide a correct stapled response, the browser must still be able to find the OCSP response on its own. Additionally servers usually will use the exact same information to find a valid OCSP response to include as a browser would, and this response must be fairly frequently updated too. Except if the server admin bothers to configure that manually which I doubt over the longer term for most. I'm not sure I understand your message. Are you saying that even if OCSP stapling is used, the certs must have the OCSP URI in them, in case the server's stapled response doesn't work, and the browser needs to fallback to the OCSP URI in the cert? There IS a significant risk if a certificate can't be revoked, this isn't just about EV treatment. Stapling or not still requires to provide a source to check for the certificates status independently, both for the server AND in case stapling fails for this or the other reason (outdated, wrong etc.). Again, not sure if I'm understanding your message. In the case of EV certs, Mozilla is still checking the CRL when the OCSP URI is not provided. Though, I believe the plan is to stop checking CRL in the future... https://bugzilla.mozilla.org/show_bug.cgi?id=585122#c34 "Instead of checking explicitly for an OCSP responder URI in the AIA extension, let's simply remove the support for downloading CRLs from Firefox's EV checking. That will have the effect of enforcing that all certs in the chain have an OCSP AIA extension, except possibly for the end-entity certificate if the server stapled the end-entity OCSP response. I agree with the CA representatives that a missing OCSP AIA URL isn't harmful when a stapled OCSP response is provided. So, I am OK with allowing that exception, at least for now." Are you saying that (instead of the above proposal) the revocation checking should do the following? 1) Check for OCSP stapling response from server. 2) If cannot get a valid OCSP stapling response, then use OCSP URI in AIA to try to get OCSP response. 3) If these attempts fail, then check CRL. 4) If both OCSP and CRL fail, then EV treatment will not be given. Regards, Kathleen Unfortunately, OCSP stapling support has been delayed due to issues that recently were found. https://bugzilla.mozilla.org/show_bug.cgi?id=929617 There is discussion about this in CAB Forum Public list (pub...@cabforum.org) "We added support for OCSP stapling to Firefox 25 (beta) and we just had to temporarily disable it right before the Firefox 25 release because of interoperability issues. ..." Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On 10/22/13 1:19 PM, Eddy Nigg wrote: I've been on the sidelines for most of this and other discussions here, however I don't think this is correct at all - if the server doesn't provide a correct stapled response, the browser must still be able to find the OCSP response on its own. Additionally servers usually will use the exact same information to find a valid OCSP response to include as a browser would, and this response must be fairly frequently updated too. Except if the server admin bothers to configure that manually which I doubt over the longer term for most. I'm not sure I understand your message. Are you saying that even if OCSP stapling is used, the certs must have the OCSP URI in them, in case the server's stapled response doesn't work, and the browser needs to fallback to the OCSP URI in the cert? There IS a significant risk if a certificate can't be revoked, this isn't just about EV treatment. Stapling or not still requires to provide a source to check for the certificates status independently, both for the server AND in case stapling fails for this or the other reason (outdated, wrong etc.). Again, not sure if I'm understanding your message. In the case of EV certs, Mozilla is still checking the CRL when the OCSP URI is not provided. Though, I believe the plan is to stop checking CRL in the future... https://bugzilla.mozilla.org/show_bug.cgi?id=585122#c34 "Instead of checking explicitly for an OCSP responder URI in the AIA extension, let's simply remove the support for downloading CRLs from Firefox's EV checking. That will have the effect of enforcing that all certs in the chain have an OCSP AIA extension, except possibly for the end-entity certificate if the server stapled the end-entity OCSP response. I agree with the CA representatives that a missing OCSP AIA URL isn't harmful when a stapled OCSP response is provided. So, I am OK with allowing that exception, at least for now." Are you saying that (instead of the above proposal) the revocation checking should do the following? 1) Check for OCSP stapling response from server. 2) If cannot get a valid OCSP stapling response, then use OCSP URI in AIA to try to get OCSP response. 3) If these attempts fail, then check CRL. 4) If both OCSP and CRL fail, then EV treatment will not be given. Regards, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On 10/22/2013 09:02 PM, From Kathleen Wilson: As I mentioned previously, I don't believe the lack of OCSP URI in those EV certificates was causing security risk to end users. Now that OCSP stapling is available, I think we should give Verizon a little bit of time to move their customers to OCSP. I've been on the sidelines for most of this and other discussions here, however I don't think this is correct at all - if the server doesn't provide a correct stapled response, the browser must still be able to find the OCSP response on its own. Additionally servers usually will use the exact same information to find a valid OCSP response to include as a browser would, and this response must be fairly frequently updated too. Except if the server admin bothers to configure that manually which I doubt over the longer term for most. There IS a significant risk if a certificate can't be revoked, this isn't just about EV treatment. Stapling or not still requires to provide a source to check for the certificates status independently, both for the server AND in case stapling fails for this or the other reason (outdated, wrong etc.). -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On 10/22/13 11:02 AM, Kathleen Wilson wrote: >> Another 10 days have passed without any apparent sign of Mozilla's >> willingness to address the case of the non-existence of an OCSP >> responder for the Cybertrust SureServer EV CA. Here is my opinion on this topic. I don't believe there was an additional security risk caused by Verizon not having the OCSP URI in their EV certificates, because Firefox will not give EV treatment if there is no fresh revocation information via CRL or OCSP. Verizon had been asking for OCSP stapling before being required to include the OCSP URI in the certs. Now that we have OCSP stapling implemented in Firefox 25, I think we should allow Verizon some time to move their customers from CRL to OCSP. I don't think it actually helps anyone to remove Verizon's EV treatment at this point in time. Many folks are of the opinion that EV treatment should be removed for a few months as some sort of punishment, but I'm not convinced that is actually necessary, because I think the negative PR that Verizon got is sufficient at this time. > > And since CRL support was dropped in recent Firefox/Seamonkey > releases there's > no revocation checking mechanism for those certs at all. > That's not technically accurate for EV certificates. The user interface to manually import CRLs was dropped, but CRLs are still being checked. Currently for EV certs, if the OCSP URI is not present, then the CRL is checked. EV treatment will not be given if current revocation status is not successfully retrieved. > >> Their EV issuing CA has been non-compliant >> for 2 years, 9 months, and 8 days by now. No wiggle room for any >> discussion about effective dates etc., they undisputably failed to >> implement a mandatory component of their revocation infrastructure >> (and were certainly aware of this requirement in 2009, see >> https://groups.google.com/d/msg/mozilla.dev.security.policy/x_cuezl71OI/lt-ftQ0jmFoJ) > In that post Steven also made his plea for OCSP stapling: "We left that meeting with a hope that ... we'd wait for TLS stapling of OCSP responses to emerge before mandating OCSP for UI indication of an Extended Validation process. OCSP stapling has only just recently become available: https://wiki.mozilla.org/CA:ImprovingRevocation#OCSP_Stapling "Release: Firefox 25" > >> So in the case of Verizon, why does Mozilla not proceed with >> removing their EV enablement? As I mentioned previously, I don't believe the lack of OCSP URI in those EV certificates was causing security risk to end users. Now that OCSP stapling is available, I think we should give Verizon a little bit of time to move their customers to OCSP. Additionally, Verizon may not be the only CA with this issue, so I think it is better that we solve it by enforcing it in code. https://bugzilla.mozilla.org/show_bug.cgi?id=585122#c34 2013-07-11 17:09:40 PDT "So, now we have OCSP stapling enabled. ... there is now a requirement that OCSP responders MUST NOT provide "good" responses for unknown certificates in effect; this is a feature that CRLs do not have. Therefore, I think we're more than justified in requiring that revocation information be provided by OCSP for EV certificates." Kathleen One more thing I want to point out... Verizon has been saying all along that they need more time on this OCSP requirement. As shown above, they requested things like OCSP stapling support in browsers back in 2009, and Mozilla only recently made that available. As a more recent example, look at Verizon's response to the January CA Communication (https://wiki.mozilla.org/CA:Communications#January_2013_Responses). They made it clear then that they are working hard to get OCSP implemented at all of their customer sites by May 15, 2014. You are correct, that the date does not match the dates imposed by the CAB Forum, but I don't really care about the specific date, so long as the CA is working hard to become compliant as soon as they can. As per Verizon's response to the CA Communication, they did not try to hide the fact that they would not be able to meet the CAB Forum's dates, but they specifically called out the areas that would be problematic for them, and gave dates that they are targeting. Given their situation, I believe the dates that they gave are reasonable, and I am fine with this approach. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
>> Another 10 days have passed without any apparent sign of Mozilla's >> willingness to address the case of the non-existence of an OCSP >> responder for the Cybertrust SureServer EV CA. Here is my opinion on this topic. I don't believe there was an additional security risk caused by Verizon not having the OCSP URI in their EV certificates, because Firefox will not give EV treatment if there is no fresh revocation information via CRL or OCSP. Verizon had been asking for OCSP stapling before being required to include the OCSP URI in the certs. Now that we have OCSP stapling implemented in Firefox 25, I think we should allow Verizon some time to move their customers from CRL to OCSP. I don't think it actually helps anyone to remove Verizon's EV treatment at this point in time. Many folks are of the opinion that EV treatment should be removed for a few months as some sort of punishment, but I'm not convinced that is actually necessary, because I think the negative PR that Verizon got is sufficient at this time. > > And since CRL support was dropped in recent Firefox/Seamonkey > releases there's > no revocation checking mechanism for those certs at all. > That's not technically accurate for EV certificates. The user interface to manually import CRLs was dropped, but CRLs are still being checked. Currently for EV certs, if the OCSP URI is not present, then the CRL is checked. EV treatment will not be given if current revocation status is not successfully retrieved. > >> Their EV issuing CA has been non-compliant >> for 2 years, 9 months, and 8 days by now. No wiggle room for any >> discussion about effective dates etc., they undisputably failed to >> implement a mandatory component of their revocation infrastructure >> (and were certainly aware of this requirement in 2009, see >> https://groups.google.com/d/msg/mozilla.dev.security.policy/x_cuezl71OI/lt-ftQ0jmFoJ) > In that post Steven also made his plea for OCSP stapling: "We left that meeting with a hope that ... we'd wait for TLS stapling of OCSP responses to emerge before mandating OCSP for UI indication of an Extended Validation process. OCSP stapling has only just recently become available: https://wiki.mozilla.org/CA:ImprovingRevocation#OCSP_Stapling "Release: Firefox 25" > >> So in the case of Verizon, why does Mozilla not proceed with >> removing their EV enablement? As I mentioned previously, I don't believe the lack of OCSP URI in those EV certificates was causing security risk to end users. Now that OCSP stapling is available, I think we should give Verizon a little bit of time to move their customers to OCSP. Additionally, Verizon may not be the only CA with this issue, so I think it is better that we solve it by enforcing it in code. https://bugzilla.mozilla.org/show_bug.cgi?id=585122#c34 2013-07-11 17:09:40 PDT "So, now we have OCSP stapling enabled. ... there is now a requirement that OCSP responders MUST NOT provide "good" responses for unknown certificates in effect; this is a feature that CRLs do not have. Therefore, I think we're more than justified in requiring that revocation information be provided by OCSP for EV certificates." Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
Kaspar Brand wrote: > Another 10 days have passed without any apparent sign of Mozilla's > willingness to address the case of the non-existence of an OCSP > responder for the Cybertrust SureServer EV CA. And since CRL support was dropped in recent Firefox/Seamonkey releases there's no revocation checking mechanism for those certs at all. > Otherwise, the CA Certificate Policy is definitely > becoming nothing but a farce (cf. e.g. item 2 of the Inclusion Policy, > "a public process, based on objective and verifiable criteria"), and the > Enforcement Policy in particular will remain a paper tiger in all eternity. Is that news to you? The policy discussions here are just security theater - since years... Ciao, Michael. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On 08.10.2013 07:16, Kaspar Brand wrote: > On 06.10.2013 20:52, Brian Smith wrote: >> In the abstract, I support the removal of the EV indicator for certs >> from CAs that don't meet our requirements for OCSP, including the >> requirement that OCSP responders must return a signed "unknown" or >> signed "revoked" response for unknown certificates, > > Fine. So in the case of Verizon, why does Mozilla not proceed with > removing their EV enablement? Their EV issuing CA has been non-compliant > for 2 years, 9 months, and 8 days by now. No wiggle room for any > discussion about effective dates etc., they undisputably failed to > implement a mandatory component of their revocation infrastructure (and > were certainly aware of this requirement in 2009, see > https://groups.google.com/d/msg/mozilla.dev.security.policy/x_cuezl71OI/lt-ftQ0jmFoJ). Another 10 days have passed without any apparent sign of Mozilla's willingness to address the case of the non-existence of an OCSP responder for the Cybertrust SureServer EV CA. Let me quote again from the Mozilla CA Certificate Policy: CA Certificate Enforcement Policy, Version 2.2, item 2: > Mozilla may, at its sole discretion, disable (partially or fully) or > remove a certificate at any time and for any reason. Mozilla will > disable or remove a certificate if the CA demonstrates ongoing or > egregious practices that do not maintain the level of service that > was established in the Inclusion Section of the Mozilla CA > Certificate Policy or that do not comply with the requirements of the > Maintenance Section of the Mozilla CA Certificate Policy. CA Certificate Inclusion Policy, Version 2.2, item 19: > We have appointed a CA certificate "module owner" and (optionally) > one or more "peers" to evaluate CA requests on our behalf and make > decisions regarding all matters relating to CA certificates included > in our products. CAs or others objecting to a particular decision may > appeal to the Mozilla governance module owner or peer(s), who will > make a final decision. Will Mozilla at least make its decision re: keeping the EV enablement for Verizon public? Otherwise, the CA Certificate Policy is definitely becoming nothing but a farce (cf. e.g. item 2 of the Inclusion Policy, "a public process, based on objective and verifiable criteria"), and the Enforcement Policy in particular will remain a paper tiger in all eternity. Kaspar ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
I utterly agree with Kaspar.
There are CA's waiting to enable the EV check due to they did not support
GET OCSP (could anyone explain what justifies this requirement?) since
there are other CSP's "enjoying" its EV check without fulfilling the EV
Reqs.
On Sun, Oct 6, 2013 at 8:52 PM, Brian Smith wrote:
> On Sun, Oct 6, 2013 at 7:36 AM, Kaspar Brand wrote:
> > My question to the browser vendors, in particular Mozilla, is still
> > unanswered:
> >
> >> Doesn't that call for more a rigorous action from the browser vendors
> >> (given that Verizon is apparently no longer a CABF member, so the
> >> stick of cancelling their membership is already ineffective)?
>
> > As demonstrated by the cclearning.accenture.com case, Verizon does its
> > own "risk assessment", decides to not follow the BR, Mozilla (Corp.)
> > remains silent... and then everyone goes back to regular schedule? I
> > don't think that's an appropriate way of dealing with this issue.
>
> Hi Kasper,
>
> I don't think there is much of a threat to our users from that
> certificate. Also, please read Section 14.2.2 ("Enterprise RAs") of
> the baseline requirements. Given that the EV requirements allow this
> "Enterprise RA" practice and given that the *.cclearning.accenture.com
> wildcard cert was at least "3rd level" it seems like a no harm / no
> foul situation.
>
> Given that we have Safe Browsing, and given that browsers highlight
> the eTLD+1 in the address bar to reduce the effectiveness of spoofing
> using subdomains (e.g. paypal.services.com), and given that the
> subject name of the cert is shown in the address bar for EV certs,
> perhaps it isn't so bad to even change the EV requirements to allow
> wildcard EV certs when the the eTLD+1 wouldn't result in confusion.
> And, conversely, perhaps we should tighten the baseline requirements
> to prevent the issuance of ANY kind of confusing wildcard certs. For
> example, *.services.com or *.banking.com seems bad no matter whether
> it is EV or not. Conversely, *.cclearning.accenture.com seems mostly
> benign to me.
>
> > "CAs MUST support an OCSP capability for Subscriber Certificates that
> >are issued after Dec 31, 2010."
>
> In the abstract, I support the removal of the EV indicator for certs
> from CAs that don't meet our requirements for OCSP, including the
> requirement that OCSP responders must return a signed "unknown" or
> signed "revoked" response for unknown certificates, and including the
> requirement that there must be an OCSP responder URI in the end-entity
> certificate. I think it would be unreasonable for us to enforce the
> requirement for "GET" at this time considering Firefox doesn't even
> try "GET" yet, but that would eventually happen too.
>
> It would be great if a volunteer in this community could identify
> which certificates in our EV program would be affected by such a
> change, along with reproducable evidence of non-conformance. I think
> that would educate us as to the extent of the change we would be
> considering.
>
> Do you think we should remove the EV indicator for *all* certificates
> that a CA issued, even if some/most of them included a link to a
> correctly-functioning OCSP responder? Or, is it reasonable to just not
> show the EV indicator when we are unable to obtain an OCSP response
> for a particular certificate in question? We already have somebody
> working on implementing the latter in bug 585122 [1]. If you that we
> should remove the EV indicator from all of a CA's EV certificates if
> *any* of them are missing OCSP functionality, then should the
> privilege of getting the "EV indicator" also be contingent on non-EV
> certs by that CA also meeting the requirement (which is now a baseline
> requirement, not just EV)?
>
> I would like us to change our EV requirements so that a CA's entire
> operation must be conformant to our policy (including the baseline
> requirements, and including any externally-operated intermediates)
> before we consider them to qualify for the EV privilege--i.e. we
> should only give the EV-certificate-issuing privilege to our best
> partners.
>
> Cheers,
> Brian
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=585122
>
> Cheers,
> Brian
> --
> Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
--
m...@chemalogo.com
gplus.to/chemalogo
+34 666 429 224 (Spain)
@chemalogo
www.linkedin.com/in/chemalogo
chemalogo
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On 06.10.2013 20:52, Brian Smith wrote:
> I don't think there is much of a threat to our users from that
> certificate.
Not going to comment on this further. The point is BR compliance and
enforcement of Mozilla's CA Certificate Maintenance Policy, not
individual case-by-case risk management.
>> "CAs MUST support an OCSP capability for Subscriber Certificates that
>>are issued after Dec 31, 2010."
>
> In the abstract, I support the removal of the EV indicator for certs
> from CAs that don't meet our requirements for OCSP, including the
> requirement that OCSP responders must return a signed "unknown" or
> signed "revoked" response for unknown certificates,
Fine. So in the case of Verizon, why does Mozilla not proceed with
removing their EV enablement? Their EV issuing CA has been non-compliant
for 2 years, 9 months, and 8 days by now. No wiggle room for any
discussion about effective dates etc., they undisputably failed to
implement a mandatory component of their revocation infrastructure (and
were certainly aware of this requirement in 2009, see
https://groups.google.com/d/msg/mozilla.dev.security.policy/x_cuezl71OI/lt-ftQ0jmFoJ).
> and including the requirement that there must be an OCSP responder
> URI in the end-entity certificate.
That's not mandated by either the EV Guidelines or the BR. Stapling is
another viable option, so obviously the fix for bug 585122 needs to be
smarter than to just checking for a URI (or drop CRL support).
> It would be great if a volunteer in this community could identify
> which certificates in our EV program would be affected by such a
> change, along with reproducable evidence of non-conformance. I think
> that would educate us as to the extent of the change we would be
> considering.
Ok, so volunteers step forward, please... if Mozilla's reaction will
mostly consist of "applauding" such work and making statements like
"(for now) I am OK with the OCSP issues that were noted", it seems that
there's relatively little incentive for undertaking such work.
Kaspar
diff --git a/security/manager/ssl/src/nsIdentityChecking.cpp
b/security/manager/ssl/src/nsIdentityChecking.cpp
--- a/security/manager/ssl/src/nsIdentityChecking.cpp
+++ b/security/manager/ssl/src/nsIdentityChecking.cpp
@@ -135,27 +146,16 @@ static struct nsMyTrustedEVInfo myTruste
"FE:B8:C4:32:DC:F9:76:9A:CE:AE:3D:D8:90:8F:FD:28:86:65:64:7D",
"MGAxCzAJBgNVBAYTAkpQMSUwIwYDVQQKExxTRUNPTSBUcnVzdCBTeXN0ZW1zIENP"
"LixMVEQuMSowKAYDVQQLEyFTZWN1cml0eSBDb21tdW5pY2F0aW9uIEVWIFJvb3RD"
"QTE=",
"AA==",
nullptr
},
{
-// CN=Cybertrust Global Root,O=Cybertrust, Inc
-"1.3.6.1.4.1.6334.1.100.1",
-"Cybertrust EV OID",
-SEC_OID_UNKNOWN,
-"5F:43:E5:B1:BF:F8:78:8C:AC:1C:C7:CA:4A:9A:C6:22:2B:CC:34:C6",
-"MDsxGDAWBgNVBAoTD0N5YmVydHJ1c3QsIEluYzEfMB0GA1UEAxMWQ3liZXJ0cnVz"
-"dCBHbG9iYWwgUm9vdA==",
-"BAABD4WqLUg=",
-nullptr
- },
- {
// CN=SwissSign Gold CA - G2,O=SwissSign AG,C=CH
"2.16.756.1.89.1.2.1.1",
"SwissSign EV OID",
SEC_OID_UNKNOWN,
"D8:C5:38:8A:B7:30:1B:1B:6E:D4:7A:E6:45:25:3A:6F:9F:1A:27:61",
"MEUxCzAJBgNVBAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxHzAdBgNVBAMT"
"FlN3aXNzU2lnbiBHb2xkIENBIC0gRzI=",
"ALtAHEP1Xk+w",
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On Sun, Oct 6, 2013 at 11:52 AM, Brian Smith wrote: > On Sun, Oct 6, 2013 at 7:36 AM, Kaspar Brand wrote: > Hi Kasper, Sorry about the misspelling, Kaspar. Cheers, Brain ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On Sun, Oct 6, 2013 at 7:36 AM, Kaspar Brand wrote:
> My question to the browser vendors, in particular Mozilla, is still
> unanswered:
>
>> Doesn't that call for more a rigorous action from the browser vendors
>> (given that Verizon is apparently no longer a CABF member, so the
>> stick of cancelling their membership is already ineffective)?
> As demonstrated by the cclearning.accenture.com case, Verizon does its
> own "risk assessment", decides to not follow the BR, Mozilla (Corp.)
> remains silent... and then everyone goes back to regular schedule? I
> don't think that's an appropriate way of dealing with this issue.
Hi Kasper,
I don't think there is much of a threat to our users from that
certificate. Also, please read Section 14.2.2 ("Enterprise RAs") of
the baseline requirements. Given that the EV requirements allow this
"Enterprise RA" practice and given that the *.cclearning.accenture.com
wildcard cert was at least "3rd level" it seems like a no harm / no
foul situation.
Given that we have Safe Browsing, and given that browsers highlight
the eTLD+1 in the address bar to reduce the effectiveness of spoofing
using subdomains (e.g. paypal.services.com), and given that the
subject name of the cert is shown in the address bar for EV certs,
perhaps it isn't so bad to even change the EV requirements to allow
wildcard EV certs when the the eTLD+1 wouldn't result in confusion.
And, conversely, perhaps we should tighten the baseline requirements
to prevent the issuance of ANY kind of confusing wildcard certs. For
example, *.services.com or *.banking.com seems bad no matter whether
it is EV or not. Conversely, *.cclearning.accenture.com seems mostly
benign to me.
> "CAs MUST support an OCSP capability for Subscriber Certificates that
>are issued after Dec 31, 2010."
In the abstract, I support the removal of the EV indicator for certs
from CAs that don't meet our requirements for OCSP, including the
requirement that OCSP responders must return a signed "unknown" or
signed "revoked" response for unknown certificates, and including the
requirement that there must be an OCSP responder URI in the end-entity
certificate. I think it would be unreasonable for us to enforce the
requirement for "GET" at this time considering Firefox doesn't even
try "GET" yet, but that would eventually happen too.
It would be great if a volunteer in this community could identify
which certificates in our EV program would be affected by such a
change, along with reproducable evidence of non-conformance. I think
that would educate us as to the extent of the change we would be
considering.
Do you think we should remove the EV indicator for *all* certificates
that a CA issued, even if some/most of them included a link to a
correctly-functioning OCSP responder? Or, is it reasonable to just not
show the EV indicator when we are unable to obtain an OCSP response
for a particular certificate in question? We already have somebody
working on implementing the latter in bug 585122 [1]. If you that we
should remove the EV indicator from all of a CA's EV certificates if
*any* of them are missing OCSP functionality, then should the
privilege of getting the "EV indicator" also be contingent on non-EV
certs by that CA also meeting the requirement (which is now a baseline
requirement, not just EV)?
I would like us to change our EV requirements so that a CA's entire
operation must be conformant to our policy (including the baseline
requirements, and including any externally-operated intermediates)
before we consider them to qualify for the EV privilege--i.e. we
should only give the EV-certificate-issuing privilege to our best
partners.
Cheers,
Brian
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=585122
Cheers,
Brian
--
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
My question to the browser vendors, in particular Mozilla, is still unanswered: > Doesn't that call for more a rigorous action from the browser vendors > (given that Verizon is apparently no longer a CABF member, so the > stick of cancelling their membership is already ineffective)? As demonstrated by the cclearning.accenture.com case, Verizon does its own "risk assessment", decides to not follow the BR, Mozilla (Corp.) remains silent... and then everyone goes back to regular schedule? I don't think that's an appropriate way of dealing with this issue. Meanwhile I had another look at Verizon's EV SSL machinery. Since its inception, the EV Guidelines have very clearly stated: "CAs MUST support an OCSP capability for Subscriber Certificates that are issued after Dec 31, 2010." (Draft 11 from 20 October 2006 already had it, in version 1.4 it disappeared due to the BR being incorporated by reference) And http://www.verizonenterprise.com/us/products/security/identity/ssl/evssl.xml at least states: "We support and use Version 1.3 of the Extended Validation Certificate Guidelines developed by the CA/Browser Forum" They refer to an older version of the EV Guidelines on their Web site, but their CP/CPS (http://cybertrust.omniroot.com/repository/Cybertrust_CPS_v_5_4.pdf) on the other hand is fine when saying: "SureServer EV issuance and management practices comply with the current version of the said Guidelines." Ok, then in 2013 there must sure[server]ly be an OCSP responder for these EV thingies, right? Just an unfortunate glitch that they forgot to include the respective URI in the cert... but nobody is perfect. Let's see if we can figure out ourselves where that responder lives: > $ openssl s_client -connect ev.omniroot.com:443 &0 | openssl > x509 -noout -text | grep http > > URI:http://crl.omniroot.com/SureServerEV.crl > CPS: http://cybertrust.omniroot.com/repository Ah, must be ocsp.omniroot.com, most likely. Let's try: > $ host ocsp.omniroot.com > ocsp.omniroot.com is an alias for evocsp.us.omniroot.com. > evocsp.us.omniroot.com has address 64.18.17.38 Great! Apparently they operate a responder in the US. Let's try to ask it for the status of the "ev.omniroot.com" cert, then: > $ curl -siH Accept: > http://ocsp.omniroot.com/ME8wTTBLMEkwRzAJBgUrDgMCGgUABBQ5h1nWidcsYM7en%2F2U9AwLuY57WgQUm3tY6z0D5IfI5IzqRnySVOk2u54CDgIAATOE8KOLdzwV > HTTP/1.1 404 Not Found > Date: Sun, 06 Oct 2013 14:13:55 GMT > Server: Apache/2.2.15 (CentOS) > Content-Length: 389 > Connection: close > Content-Type: text/html; charset=iso-8859-1 > > > > 404 Not Found > > Not Found > The requested URL > /ME8wTTBLMEkwRzAJBgUrDgMCGgUABBQ5h1nWidcsYM7en/2U9AwLuY57WgQUm3tY6z0D5IfI5IzqRnySVOk2u54CDgIAATOE8KOLdzwV > was not found on this server. > > > Apache/2.2.15 (CentOS) Server at ocsp.omniroot.com Port 80 > Ouch. Hmm, apparently no GET support here yet - wasn't there a section about this somewhere in the BR... (13.2.2)? Well, anyway, let's be nice and try again, this time with POST: > $ echo > ME8wTTBLMEkwRzAJBgUrDgMCGgUABBQ5h1nWidcsYM7en/2U9AwLuY57WgQUm3tY6z0D5IfI5IzqRnySVOk2u54CDgIAATOE8KOLdzwV > | openssl base64 -d -A | curl -iH "Content-Type: application/ocsp-request" > -H Accept: --data-binary @- http://ocsp.omniroot.com > HTTP/1.1 200 OK > Date: Sun, 06 Oct 2013 14:14:04 GMT > Server: Apache/2.2.15 (CentOS) > Last-Modified: Mon, 18 Feb 2013 16:54:02 GMT > ETag: "20117-7-4d6029275fa0f" > Accept-Ranges: bytes > Content-Length: 7 > Connection: close > Content-Type: text/html; charset=UTF-8 > > server Wow, fantastic! It's telling us that it is a *server* (not some toy, in case you were wondering). And of course text/html is perfectly matching for a request of type application/ocsp-request, isn't it? Going back to the first message in this thread and the Netcraft blog entry, what is really egregious is not so much the fact that Netcraft found "an EV certificate without an OCSP URL!" for enroll.americanexpress.com - the point is that Verizon does not provide a working OCSP responder for their EV certs *at all*... even though the EV Guidelines made a responder mandatory as of January 1, 2011 (see above). I fail to see a reason why Mozilla's next action should not consist of reverting the Cybertrust-related changes committed with https://bugzilla.mozilla.org/show_bug.cgi?id=493709, and only re-enable Verizon for EV after they have completed a new full WebTrust EV audit. Kaspar P.S. Apart from the non-compliant businessCategory attributes mentioned before, the issuer DN for the Verizon EV SSL CA also does not meet the requirement from BR section 9.1.4: there's no countryName RDN (it's just "O=Cybertrust Inc, CN=Cybertrust SureServer EV CA"). ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
