Hi As far as I know we have the following status:
> Add a security warning to the Web Console to remind developers that they should not be using a SHA-1 based certificates Has already been fixed. But currently SHA-1 is only exposed in the console, not on the lock icon so far. > Show the “Untrusted Connection” error whenever a SHA-1 certificate issued after January 1, 2016, is encountered in Firefox Has been fixed and reverted. Not shipped so far (see security.pki.sha1_enforcement_level). > Show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017 Has not been fixed so far, but can be enabled (see security.pki.sha1_enforcement_level). There was also a discussion about exposing/untrust SHA-1 certs that expires after January 1, 2017 (see https://sha1-2017.badssl.com/). See also: https://bugzilla.mozilla.org/show_bug.cgi?id=942515 https://bugzilla.mozilla.org/show_bug.cgi?id=1183718 https://blog.mozilla.org/security/2015/10/20/continuing-to-phase-out-sha-1-certificates/ Regards, Jonas Am 17.06.2016 um 14:46 schrieb Jakob Bohm: > On 06/06/2016 23:14, [email protected] wrote: >> On Thursday, May 19, 2016 at 9:09:58 AM UTC-7, [email protected] wrote: >>> Could you confirm the dates from which FF will be rejecting SHA-1 >>> SSL certificates (regardless of when they were issued) >> >> Hi Ajuram, >> >> I can't speak for Richard, but I do not believe there is a firm date >> for rejecting all SHA-1 certs yet: The plan is still Q1 2017. >> >> I don't imagine we'd move earlier than that unless new research on >> SHA-1 collisions prompts it. >> >> J.C. >> > > One major suggestion (based on past experience with Chrome doing it > wrong): Do not apply SHA-1 rejection to any of the following: > > 1. The self-signature on the root cert in a chain. > > 2. Cross-signatures/certs on a subject/public key combination which is > also present as a trusted root in its own right (example: GlobalSign > has long ago issued a cross-certificate where their old SHA-1 root cert > SHA-1 signed their new SHA-2 root). > > 3. Any situation where the server / e-mail signer / code signer > provides enough certs to form multiple trust chains and at least one > trusted chain can be formed by ignoring all the non-root SHA-1 certs > (this actually encompass cases 1 and 2 as special cases). > > 4. For file formats that can be signed with multiple certificates, > accept the good signature and ignore any SHA-1 signatures that might be > included for backward compatibility. This includes: Anything with a > PKCS#7/CMS signature (supports a "SET of SignerInfo"), Anything with > JAR style signatures (including .xpi files, the JAR signature format > spec allows an almost unlimited number of signature files in the .zip, > each of which is a PKCS#7/CMS signature itself), anything with > Microsoft Authenticode signatures (these are PKCS#7 but also allow > additional signatures in a special unauthenticated signature attribute). > > By not rejecting these cases, servers/signers can provide alternative > signature chains that are trusted by older clients. For instance this > could be a good thing to to for the "download Firefox" page, since > people are likely to visit that using a woefully outdated browser. > > Enjoy > > Jakob
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
