1042479 - mozilla::pkix does not support OID 1.3.14.3.2.29 (OIW's sha1WithRSASignature)

Status: VERIFIED FIXED

(Core :: Security: PSM, defect)

Description

[Ray Satiro]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 20140722000501

Steps to reproduce:

In the latest Aurora I am not able to access websites that are signed by a CA using sha1/rsa1024.

gecko.mstone = 33.0a2
gecko.buildID = 20140722004002


Actual results:

I can no longer monitor web traffic using Fiddler. That may be because Fiddler's CA certificate uses sha1/rsa1024.

------------------
encrypted.google.com uses an invalid security certificate.

The certificate is not trusted because it was signed using a signature algorithm that was disabled because that algorithm is not secure.

(Error code: sec_error_cert_signature_algorithm_disabled)
------------------

Fiddler's CA certificate is already trusted in Firefox as an authority. I clicked 'Add Exception' to add an exception for that particular site but it did nothing.



Expected results:

I understand that RSA 1024 is being phased out (https://wiki.mozilla.org/CA:MD5and1024) but I could use an option to override that. I have a feeling I'm going to find this is not just a problem with my Fiddler CAs.

Also it would be helpful to have an option for testing purposes that I could use to override when there's _any_ error in a certificate chain regardless of the error. Like a "I know what I'm doing" button or something. Thanks

Comment 1

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

[Tracking Requested - why for this release]:

Comment 2

[[:mmc] Monica Chew (no longer reading bugmail)]

Even if we did want to support 1024 bit certs, we are pinning *.google.com in FF 33, so this wouldn't work unless you installed your Fiddler cert as a trust anchor anyway.

https://mxr.mozilla.org/mozilla-aurora/source/security/manager/boot/src/StaticHPKPins.h#835

Comment 3

[[:mmc] Monica Chew (no longer reading bugmail)]

(In reply to [:mmc] Monica Chew (please use needinfo) from comment #2)
> Even if we did want to support 1024 bit certs, we are pinning *.google.com
> in FF 33, so this wouldn't work unless you installed your Fiddler cert as a
> trust anchor anyway.

Nevermind, I see from your initial bug report that you already did this.

Comment 4

[Camilo Viecco (:cviecco)]

 (In reply to Ray Satiro from comment #0)
> User Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101
> Firefox/24.0 (Beta/Release)
> Build ID: 20140722000501
> 
> Steps to reproduce:
> 
> In the latest Aurora I am not able to access websites that are signed by a
> CA using sha1/rsa1024.
> 
> gecko.mstone = 33.0a2
> gecko.buildID = 20140722004002
> 
> 
> Actual results:
> 
> I can no longer monitor web traffic using Fiddler. That may be because
> Fiddler's CA certificate uses sha1/rsa1024.
> 
> ------------------
> encrypted.google.com uses an invalid security certificate.
> 
> The certificate is not trusted because it was signed using a signature
> algorithm that was disabled because that algorithm is not secure.
> 
> (Error code: sec_error_cert_signature_algorithm_disabled)
> ------------------
> 
> Fiddler's CA certificate is already trusted in Firefox as an authority. I
> clicked 'Add Exception' to add an exception for that particular site but it
> did nothing.
> 
> 
> 
> Expected results:
> 
> I understand that RSA 1024 is being phased out
> (https://wiki.mozilla.org/CA:MD5and1024) but I could use an option to
> override that. I have a feeling I'm going to find this is not just a problem
> with my Fiddler CAs.
> 
> Also it would be helpful to have an option for testing purposes that I could
> use to override when there's _any_ error in a certificate chain regardless
> of the error. Like a "I know what I'm doing" button or something. Thanks

Can you please post the Fiddler CA here?

Comment 5

[Camilo Viecco (:cviecco)]

Ray can you please attach the CA that you are using to this bug?

Comment 6

[Ray Satiro]

Attachment: RSA1024 Firefox Test.zip

(In reply to Camilo Viecco (:cviecco) from comment #5)
> Ray can you please attach the CA that you are using to this bug?

Sure. I've attached two certificates, a Fiddler CA certificate and a localhost certificate that I signed with the CA. To reproduce:

Command window:
socat openssl-listen:4433,reuseaddr,cert=localhost.pem,verify=0,fork -

Aurora:
Options > Advanced > Certificates > View Certificates > Authorities > Import > FiddlerRoot.cer
Go to https://localhost:4433/ and you'll see error sec_error_cert_signature_algorithm_disabled.

Comment 7

[Camilo Viecco (:cviecco)]

Firefox is working as expected (we are now being more strict about certificate encodings) . Here is the problem:

The OID for the signature type is incorrect. It is set to 1.3.14.3.2.29 (which is an obsolete value  ({iso(1) identified-organization(3) oiw(14) secsig(3) algorithms(2) sha-1WithRSAEncryption(29)})) the OID you want is 1.2.840.113549.1.1.5 ( sha1WithRSAEncryption ::= {pkcs-1 5}) (see rfc 5280 section 4.1.1.2, which will point you to: rfc 3279 section 2.2.1). 

This happens both in the CA and the End-entitity certificates.

Also, your CA certs have negative serial values (which I think is OK for now) but that I would fix. 

It seems this is a bug on the certificate generation in fiddler.

Comment 8

[Ray Satiro]

Ok thanks for the detail. I will forward your comments to the developer. I filed this bug though because I would like an option to override that behavior, and also an option to override really any block. For some https websites I really don't care if some signer or something in the chain is bad I just need access to the information. That add exception button doesn't always work. Can you consider that? Thanks

Comment 9

[Eric Lawrence (@ericlaw)]

The certificates in question are generated by Microsoft's makecert.exe, which has been used by a huge number of developers for over a decade. If you truly intend to reject all such certificates, you may wish to more carefully weigh the compatibility impact of doing so.

Comment 10

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

See also https://www.mail-archive.com/[e-mail]/msg01402.html and bug 405966.

OID 1.3.36.3.3.1.1 (rsaSignatureWithsha1) is another one to investigate.

Comment 11

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

(In reply to Eric from comment #9)
> The certificates in question are generated by Microsoft's makecert.exe,
> which has been used by a huge number of developers for over a decade.

Thanks. This is helpful to know. Do you know if makecert uses other OIW or non-IETF-standard OIDs for signature or hash algorithms? Is this documented somewhere?

Comment 12

[Eric Lawrence (@ericlaw)]

Hey, Brian-- Unfortunately, I no longer have access to the makecert.exe sources. Its flags include the following that might map to legacy OIDs:

-a - Algorithm. Choices are md5|sha1|sha256|sha384|sha512
-iky - Issuer key type (signature|exchange|<int>)
-sky - Subject key type (signature|exchange|<int>)
-$ - Signing authority (individual|commercial)
-cy - Certificate type (end|authority)
-eku - Comma-separated list of EKU OIDs
-nscp - Include Netscape client auth extension

Comment 13

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

Attachment: Re Object Identifiers Confusion now hath made his masterpiece.htm

The OIW OIDs were documented in http://www.oiw.org/agreements/stable/12s-9412.txt, which no longer works. This old IETF-PKIX mailing list message is the documents the OID:
http://www.imc.org/ietf-pkix/old-archive-97/msg01166.html. I am attaching that message to the bug in case img.org ever stops hosting the oild IETF-PKIX mailing list archive.

Comment 14

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

Attachment: add-support-for-old-OIW-OID.patch

Comment 15

[Sylvestre Ledru [:Sylvestre]]

Tracking because it might break quite a few websites.

Comment 16

[Dana Keeler (she/her) (use needinfo) [:keeler]]

Comment on attachment 8467413 [details] [diff] [review]
add-support-for-old-OIW-OID.patch

Review of attachment 8467413 [details] [diff] [review]:
-----------------------------------------------------------------

r=me

Comment 17

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

https://hg.mozilla.org/integration/mozilla-inbound/rev/19bd60030de4

Comment 18

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

Comment on attachment 8467413 [details] [diff] [review]
add-support-for-old-OIW-OID.patch

Approval Request Comment
[Feature/regressing bug #]: bug 1036107
[User impact if declined]: Some HTTPS websites will not work.
[Describe test coverage new/current, TBPL]: There are automated tests, including a new automated test for this bug.
[Risks and why]: Very Low.
[String/UUID change made/needed]: None.

Comment 19

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/19bd60030de4

Comment 20

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/cd7100982c73

Comment 21

[Matt Wobensmith [:mwobensmith][:matt:]]

Using the instructions in comment 6:

Confirmed issue in Fx33, 2014-08-10.
Verified fixed in Fx33 and Fx34, 2014-08-22.