590364 - By default, stop accepting MD5 as a hash algorithm in certificate signatures

Status: RESOLVED FIXED

(NSS :: Libraries, defect)

Description

[Kathleen Wilson]

Requested change: 
Stop accepting MD5 as a hash algorithm for intermediate and end-entity certificates. Software published by Mozilla should return an error when a certificate with an MD5-based signature is used. 

When: 
The request is to implement this in NSS so that it is picked up in the first release of Firefox on or after June 30, 2011. Is there a way to set such a date in this bug?

Note: 
Mozilla will request that this action be taken earlier if necessary to keep our users safe. 

Reference: Bug #471539
Change the default setting of an NSS environment variable from
NSS_HASH_ALG_SUPPORT=-MD2,+MD5 (currently only MD2 is turned off)
to
NSS_HASH_ALG_SUPPORT=-MD2,-MD5 (this would turn off MD5) 

Thanks,
Kathleen

Comment 1

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

3.12.11 might also work, depending on the schedule for 3.12.10. Basically, this bug is about making sure that it is possible for Mozilla products to stop accepting MD5-based signatures on June 30th. Ideally, we would modify PSM in Firefox 6 to check the current date and disable MD5 if today's date is June 30th or later.

Comment 2

[Tony Berman]

(In reply to comment #1)
> 3.12.11 might also work, depending on the schedule for 3.12.10. Basically, this
> bug is about making sure that it is possible for Mozilla products to stop
> accepting MD5-based signatures on June 30th. Ideally, we would modify PSM in
> Firefox 6 to check the current date and disable MD5 if today's date is June
> 30th or later.

HI Brian, will earlier versions of FireFox be affected by this change, or would MD5 certs only stop working in FF6 and later?

Thanks
Tony

Comment 3

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Tony, it looks like FF6 would be the soonest release with this change.

Comment 4

[Kathleen Wilson]

Brian, Is this still planned to be included in FF6? What version of Thunderbird do you think this will be in?

Thanks,
Kathleen

Comment 5

[Tony Berman]

Hi Brian,

I downloaded FF6 to test some certs and it seems that MD5 certs are not blocked in the Beta of 6.0. Will that be updated before teh release?

Thanks
Tony

Comment 6

[Kai Engert (:KaiE:)]

We just discussed this bug in the NSS conference call.

We would like to change the default inside NSS. In particular, we want to change NSS, so that MD5 is longer accepted when verifying signatures.

However, we're worried that some corporate environments still depend on hardware infrastructure using MD5. Therefore we'd like to have a new hidden preference (about:config) at the Mozilla/Firefox level, that could allow such environments to turn it back on.

Bob said the name of the NSS API to influence this behaviour is called SetAlgorithmPolicy (check for similar spelling). (see also SecOidInit, HashAlgSupport)

So, we need a change in NSS to change the default, and upgrade Mozilla to that NSS.

In addition, we need to introduce the new preference at the PSM level, and change NSS based on that pref.

Comment 7

[Kai Engert (:KaiE:)]

Test case:

- use a separate test profile, please

- install my test CA from http://kuix.de/ca/nss-test-ca.php
  (check the boxes, OK)

- go to https://kuix.de:9450

As of today (not fixed), you fill see my homepage.
Click identity button, view certificate, details, click kuix.de, click cert signature alg, you should see MD5.


Expected (when using a build that contains the fix from this bug):

- use the same test profile as above

- go to https://kuix.de:9450

- you should see an error page

- you should be able to add an override and connect to the page

Comment 8

[Kai Engert (:KaiE:)]

Attachment: Patch v1

Comment 9

[Kai Engert (:KaiE:)]

Bob, Wan-Teh:

When using patch v1, we get a full error, no override possible.
Error shown is: sec_error_bad_signature


I see two options, one simple, one requiring more work.


(a) Strictly require the pref to continue

The simple approach would be, add the pref.
By default, people would run into the hard error, bad signature, no override possible.
People will have to know the pref to proceed.
The pref will reenable MD5 globally.


(b) Allow overrides with MD5 disabled

This would require more changes at the PSM level.

This also rises a new question:

  Should it be allowed to override sec_error_bad_signature in general,
  or do we need a new error to distinguish MD5 disabled (or hash disabled)
  from other errors?


I can get done (a) quickly.

I cannot get done (b) quickly, we have more important work to do.

Comment 10

[Kai Engert (:KaiE:)]

For (a):

The following code (tested to work with testcase from comment 7)
would be used to *enable* MD5:

NSS_SetAlgorithmPolicy(SEC_OID_MD5, 
    NSS_USE_ALG_IN_CERT_SIGNATURE | NSS_USE_ALG_IN_CMS_SIGNATURE,
    0);

NSS_SetAlgorithmPolicy(SEC_OID_PKCS1_MD5_WITH_RSA_ENCRYPTION,
    NSS_USE_ALG_IN_CERT_SIGNATURE | NSS_USE_ALG_IN_CMS_SIGNATURE,
    0);

NSS_SetAlgorithmPolicy(SEC_OID_PKCS5_PBE_WITH_MD5_AND_DES_CBC,
    NSS_USE_ALG_IN_CERT_SIGNATURE | NSS_USE_ALG_IN_CMS_SIGNATURE,
    0);


The following code (tested to work with testcase from comment 7)
would be used to *disable* MD5
(when a user switches the pref back to disabled at runtime):

NSS_SetAlgorithmPolicy(SEC_OID_MD5, 
    0,
    NSS_USE_ALG_IN_CERT_SIGNATURE | NSS_USE_ALG_IN_CMS_SIGNATURE)

NSS_SetAlgorithmPolicy(SEC_OID_PKCS1_MD5_WITH_RSA_ENCRYPTION,
    0,
    NSS_USE_ALG_IN_CERT_SIGNATURE | NSS_USE_ALG_IN_CMS_SIGNATURE);

NSS_SetAlgorithmPolicy(SEC_OID_PKCS5_PBE_WITH_MD5_AND_DES_CBC,
    0,
    NSS_USE_ALG_IN_CERT_SIGNATURE | NSS_USE_ALG_IN_CMS_SIGNATURE);


Correct?

Comment 11

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Kai Engert (:kaie) from comment #9)
> I cannot get done (b) quickly, we have more important work to do.

What do other borwsers do, regarding (a) vs (b)?

Comment 12

[Kai Engert (:KaiE:)]

Comment on attachment 602106 [details] [diff] [review]
Patch v1

Let's limit this bug to the NSS portion of the changes.

Let's work on Mozilla's application level preference in bug 732390.

Comment 13

[Kyle Hamilton]

NSS is also called for all TLS cryptography, not merely the handshake, yes?  In that case, bug 732673 requires attention as well because of RSA_RC4_MD5 enabled by default in sslv3.

Comment 14

[Kai Engert (:KaiE:)]

(In reply to Kyle Hamilton from comment #13)
> bug 732673 requires attention as well because of RSA_RC4_MD5
> enabled by default in sslv3.

The patch attached to bug 732390 already does that.

Comment 15

[Wan-Teh Chang]

(In reply to Kai Engert (:kaie) from comment #9)
> 
> This also rises a new question:
> 
>   Should it be allowed to override sec_error_bad_signature in general,
>   or do we need a new error to distinguish MD5 disabled (or hash disabled)
>   from other errors?

NSS has an SEC_ERROR_INVALID_ALGORITHM error that could be used to report
this condition.  But that error code has the same problem -- it is also
used for some invalid algorithms that we don't want to allow users to
accept.

It seems that turning off MD5 signatures using NSS_SetAlgorithmPolicy is
only suitable when we want to treat them as hard errors.

Comment 16

[Wan-Teh Chang]

Comment on attachment 602106 [details] [diff] [review]
Patch v1

>+	xOids[SEC_OID_MD5                           ].notPolicyFlags = ~0;

We need to support the use of MD5 for non-cryptographic purposes, so I
think we should not add this entry for SEC_OID_MD5.

>+	xOids[SEC_OID_PKCS5_PBE_WITH_MD5_AND_DES_CBC].notPolicyFlags = ~0;

This one I am less sure about.

Comment 17

[David E. Ross]

Given that the deadline in the Summary passed 8 months ago and that -- per discussions in this bug report -- some use of MD5 is likely to continue, should not the Summary be updated?

Comment 18

[Kai Engert (:KaiE:)]

Let's discuss today in the NSS conf call which ones should be removed.

Comment 19

[Robert Relyea]

Comment on attachment 602106 [details] [diff] [review]
Patch v1

r+

The active change here is really the SEC_OID_MD5. We check the hash value of the signature from the hash oid returned by the verify function. This oid will have been mapped to SEC_OID_MD5 for all signature types that use MD5 (even if, for instance, ECC was used).

bob

Comment 20

[Varga Viktor]

(In reply to Kai Engert (:kaie) from comment #7)
> Test case:
> 
> - use a separate test profile, please
> 
> - install my test CA from http://kuix.de/ca/nss-test-ca.php
>   (check the boxes, OK)
> 
> - go to https://kuix.de:9450
> 
> As of today (not fixed), you fill see my homepage.
> Click identity button, view certificate, details, click kuix.de, click cert
> signature alg, you should see MD5.
> 
> 
> Expected (when using a build that contains the fix from this bug):
> 
> - use the same test profile as above
> 
> - go to https://kuix.de:9450
> 
> - you should see an error page
> 
> - you should be able to add an override and connect to the page


Dear Kai,
Your test case should polished, to cover the possible MD5 cases.
(Mozilla forces nowadays the minimum three level CA structure:
lvl 1: root CA; lvl 2: productive CA; lvl 3 end user cert.

Test cases, and their expected results after the MD5 disabled:

1. MD5 selfsigned CA issued a MD5 end user certificate; exp.result: bad
2. MD5 selfsigned CA issued a SHA1 end user certificate; exp.result: okay

The first was your case, the second is not affected by the MD5 bug, because a self signed root certificate is not checked against its signature. You install it because you have the complete certificate. (The algorithm on the top is not matter.)

3. MD5 selfsigned CA root CA issued a MD5 intermediate and that intermediate issued and MD5 end user certificate; exp.result: bad
4. MD5 selfsigned CA root CA issued a MD5 intermediate and that intermediate issued and SHA1 end user certificate; exp.result: bad

The third is clear, because it have MD5 on intermediate and end user level too.
The fourh is a special, because the end user cert has SHA1 algorithm, but it issuer has MD5, which is affected by the MD5 bug. 

Regards, Viktor

Comment 21

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

We should have an MD5-based signed certificate used as part of the automated testing (chains.sh?), so that the behavior is tested as part of the test suite.

CERT_PKIXVerifyCert should return a specific error message when it detects the situation where it could not build a chain because all the options use algorithms with blocked signature algorithms. This will allow applications to detect when this type of error is occurring--e.g. so they can allow the user to override the error, or so they can count the errors using their telemetry systems.

The switch to libpkix in Mozilla products should happen first, so that the above modification to CERT_PKIXVerifyCert could be relied on. Instead, we would need to also have a similar modification to CERT_Verify* if we want to count how often this error occurs (which we do, AFAICT).

Comment 22

[Kai Engert (:KaiE:)]

Checking in secoid.c;
/cvsroot/mozilla/security/nss/lib/util/secoid.c,v  <--  secoid.c
new revision: 1.63; previous revision: 1.62
done

Comment 23

[Kai Engert (:KaiE:)]

(In reply to Varga Viktor from comment #20)

It would be great if you could help getting this tested...


(In reply to Brian Smith (:bsmith) from comment #21)

I don't mind you trying to get such additional work done...

Comment 24

[Kai Engert (:KaiE:)]

This bug doesn't block bug 732390.

Comment 25

[Wan-Teh Chang]

Attachment: Add SEC_ERROR_ALGORITHM_DISABLED_BY_POLICY

Kai,

Could you test this NSS patch with Firefox and see if Firefox
reports a different error code from sec_error_bad_signature?
I don't know if a PSM change is needed to generate the
sec_error_algorithm_disabled_by_policy string.

Thanks a lot.

Comment 26

[Kai Engert (:KaiE:)]

Comment on attachment 607414 [details] [diff] [review]
Add SEC_ERROR_ALGORITHM_DISABLED_BY_POLICY

This bug is closed, we shouldn't do any more code changes in here.

I've moved your patch to bug 738454 and will comment over there.

Comment 27

[Kai Engert (:KaiE:)]

We've decided to backout this change, because:

- the patch isn't necessary for Mozilla applications
  (which can configure their preference on their own)

- it might be preferable to make this change in the next major version of NSS

We consider to keep the old default (accept) on the 3.13.x branch,
and make the change (reject by default) for 3.14.

r=rrelyea for backing out

Reopening.

Checking in secoid.c;
/cvsroot/mozilla/security/nss/lib/util/secoid.c,v  <--  secoid.c
new revision: 1.64; previous revision: 1.63
done

Comment 28

[Kai Engert (:KaiE:)]

This doesn't block the introduction of a new error code (bug 738454).

Comment 29

[Kathleen Wilson]

Should this bug be closed as a duplicate of Bug #650355 (which has been fixed and is planned for FF 16)?

Is Bug #663313, "Stop accepting MD5- and MD2- based OCSP signatures", still needed?

Comment 30

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Kathleen Wilson from comment #29)
> Should this bug be closed as a duplicate of Bug #650355 (which has been
> fixed and is planned for FF 16)?

This is a bug in the NSS product, not Gecko, so it is not a duplicate. Gecko-based software will (by default) block MD5 signatures, but non-Gecko software that uses NSS will still accept MD5 signatures.

> Is Bug #663313, "Stop accepting MD5- and MD2- based OCSP signatures", still
> needed?

I will comment in the bug.

Comment 31

[Kai Engert (:KaiE:)]

checked in again

Checking in secoid.c;
/cvsroot/mozilla/security/nss/lib/util/secoid.c,v  <--  secoid.c
new revision: 1.67; previous revision: 1.66
done