No Russian CAs
Hello Caju Mihai, Because in Russia there are no significant and notable CAs. Usually only foreign CAs are used. Sincerely, Andrew (Russia) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
2018.08.23 Let's Encrypt OCSP Responder Incident
To see the original communication on our Community Forums, click here: https://community.letsencrypt.org/t/2018-08-23-ocsp-responder-incident/70350 At 17:47 UTC on August 23rd, 2018 we deployed a configuration change to our OCSP responder service that resulted in 90% of traffic to our origin inaccurately receiving OCSP "unauthorized" statuses for valid OCSP requests. Most OCSP responses that were cached at our CDN prior to the incident were not affected. The change was reverted on 19:33 UTC the same day to resolve the problem, though CDN caching may have resulted in affected statuses being served for a limited period of time after resolution. The root technical cause of this incident was [a change](https://github.com/letsencrypt/boulder/pull/3815) developed during a previous incident in which malformed OCSP traffic was causing excessive strain on the OCSP responder. Unfortunately [a bug in the implementation](https://github.com/letsencrypt/boulder/issues/3829) improperly rejected OCSP requests unless they matched the last configured serial prefix rather than any configured serial prefix. We have since [fixed the bug](https://github.com/letsencrypt/boulder/pull/3830). We first became aware of the problem at 17:52 UTC after our internal alerting flagged invalid OCSP responses for certificates issued by our monitoring systems, though the scale of the issue was not immediately clear. We began investigating the root cause, identified the problem at 19:26 UTC and immediately disabled the prefix validation feature in staging and production. The bug was not caught during testing because the unittest accompanying the initial PR did not cover the case of multiple acceptable prefixes. The bug was not caught in our staging environment for two reasons: (1) Our internal OCSP monitoring looks for HTTP 500s, but ignores OCSP "unauthorized" responses, because large number of such responses can be triggered externally by misconfigured clients; (2) Our end-to-end OCSP monitoring tests were working in production, but not in staging. Remediation items: 1. Review our procedures for ensuring that all monitoring tools are applied to both production and staging environments. 2. Extend OCSP monitoring to include OCSP statuses (unauthorized, revoked, ok, etc) in addition to HTTP statuses. 3. Add alerts when fraction of unauthorized or revoked OCSP responses is extremely high. Timeline: 2018-08-23 01:43 UTC - feature configured in staging 2018-08-23 17:47 UTC - feature configured in production 2018-08-23 19:31 UTC - feature disabled in staging 2018-08-23 19:33 UTC - feature disabled in production ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: No Russian CAs
vineri, 24 august 2018, 21:28:36 UTC+3, Kurt Roeckx a scris: > Probably because no Russian CA has applied to be in the root store. A CA from Kazahstan has applied, although I can't find them in the search results I have found a link to the bug in the wiki. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: No Russian CAs
Probably because no Russian CA has applied to be in the root store. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
No Russian CAs
Greetings, I would like to ask why there are no root certificate authorities from organizations in the Russian Federation. Specifically I haven't found any with the country code RU in the NSS CA bundle. Is it due to political pressure? Or does the Russian government have a bad history with forcing CAs to issue certificates? As far as I know Yandex has it's own intermediate CA, signed by Certum. So I can't see the issue? Also can you point me to a few bugs where Russian CAs have attempted inclusion? Bugzilla search isn't very helpful, and I have tried searching in "CA Certificates Code", "CA Certificate Mis-Issuance" and "CA Certificate Root Program" ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services - Minor SCT issue disclosure
The code at issue evolved as CT requirements changed. What started off as a very simple conditional grew into a more complex if / else if block with somewhat complicated logic and inline checks. As part of the fix, we simplified the conditionals and refactored the inline checks to make use of nice clear IsExternallyOperated() and IsGoogleOperated() functions. The end result is a much more readable and clear set of logic that is easier to test and we expanded test coverage. I think the big lesson for the community is that it would have been better to have refactored earlier rather the evolving the code to the point it became more complicated than it needed to be. On Thu, Aug 23, 2018 at 9:40 AM Ryan Sleevi wrote: > > > On Thu, Aug 23, 2018 at 8:50 AM, Andy Warner via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: >> >> * NOTE: The bug was due to an 'if/else' chain fall through. The code in >> question has been refactored to be simpler and more readable. >> > > Andy, > > It might be good for the community if you could describe the processes > before and after the change, so that other CAs can help prevent similar > issues with their own embedding systems. > 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
