Closed Bug 1304407 Opened 7 years ago Closed 7 years ago

authentication with client certificate fails in Firefox 49

Categories

(NSS :: Libraries, defect)

Product:
NSS
Component:
Libraries
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(firefox49 wontfix, firefox-esr45 unaffected, firefox50 fixed, firefox51 unaffected, firefox52 unaffected)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox49 --- wontfix
firefox-esr45 --- unaffected
firefox50 --- fixed
firefox51 --- unaffected
firefox52 --- unaffected

People

(Reporter: petko.ivn, Assigned: ttaubert)

References

Details

(Keywords: regression, wsec-tls, Whiteboard: [adv-main50-])

Attachments

(4 files, 2 obsolete files)

screenshots
46.92 KB, application/x-zip-compressed
Details
0001-Bug-1304407-Handle-no-matching-sigAlgs-for-client-ce.patch
4.75 KB, patch
ttaubert
: review+
Details | Diff | Splinter Review
Script to uplift Release 49 to NSS 3.25.1
43 bytes, text/plain
lizzard
: approval-mozilla-release-
Details
Script to uplift Beta 50 to NSS 3.26.2
43 bytes, text/plain
ritu
: approval-mozilla-beta+
Details
Attached file screenshots — 
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36

Steps to reproduce:

