Re: Mozilla's Expectations for OCSP Incident Reporting
Browsers by default just ignore any OCSP error. So while the browser might have seen an error getting the OCSP reply, the user is not aware of it. And why Browsers do ignore OCSP errors? Because some CA don't take OCSP errors seriously. So yes, it has an impact: it comfort Browsers in that situation, which is less than ideal, because it impacts the security of *all* users. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla's Expectations for OCSP Incident Reporting
On Fri, 15 May 2020 10:13:01 -0400 Lee via dev-security-policy wrote: > How is this situation different from the time when the google ocsp > service was down? Maybe some clarification here: The Google OCSP was the OCSP for end entity certificates. The Identrust OCSP was the OCSP server for intermediate certs. Checking OCSP for intermediates is less common than checking OCSP for end entity certificates. So there is a difference. However I still believe OCSP servers should not be offline for longer periods of time in both cases :-) -- Hanno Böck https://hboeck.de/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla's Expectations for OCSP Incident Reporting
On 5/15/20, Peter Gutmann via dev-security-policy wrote: > Hanno Böck writes: > >>The impact it had was a monitoring system that checked whether the >>certificate of a host was okay, using gnutls-cli with ocsp enabled (which >>also uncovered a somewhat unexpected inconsistency in how the gnutls cli >> tool >>behaves[1]). > > Sure, but if the only impact was on a specially-configured setup > (gnutls-cli > with OCSP explicitly enabled rather than a standard web browser) then it > didn't have any real impact on actual users. How is this situation different from the time when the google ocsp service was down? https://groups.google.com/forum/?_escaped_fragment_=topic/mozilla.dev.security.policy/MMO3HSYghwQ Not a whole lot of people noticed that.. but there was a real impact on some actual users. Lee ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla's Expectations for OCSP Incident Reporting
On 2020-05-15 08:47, Peter Gutmann wrote: Hanno Böck writes: The impact it had was a monitoring system that checked whether the certificate of a host was okay, using gnutls-cli with ocsp enabled (which also uncovered a somewhat unexpected inconsistency in how the gnutls cli tool behaves[1]). Sure, but if the only impact was on a specially-configured setup (gnutls-cli with OCSP explicitly enabled rather than a standard web browser) then it didn't have any real impact on actual users. Browsers by default just ignore any OCSP error. So while the browser might have seen an error getting the OCSP reply, the user is not aware of it. So it's possible that a certificate was revoked, but because OCSP was down that the browser connected to the website without any error, while it should have given an error. So it's possible that there was a real impact on actual users. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla's Expectations for OCSP Incident Reporting
Hanno Böck writes: >The impact it had was a monitoring system that checked whether the >certificate of a host was okay, using gnutls-cli with ocsp enabled (which >also uncovered a somewhat unexpected inconsistency in how the gnutls cli tool >behaves[1]). Sure, but if the only impact was on a specially-configured setup (gnutls-cli with OCSP explicitly enabled rather than a standard web browser) then it didn't have any real impact on actual users. It's a bit like the joke about someone complaining about his neighbour sunbathing in the nude, which they're forced to see every time they climb up a tall ladder and look over at their property with binoculars (can't remember the exact form, but something like that). If the only thing that we have any evidence was affected was a monitoring system specially set up to be affected then it seems pretty likely that the actual impact of the outage on general users was zero. Which makes it a certificational weakness, not a practical one, and therefore much less of an issue. Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla's Expectations for OCSP Incident Reporting
On Wed, May 13, 2020 at 12:12 AM Peter Gutmann wrote: > Ryan Sleevi writes: > > >>Following up on this, would it be correct to assume that, since no-one > has > >>pointed out any impact that this had on anything, that it's more a > >>certificational issue than anything with real-world consequences? > > > >That seems quite a suppositional leap, don't you think? > > It's been more than two weeks since the issue was first reported, if > no-one's > been able to identify any actual impact in that time - compare this to say > certificate-induced outages which make the front page of half the tech news > sites on the planet when they occur - then it seems reasonable to assume > that > the impact is minimal if not nonexistent. > > In any case I was inviting people to provide information on whether there's > been any adverse effect in order to try and gauge the magnitude, or lack > thereof, of this event. I would hardly say it’s reasonable to conclude whatever you want simply because no one has personally engaged with you for two days, and worse, that others support that view. I appreciate it as a rhetorical technique to try and force a reply, which it obviously did, but only to point out how deeply flawed the argument is, at least in a venue where replying to you is optional. A better approach would be to examine what and how clients would have been affected, and then how to quantify and measure that, as well as what the impact of that affect would be. Posing that you didn’t see a news story and you didn’t get any replies to your email on a relatively obscure newsgroup that it is proof there was no impact or harm ... isn’t that ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla's Expectations for OCSP Incident Reporting
On Wed, 13 May 2020 02:29:07 + Peter Gutmann via dev-security-policy wrote: > Following up on this, would it be correct to assume that, since > no-one has pointed out any impact that this had on anything, that > it's more a certificational issue than anything with real-world > consequences? I have reported (and noticed) it because it had an impact. The impact it had was a monitoring system that checked whether the certificate of a host was okay, using gnutls-cli with ocsp enabled (which also uncovered a somewhat unexpected inconsistency in how the gnutls cli tool behaves[1]). Not saying this is a particularly severe impact, however it took me some time figuring out what's going on there. It may very well that others have experienced impact that they were unable to explain. [1] https://gitlab.com/gnutls/gnutls/-/issues/981 -- Hanno Böck https://hboeck.de/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla's Expectations for OCSP Incident Reporting
Ryan Sleevi writes: >>Following up on this, would it be correct to assume that, since no-one has >>pointed out any impact that this had on anything, that it's more a >>certificational issue than anything with real-world consequences? > >That seems quite a suppositional leap, don't you think? It's been more than two weeks since the issue was first reported, if no-one's been able to identify any actual impact in that time - compare this to say certificate-induced outages which make the front page of half the tech news sites on the planet when they occur - then it seems reasonable to assume that the impact is minimal if not nonexistent. In any case I was inviting people to provide information on whether there's been any adverse effect in order to try and gauge the magnitude, or lack thereof, of this event. Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla's Expectations for OCSP Incident Reporting
On Tue, May 12, 2020 at 10:29 PM Peter Gutmann via dev-security-policy wrote: > > >Just to understand the scope of this, what was the impact on end users? > > Following up on this, would it be correct to assume that, since no-one has > pointed out any impact that this had on anything, that it's more a > certificational issue than anything with real-world consequences? That seems quite a suppositional leap, don't you think? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla's Expectations for OCSP Incident Reporting
>Just to understand the scope of this, what was the impact on end users? Following up on this, would it be correct to assume that, since no-one has pointed out any impact that this had on anything, that it's more a certificational issue than anything with real-world consequences? Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla's Expectations for OCSP Incident Reporting
Just an FYI - I've also started a thread on the CA/Browser Forum list to see about establishing OCSP uptime requirements in the Baseline Requirements. On Mon, May 11, 2020 at 5:45 AM Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 2020-05-08 21:03, Wayne Thayer wrote: > > It was recently reported [1] that IdenTrust experienced a multi-day OCSP > > outage about two weeks ago. Other recent OCSP issues have resulted in > > incident reports [3][4], so I am concerned that IdenTrust didn't report > > this, and I created a bug [5] to ensure that we track the issue (assuming > > the report of an extended outage is accurate). > > > > I also created an issue [6] suggesting that Mozilla clarify expectations > > for reporting CRL and OCSP outages. These services are notoriously > > unreliable and I doubt that a constant barrage of reports for brief > outages > > would be manageable. I believe that Mozilla does expect CAs to report > > "significant" outages, but there is currently no guidance to help CAs > > determine when they should file a report. > > Should we have minimum uptime requirements? For instance 90% for a 24 > hour period and 95% per 30 days? > > > Kurt > ___ > 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: Mozilla's Expectations for OCSP Incident Reporting
On 2020-05-08 21:03, Wayne Thayer wrote: It was recently reported [1] that IdenTrust experienced a multi-day OCSP outage about two weeks ago. Other recent OCSP issues have resulted in incident reports [3][4], so I am concerned that IdenTrust didn't report this, and I created a bug [5] to ensure that we track the issue (assuming the report of an extended outage is accurate). I also created an issue [6] suggesting that Mozilla clarify expectations for reporting CRL and OCSP outages. These services are notoriously unreliable and I doubt that a constant barrage of reports for brief outages would be manageable. I believe that Mozilla does expect CAs to report "significant" outages, but there is currently no guidance to help CAs determine when they should file a report. Should we have minimum uptime requirements? For instance 90% for a 24 hour period and 95% per 30 days? Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] Mozilla's Expectations for OCSP Incident Reporting
Wayne Thayer via dev-security-policy writes: >It was recently reported [1] that IdenTrust experienced a multi-day OCSP >outage about two weeks ago. Just to understand the scope of this, what was the impact on end users? If it went on for multiple days then presumably no-one noticed it, the second reference: https://community.letsencrypt.org/t/identrust-ocsp-producing-errors/120677 states: Usually few clients do OCSP checks of the intermediate cert, thus this probably doesn’t show up very often. >From the report it looks like a very specific config was required to even notice it. If an OCSP responder crashes on the Internet and no-one checks it, does it make a difference? (Interesting to see that the Wikipedia page for this philosophical question helpfully shows a photo of "A fallen tree in a forest" to illustrate the concept). Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Mozilla's Expectations for OCSP Incident Reporting
It was recently reported [1] that IdenTrust experienced a multi-day OCSP outage about two weeks ago. Other recent OCSP issues have resulted in incident reports [3][4], so I am concerned that IdenTrust didn't report this, and I created a bug [5] to ensure that we track the issue (assuming the report of an extended outage is accurate). I also created an issue [6] suggesting that Mozilla clarify expectations for reporting CRL and OCSP outages. These services are notoriously unreliable and I doubt that a constant barrage of reports for brief outages would be manageable. I believe that Mozilla does expect CAs to report "significant" outages, but there is currently no guidance to help CAs determine when they should file a report. - Wayne [1] https://www.feistyduck.com/bulletproof-tls-newsletter/issue_64_gcc_code_analyzer_finds_bug_in_openssl [2] https://community.letsencrypt.org/t/identrust-ocsp-producing-errors/120677 [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1622505 [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1630040 [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1636544 [6] https://github.com/mozilla/pkipolicy/issues/214 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