We have a webserver (RHEL, Apache 2 with mod_ssl) and application which allows authentication with client certificates (key usage: TLS Web Client Authentication (1.3.6.1.5.5.7.3.2);E-mail protection (1.3.6.1.5.5.7.3.4); signature algorithm: PKCS #1 SHA-256 With RSA Encryption). If client certificate is NOT chosen when accessing the web server, then everything is OK, SSL negotiation is successful with Connection Encrypted (TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, 256 bit keys, TLS 1.2). 
However if a client cert is supplied we get error: Secure Connection Failed

An error occurred during a connection to ******. security library: no security module can perform the requested operation. Error code: SEC_ERROR_NO_MODULE

Moreover the browser complete dies - i.e. it won't open any new pages in a separate tab or window. 
Even the link Learn more… on your error page does not work.

client OS version: Win 10 Enterprise Version 1607, OS Build 14393.187
Browser: Firefox 49.0

The problem appears to be related to TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as if this cipher is disabled (in about:config) then negotiation falls downs to TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and there is no problem with using our client certificates. Issue is also fixed if protocol version is limited to TLS 1.1 (via about:config, security.tls.version.max=2).

The issue was not present in Firefox 48.0.2 as TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 does not appear to be used.


Actual results:

An error occurred during a connection to ********* security library: no security module can perform the requested operation. Error code: SEC_ERROR_NO_MODULE


Expected results:

web page was supposed to display, as it did in 48.0.2
Keywords: wsec-tls
Component: Untriaged → Security: PSM
Product: Firefox → Core
What PKCS#11 modules do you have loaded in Firefox?
Flags: needinfo?(petko.ivn)
Same issue in our Enviornment. If we deaktivate TLS 1.2 on the Webserver the Client Cert Authentication works.

The Following PKCS 11 modueles are loaded:

NSS internal PKCS11 Module V3.25

The Issue is also in  Firefox 49.0.1 Beta an 50.0 Beta with crypto module V 3.26
Tobias, could you use the tool Mozregression to narrow down a regression range, please.
See http://mozilla.github.io/mozregression/ for details.
You can use a specific profile with mozregression (--profile) with PKCS#11 modules loaded.

Run the command mozregression --good=48 then copy here the final pushlog from the repository mozilla-inbound.
Flags: needinfo?(tobias.hoffmann)
Loic, i ran the tool in my enviornment but it only downloads two versions: The first Version is the 48.0a1. It starts an i testet it with authentication well. Then it downloads the next Version 52.0a1 this works well too. So wich log do you want?
The 1st version 48 should be good, and 52 should be bad if the bug is still here (sometimes bugs are already fixed in next versions at the moment when the user is reporting the issue).

Before relaunching Mozgeression, can you test Firefox DE 51 (https://www.mozilla.org/en-US/firefox/developer/all/) and Nightly 52 (https://nightly.mozilla.org/) to know if the bug is reproducible.
Hi Loic, I tested the 2 Versions. The issue is fixed in the nightly build firefox-52.0a1.en-US.win64.installer.exe from nightly.mozilla.org

The actual Version firefox-50.0a2.de.win32.installer.exe from https://www.mozilla.org/en-US/firefox/developer/all/ has still the issue

Which version will be the next release?
So it looks like the bug has been already fixed in 52 (and maybe 51).
New versions are released every 6 weeks (more or less), so according to https://wiki.mozilla.org/RapidRelease/Calendar it should be in 2017.

Anyway, could you find the working range. Nightly 50 started in June 2016, so can you run:
mozregression --find-fix --bad=2016-06-25

Mozregression will download the last build 52 from today (which is good) then the build 50 from 2016-06-25 which should be bad, then the tool will continue the run to narrow down the range.
Ty Tobias.
status-firefox49: --- → affected
status-firefox50: --- → affected
status-firefox51: --- → unaffected
status-firefox52: --- → unaffected
tracking-firefox49: --- → ?
tracking-firefox50: --- → ?
Depends on: 1296266
Flags: needinfo?(tobias.hoffmann)
Keywords: regression
For the record, if you want to find the regression range, you can run mozregression --good=48 --bad=2016-06-25.
If i use this command my mac downloads the https://archive.mozilla.org/pub/firefox/nightly/2016/04/2016-04-25-10-22-03-mozilla-central/firefox-49.0a1.en-US.mac.dmg and asks me if good or bad, but the App wont start. So i can't prove if this Version is defect. I will test it at work again
You can use a slightly different boundary build for the start range.
As FF50 has still the bug, you can use --good=48 --bad=50 e.g.
(dont forget to update mozregression, a new version has been released 2 days ago)
We can confirm the issue with client cert authentication is fixed in developer edition, 51.0a2 (2016-09-26) (64-bit), but now the add-on SignTextJS does not work in this edition, getting the "standard" message
"An error occurred when attempting to sign the content, the errot was: undefined" as if the add-on is not present at all. Is this regression in the browser or we have to address SignTextJS developer (https://github.com/mozkeeler/signTextJS)? Any chance to get this fix for certificate authentication fixed in some update to 49?
Update: looks like trouble with SignTextJS is caused by Electrolysis being on by default in developer edition. With Electrolysis on we get window.crypto.signText is undefined. If you turn off Electrolysis  (Open Preferences and un-check the "Enable multi-process") then SignTextJS fails with a java script error: TypeError: cert.getUsagesString is not a function at main.js:306:5 (signtextjs/lib/main.js, the error is at this line  cert.getUsagesString(true, {}, usages); // true for local-only verification). There is an open issue (since Aug 16) for the trouble with undefined error when multi-process is ON: https://github.com/mozkeeler/signTextJS/issues/40 . But now this doesn't work even with multi-process OFF.
Is this add-on available on AMO too? Or only on Github?
(In reply to Loic from comment #16)
> Is this add-on available on AMO too? Or only on Github?

It's available here: https://addons.mozilla.org/en-US/firefox/addon/signtextjs/ and on GitHub.
David, is there something Mozilla can do to fix this issue for users with F49/50 instead of waiting for the release of FF51 (and the update of the NSS lib which fixes the bug)?
Flags: needinfo?(dkeeler)
We would need to identify what changed in NSS that caused the regression (and the fix, really). We could potentially uplift the change to 50, but it's unlikely this will get fixed for 49, since it's already been released.
Flags: needinfo?(dkeeler)
The symptoms here seem pretty severe. I don't know how many users this affects. David do you know who could investigate further as per comment 19?

(If this is really hurting it could be proposed for a dot release).
Flags: needinfo?(dkeeler)
Unfortunately I can't reproduce this issue with the information given. Petko - are there any more details you can share that would shed some light on how to reproduce this? Alternatively, can you set up a publicly-accessible test server?

Tim - there appears to be an issue with client certificates and TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 in the version of NSS that shipped with Firefox 49, but was fixed by 51. Does that ring any bells?
Flags: needinfo?(dkeeler) → needinfo?(ttaubert)
Hi David, do you need an Testserver for certificate auth to reproduce the Issue? Or do you want to reproduce another issue?
@ David Bolter
for your info:

We use certificate authentication for portal services (Citrix Application) to our Customers. The have now to use IE or Chrome. actually we speak round about 1000 users.
(In reply to David Keeler [:keeler] (use needinfo?) from comment #21)
> Unfortunately I can't reproduce this issue with the information given. Petko
> - are there any more details you can share that would shed some light on how
> to reproduce this? Alternatively, can you set up a publicly-accessible test
> server?
> 
> Tim - there appears to be an issue with client certificates and
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 in the version of NSS that shipped
> with Firefox 49, but was fixed by 51. Does that ring any bells?

Sorry, we can no longer reproduce this. Our client re-configured their front end servers and removed TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. So authentication is working now by negotiation a different cipher.
Based on comment 24, this is not an issue anymore. Please reopen if that's not the case.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
status-firefox49: affected → unaffected
status-firefox50: affected → unaffected
tracking-firefox49: ? → ---
tracking-firefox50: ? → ---
Resolution: --- → WORKSFORME
NO, its not fixed. Downgrading encryption is never the solution to fixing bugs. Besides the build wherein it was fixed has an even worse problem. Please read my comments above. SignTextJS does not work in aurora at all, with or without electrolysis. This addon is being used by some 70 thousand people and there is no point in using client certificates in our applications if end users can't sign content with them.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
tobias, did you retry to find the regressing bug in FF48?
Loic, no i got no time this week. I will try it tomorrow.
I test mozregression --good=48 --bad=2016-06-25 but Firefox doesnt start. mozregression is at new version. probably an issue with my mac. i setup an vm and will start it again.
You can try different dates, like --good=47 --bad=50
No chance, he is downloading and the he do nothing:

Tobiass-MacBook-Pro:~ tobias$ mozregression --good=47 --bad=50
**********
You should use a config file. Please use the --write-config command line flag to help you create one.
**********

 0:00.39 INFO: Using date 2016-08-01 for release 50
 0:00.39 INFO: Using date 2016-03-07 for release 47
 0:05.61 INFO: Testing good and bad builds to ensure that they are really good and bad...
 0:05.62 INFO: Downloading build from: https://archive.mozilla.org/pub/firefox/nightly/2016/03/2016-03-07-06-29-03-mozilla-central/firefox-48.0a1.en-US.mac.dmg
===== Downloaded 100% =====
 0:24.39 INFO: Running mozilla-central build for 2016-03-07
 1:08.94 INFO: Launching /private/var/folders/ry/qjtl0k3x7mlbqpj3qby2x6_r0000gn/T/tmp42qVoB/FirefoxNightly.app/Contents/MacOS/firefox
 1:09.17 INFO: application_buildid: 20160307062903
 1:09.17 INFO: application_changeset: be593a64d7c6a826260514fe758ef32a6ee580f7
 1:09.17 INFO: application_name: Firefox
 1:09.17 INFO: application_repository: https://hg.mozilla.org/mozilla-central
 1:09.17 INFO: application_version: 48.0a1
Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry' or 'exit' and press Enter):
Do you see firefox in the process manager?
Ive downloaded ubuntu lts so i test it on an clean system.

Actually i am on the supermarket 
Hi Loic, here is the output:

22:20.74 INFO: Oh noes, no (more) inbound revisions :(
22:20.74 INFO: Last good revision: 3f6483d4dfb3af6995627c30dc8b9ea885d986e5
22:20.74 INFO: First bad revision: 3a53ff76208b2cfe4b8d77f17aec627387773fa8
22:20.74 INFO: Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=3f6483d4dfb3af6995627c30dc8b9ea885d986e5&tochange=3a53ff76208b2cfe4b8d77f17aec627387773fa8

22:21.86 INFO: Looks like the following bug has the changes which introduced the regression:
https://bugzilla.mozilla.org/show_bug.cgi?id=1277255

Do you need anymore infos?
Ty.
Blocks: 1277255
Flags: needinfo?(petko.ivn)
So NSS 3.25 regressed and NSS 3.27 fixed it.
I'm not sure yet what exactly happens because I can't quite reproduce it, but I played around with a few lines that seemed suspicious:


Bug 1179338 introduced flexible hashes for cert_verify messages:

https://hg.mozilla.org/projects/nss/rev/893c116cba8b

Bug 923089 introduced cipher suites with SHA-384 as the PRF:

https://hg.mozilla.org/projects/nss/rev/893c116cba8b

Both landed in 3.25. My guess is that the first might contain the bug we're hitting, the second bug enables the new cipher suites and thus triggers it.

Bug 1287271 landed in 3.27, that rewrites the signature schemes code for TLS 1.3 and probably fixed the bug.


So here's the interesting thing:

https://hg.mozilla.org/projects/nss/file/NSS_3_25_RTM/lib/ssl/ssl3con.c#l10209

That shows ssl3_DecideTls12CertVerifyHash(), a function introduced by the first bug above. It's supposed to set |ss->ssl3.hs.tls12CertVerifyHash| and that's then later used in ssl3_SendCertificateVerify() to compute a hash and sign it. Now if somehow tls12CertVerifyHash ends up with a bogus value we crash with:

> client: Handshake failed with error -8128: security library: no security module can perform the requested operation.

That seems to perfectly match what's given in comment #0. What I did is to put this at the end of ssl3_DecideTls12CertVerifyHash():

> ss->ssl3.hs.tls12CertVerifyHash = 0xff;

Now, he we could end up in this situation I don't know...
Flags: needinfo?(ttaubert)
We run into the samer error when ss->ssl3.hs.tls12CertVerifyHash = 0, i.e. unchanged from it's value when the .hs struct is created. That can easily happen when ssl3_ExtractClientKeyInfo() fails, ssl3_DecideTls12CertVerifyHash() has no way to return an error code.
ssl3_ExtractClientKeyInfo() was used in 3.24 too but a failure there didn't have the same consequences:

https://hg.mozilla.org/projects/nss/file/NSS_3_24_RTM/lib/ssl/ssl3con.c#l7557

We would simply destroy ss->ssl3.hs.backupHash, but AFAICT we would still send the cert_verify message.

So my guess is that CERT_ExtractPublicKey(ss->ssl3.clientCertificate) fails for some reason. We obviously need to catch errors here better, but it would also be very interesting to know what kind of client certificates reproduce this bug...

Tobias, any chance you can tell us more about the client certificate itself? Could you paste the ASN.1 dump and blank out the private (and public) key maybe? That might help!
Flags: needinfo?(tobias.hoffmann)
FTR, ssl3_TLSSignatureAlgorithmForKeyType() in ssl3_ExtractClientKeyInfo() could fail too, of course.
Ok, so the likely version here is that the server sends a CertificateRequest message containing only signature algorithms that don't match the client certificate's keyType. So that seems like an OpenSSL bug that we handle terribly.
Or a configuration bug, the poor server can't know what the client will select. Anyway, something along those lines.
If only I could move bugs to the NSS component...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(tobias.hoffmann)
Assignee: nobody → nobody
Component: Security: PSM → Libraries
Product: Core → NSS
Version: 49 Branch → trunk
This one's for NSS 3.25. In case we want to take it along with a point release?
Attachment #8797042 - Flags: review?(martin.thomson)
This one's for NSS 3.26.
Attachment #8797045 - Flags: review?(martin.thomson)
Hi Tim, we use Certificates sha1 certificates from an internal windows ca. how can i create an asn.1 dump?
Hi Tim, is this what you need?

SSL> asn1parse -in /Users/tobias/Desktop/thoffmann.cer -inform DER -out /Users/tobias/Desktop/thoffmann.txt
    0:d=0  hl=4 l=1250 cons: SEQUENCE          
    4:d=1  hl=4 l= 970 cons: SEQUENCE          
    8:d=2  hl=2 l=   3 cons: cont [ 0 ]        
   10:d=3  hl=2 l=   1 prim: INTEGER           :02
   13:d=2  hl=2 l=  10 prim: INTEGER           :XXXXXXXXXXXXXX
   25:d=2  hl=2 l=  13 cons: SEQUENCE          
   27:d=3  hl=2 l=   9 prim: OBJECT            :sha1WithRSAEncryption
   38:d=3  hl=2 l=   0 prim: NULL              
   40:d=2  hl=2 l=  61 cons: SEQUENCE          
   42:d=3  hl=2 l=  11 cons: SET               
   44:d=4  hl=2 l=   9 cons: SEQUENCE          
   46:d=5  hl=2 l=   3 prim: OBJECT            :countryName
   51:d=5  hl=2 l=   2 prim: PRINTABLESTRING   :DE
   55:d=3  hl=2 l=  18 cons: SET               
   57:d=4  hl=2 l=  16 cons: SEQUENCE          
   59:d=5  hl=2 l=   3 prim: OBJECT            :organizationName
   64:d=5  hl=2 l=   9 prim: PRINTABLESTRING   :Companname
   75:d=3  hl=2 l=  26 cons: SET               
   77:d=4  hl=2 l=  24 cons: SEQUENCE          
   79:d=5  hl=2 l=   3 prim: OBJECT            :commonName
   84:d=5  hl=2 l=  17 prim: PRINTABLESTRING   :Company User CA
  103:d=2  hl=2 l=  30 cons: SEQUENCE          
  105:d=3  hl=2 l=  13 prim: UTCTIME           :160216143204Z
  120:d=3  hl=2 l=  13 prim: UTCTIME           :190215143204Z
  135:d=2  hl=2 l=  27 cons: SEQUENCE          
  137:d=3  hl=2 l=  25 cons: SET               
  139:d=4  hl=2 l=  23 cons: SEQUENCE          
  141:d=5  hl=2 l=   3 prim: OBJECT            :commonName
  146:d=5  hl=2 l=  16 prim: PRINTABLESTRING   :sn, givenName
  164:d=2  hl=4 l= 290 cons: SEQUENCE          
  168:d=3  hl=2 l=  13 cons: SEQUENCE          
  170:d=4  hl=2 l=   9 prim: OBJECT            :rsaEncryption
  181:d=4  hl=2 l=   0 prim: NULL              
  183:d=3  hl=4 l= 271 prim: BIT STRING        
  458:d=2  hl=4 l= 516 cons: cont [ 3 ]        
  462:d=3  hl=4 l= 512 cons: SEQUENCE          
  466:d=4  hl=2 l=  59 cons: SEQUENCE          
  468:d=5  hl=2 l=   9 prim: OBJECT            :1.3.6.1.4.1.311.21.7
  479:d=5  hl=2 l=  46 prim: OCTET STRING      [HEX DUMP]:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  527:d=4  hl=2 l=  29 cons: SEQUENCE          
  529:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Extended Key Usage
  534:d=5  hl=2 l=  22 prim: OCTET STRING      [HEX DUMP]:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  558:d=4  hl=2 l=  14 cons: SEQUENCE          
  560:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Key Usage
  565:d=5  hl=2 l=   1 prim: BOOLEAN           :255
  568:d=5  hl=2 l=   4 prim: OCTET STRING      [HEX DUMP]:030205A0
  574:d=4  hl=2 l=  39 cons: SEQUENCE          
  576:d=5  hl=2 l=   9 prim: OBJECT            :1.3.6.1.4.1.311.21.10
  587:d=5  hl=2 l=  26 prim: OCTET STRING      [HEX DUMP]:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  615:d=4  hl=2 l=  29 cons: SEQUENCE          
  617:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Subject Key Identifier
  622:d=5  hl=2 l=  22 prim: OCTET STRING      [HEX DUMP]:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  646:d=4  hl=2 l=  31 cons: SEQUENCE          
  648:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Authority Key Identifier
  653:d=5  hl=2 l=  24 prim: OCTET STRING      [HEX DUMP]:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  679:d=4  hl=2 l=  66 cons: SEQUENCE          
  681:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 CRL Distribution Points
  686:d=5  hl=2 l=  59 prim: OCTET STRING      [HEX DUMP]:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  747:d=4  hl=2 l= 106 cons: SEQUENCE          
  749:d=5  hl=2 l=   8 prim: OBJECT            :Authority Information Access
  759:d=5  hl=2 l=  94 prim: OCTET STRING      [HEX DUMP]:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  855:d=4  hl=2 l=  51 cons: SEQUENCE          
  857:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Subject Alternative Name
  862:d=5  hl=2 l=  44 prim: OCTET STRING      [HEX DUMP]:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  908:d=4  hl=2 l=  68 cons: SEQUENCE          
  910:d=5  hl=2 l=   9 prim: OBJECT            :S/MIME Capabilities
  921:d=5  hl=2 l=  55 prim: OCTET STRING      [HEX DUMP]:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  978:d=1  hl=2 l=  13 cons: SEQUENCE          
  980:d=2  hl=2 l=   9 prim: OBJECT            :sha1WithRSAEncryption
  991:d=2  hl=2 l=   0 prim: NULL              
  993:d=1  hl=4 l= 257 prim: BIT STRING
Comment on attachment 8797042 [details] [diff] [review]
0001-25-Bug-1304407-Handle-no-matching-sigAlgs-for-client-ce.patch

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

::: lib/ssl/ssl3con.c
@@ +10221,5 @@
>  
>      /* Determine the key's signature algorithm and whether it prefers SHA-1. */
>      rv = ssl3_ExtractClientKeyInfo(ss, &sigAlg, &preferSha1);
>      if (rv != SECSuccess) {
> +        return rv;

return SECFailure

@@ +10265,5 @@
> +    if (ss->ssl3.hs.tls12CertVerifyHash == ssl_hash_none) {
> +        return SECFailure;
> +    }
> +
> +    return rv;

return SECSuccess;
Attachment #8797042 - Flags: review?(martin.thomson) → review+
Comment on attachment 8797045 [details] [diff] [review]
0001-26-Bug-1304407-Handle-no-matching-sigAlgs-for-client-ce.patch

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

See other.
Attachment #8797045 - Flags: review?(martin.thomson) → review+
Comment on attachment 8797042 [details] [diff] [review]
0001-25-Bug-1304407-Handle-no-matching-sigAlgs-for-client-ce.patch

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

Oh, I missed a comment.

::: external_tests/ssl_gtest/ssl_loopback_unittest.cc
@@ +485,5 @@
> +  server_->SetSignatureAlgorithms(SignatureEcdsaSha256,
> +                                  PR_ARRAY_SIZE(SignatureEcdsaSha256));
> +
> +  Connect();
> +  CheckKeys(ssl_kea_ecdh, ssl_auth_ecdsa);

IMPORTANT: Please verify that the client DIDN'T provide a certificate.
r=mt
Assignee: nobody → ttaubert
Attachment #8797042 - Attachment is obsolete: true
Attachment #8797045 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #8797710 - Flags: review+
Attachment #8797710 - Attachment filename: 0001-Bug-1304407-Handle-no-matching-sigAlgs-for-client-ce.patch → 0001-Bug-1304407-Handle-no-matching-sigAlgs-for-client-ce.patch, v2
This landed on the NSS 3.26 branch and is available in 3.26.2 beta:

https://hg.mozilla.org/projects/nss/rev/d8200544657f
(In reply to tobias.hoffmann from comment #47)
> Hi Tim, is this what you need?

Tobias, this is exactly what I meant. Thank you! I can't tell whether this would lead to the problem that I think we're hitting, but that's hard to say without a way to reproduce here.
The patch also landed on the NSS 3.25 branch, available in 3.25.1 beta:

https://hg.mozilla.org/projects/nss/rev/c579a83e6d9f
Hi Tim,

if you further need to reproduce the issue, I will give you an certificate and an URL where you can reproduce it.

We only need to transfer the certificate securely to you.
(In reply to tobias.hoffmann from comment #55)
> if you further need to reproduce the issue, I will give you an certificate
> and an URL where you can reproduce it.
> 
> We only need to transfer the certificate securely to you.

That's a great idea, thanks for your help! Contacted you via email :)
Thanks to Tobias I was able to find what's actually going wrong here. The servers sends a CertReq with sigAlgs=[md5+rsa, sha1+rsa, sha256+rsa, sha1+dsa]. We should ignore MD5 here but don't, instead we ignore SHA-1 and treat MD5 as higher priority than SHA-256. Later we fail because we don't support MD5 anymore internally.
Second patch up for review: https://nss-dev.phacility.com/D64
I've noticed that NSS 3.26 won't select the most secure hash algorithm for the signature if multiple are advertised by the server. I wonder if that shouldn't be changed.
Hubert, as always, patches are welcome.  There are changes in NSS 3.27 (I think, it might be 3.28) that change how signature schemes are selected.  Changing the default preference order is something that should be discussed on the nss-dev list, but applications can set their own preference order.  (Note that there is a special carve-out for SHA-1 in some circumstances, you might have hit that.)
Approval Request Comment
[Feature/regressing bug #]: bug 1179338 + bug 923089
[User impact if declined]: When a server requests client authentication and sends MD5 as a signature algorithm, while using a SHA-384 cipher suite, it might happen that the connection will fail and leave the browser in a somewhat unusable state.
[Describe test coverage new/current, TreeHerder]:
[Risks and why]: Low
[String/UUID change made/needed]: None.

If we have another point release (49.0.3?) and want to take a fix, here it is.
Attachment #8799497 - Flags: approval-mozilla-release?
Approval Request Comment
[Feature/regressing bug #]: bug 1179338 + bug 923089
[User impact if declined]: When a server requests client authentication and sends MD5 as a signature algorithm, while using a SHA-384 cipher suite, it might happen that the connection will fail and leave the browser in a somewhat unusable state.
[Describe test coverage new/current, TreeHerder]:
[Risks and why]: Low
[String/UUID change made/needed]: None.
Attachment #8799498 - Flags: approval-mozilla-beta?
Comment on attachment 8799498 [details]
Script to uplift Beta 50 to NSS 3.26.2

Beta50+
Attachment #8799498 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Tim,

If MD5 support in freebl/softoken has been explicitly enabled by setting :
NSS_HASH_ALG_SUPPORT=+MD5
in the environment

then shouldn't MD5 cert requests continue to be accepted ?

Looking at the patch, I don't see anything that would prevent it, but I just want to make sure this case does not regress.
(In reply to Julien Pierre from comment #66)
> then shouldn't MD5 cert requests continue to be accepted ?

No, that option was removed to prevent transcript collision attacks, see bug 1158489. Since NSS 3.19.2.2 we haven't accepted MD5 signatures in TLS.
(In reply to Wes Kocher (:KWierso) from comment #65)
> https://hg.mozilla.org/releases/mozilla-beta/rev/
> f48198e165031b2741df8b64367b65a63c17a263

Pushed a follow-up that includes a necessary change to old-configure.in:

https://hg.mozilla.org/releases/mozilla-beta/rev/d1b244e09392

Otherwise Linux distribution consumers who update Firefox, but package NSS separately, won't notice that they must update NSS too.
Thanks, I guess that probably means that either we don't have any customers still using MD5 certs - which would be a good news, or they have not been current on their server patch updates that include NSS versions newer than 3.19.2.2 - and there have been several.
Comment on attachment 8799497 [details]
Script to uplift Release 49 to NSS 3.25.1

I'd like this to have some time on 50 to shake out any potential  new issues. 50 should release in a few weeks, Nov. 8th.
Attachment #8799497 - Flags: approval-mozilla-release? → approval-mozilla-release-
Liz is this a wontfix for 49 or a maybe ridealong a possible later point release kinda thing?
Flags: needinfo?(lhenry)
It didn't make it into 49.0.2.  If no one strongly objects I'll wontfix for 49. Please feel free to question this if you think it should stay in the queue for another dot release and want to argue for that.
status-firefox49: affected → wontfix
Flags: needinfo?(lhenry)
Status: ASSIGNED → RESOLVED
Closed: 7 years ago → 7 years ago
Resolution: --- → FIXED
Whiteboard: [adv-main50-]
Target Milestone: --- → 3.27
You need to log in before you can comment on or make changes to this bug.