Closed Bug 1180526 Opened 9 years ago Closed 9 years ago

Allow creating exceptions for servers using weak diffie-hellman keys (ssl_error_weak_server_ephemeral_dh_key)

Categories

(Core :: Security: PSM, defect)

Product:
Core
Component:
Security: PSM
Version:
39 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: f0rhum, Unassigned)

References

Details

(Whiteboard: Workaround: Install Disable DHE add-on https://addons.mozilla.org/ja/firefox/addon/disable-dhe/)

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:39.0) Gecko/20100101 Firefox/39.0 Build ID: 20150630154324 Steps to reproduce: Upgraded from 38.0.5 Switched SSL Version Control 0.4.1-Signed to SSLv3 as usual to allow access to my devices I can't upgrade Actual results: Error cant connect Old routers : Generic ~"Secured connection failed" Promise EX8350 RAID controler : ssl_error_weak_server_ephemeral_dh_key Expected results: Allow me to accept, kind of "I know what I do" button and "Store exception" check-boxe, all that may be dependant on previously installed SSL Version Control Thank you
In the lap time I switch back to win32 38.0.5 and stick my linux package managers to same release.
EDIT: I already have security.tls.version.fallback-limit=0
Not a security-sensitive bug. :keeler, is this something we would consider? (I'm not up-to-date on our policy on what we allow people to click through or not)
Group: core-security
Component: Untriaged → Security: UI
Flags: needinfo?(dkeeler)
Product: Firefox → Core
Summary: can't connect ssl v39 → Allow creating exceptions for servers using weak diffie-helmann keys
Summary: Allow creating exceptions for servers using weak diffie-helmann keys → Allow creating exceptions for servers using weak diffie-hellman keys
NSS (the set of underlying crypto libraries) now enforces a hard limit of >= 1023-bits for DH key exchange, as I understand it. It's not something we can change in Firefox, and all discussions I'm aware of have ended in the NSS team indicating that they're not open to lowering the limit. In short, this is not something we can make an overridable error.
Flags: needinfo?(dkeeler)
Component: Security: UI → Security: PSM
User could disable security.ssl3.dhe_rsa_aes_128_sha and security.ssl3.dhe_rsa_aes_256_sha in about:config to work around
Nice and pleasant info Simon, but will they at least get a warning on first connection?
I should have said user should search for .dhe in about:config and disable them, you wont get a warning.
This NSS decision makes me mad. So to get access to my HBA and router I need a workaround that leaves my firefox weaker for the whole web than before. Nasty. Although both my HW is not that old (~ 2008) but no more supported by manufacturers. What about the backward compatibility that is claimed to be an advantage in OSS world?
What specific version of NSS/Firefox introduced this? And what is the bug? I have client who is seeing this on on the FF 38.1 ESR, but NOT the FF 38.0.1 ESR. This seems like a pretty major change to make it in an ESR point release.
Flags: needinfo?(dkeeler)
I saw it first in 39. It is also in ESR and 38.1, but 38.0.1 to 6 are OK
FF could try to connect and on the error retry connection without DHE offered.
FYI bug 1138554 contains all the information about this.
Flags: needinfo?(dkeeler)
I'm using Firefox 31 ESR to access a bunch of legacy devices that use SSLv3 and I have the same problem now. (Simon from comment #5) > User could disable security.ssl3.dhe_rsa_aes_128_sha and > security.ssl3.dhe_rsa_aes_256_sha in about:config to work around I disabled everything dhe and ecdhe but no difference: An error occurred during a connection to x.x.x.x. The server certificate included a public key that was too weak. (Error code: ssl_error_weak_server_cert_key) I also have these set: security.tls.version.min 0 security.use_mozillapkix_verification false Prior to 31.8.0 everything worked. I have a separate profile to access the legacy devices, so I just need a preference that I can use or a workaround and even if it weakens security for the profile, that's fine.
(In reply to Ray Satiro from comment #13) > An error occurred during a connection to x.x.x.x. The server certificate > included a public key that was too weak. (Error code: > ssl_error_weak_server_cert_key) This is not the same error.
Although the thread title was changed by some admin I had also generic ssl error as stated in the first post
(In reply to f0rhum from comment #15) > Although the thread title was changed by some admin Aside: I am not a BMO admin. I changed the title to be solution-oriented. We clearly can't just make the default limits here lower for everyone just because some people have outdated local devices that don't cope with the current limits (cf. comment 8). You seemed to be asking for an exception. If I misunderstood, then what *do* you think we should be doing? (Aside aside: this is a general problem when we have bugreports which are only explicit about "product X does Y and that's wrong" without making the "... it should do Z instead" explicit.) > I had also generic ssl > error as stated in the first post Still doesn't seem like the same error as Ray's (well, without more details, anyway), and in any case, that should be a different bug... if the NSS folks hardcoded the constraint for >1023bit DH keys and can't do anything about that, it may be possible to do something about the other errors, but you'd need to provide more details. Per comment #4, I believe this is essentially cantfix/wontfix. Please let me know if that makes sense or if you think there's something else that can be done here given that the NSS folks have effectively vetoed allowing you to bypass the limit.
Flags: needinfo?(f0rhum)
Flags: needinfo?(dkeeler)
(In reply to :Gijs Kruitbosch from comment #14) > (In reply to Ray Satiro from comment #13) > > An error occurred during a connection to x.x.x.x. The server certificate > > included a public key that was too weak. (Error code: > > ssl_error_weak_server_cert_key) > > > This is not the same error. Well what probably happened is they got the DHE error, took the advice to turn off DHE and are now getting the "too weak" error. Turning off DHE only works if the device/server has a backup that works.
(In reply to :Gijs Kruitbosch from comment #16) > (In reply to f0rhum from comment #15) > > Although the thread title was changed by some admin > > Aside: I am not a BMO admin. I changed the title to be solution-oriented. Sorry Gijs, I didn't want to be rough. As I saw what how wrote and I couldn't edit my post I just didn't check if anybody can change the title. > We clearly can't just make the default limits here lower for everyone just > because some people have outdated local devices that don't cope with the > current limits (cf. comment 8). You seemed to be asking for an exception. If > I misunderstood, then what *do* you think we should be doing? Did you meant "...what do *you* think..." (sorry for my mean english)? If yes, I don't ask an exception for me, not a special release for me, not at all. I understand the concerns of security team, but I'd like (it seems I'm not alone) we could be allowed to store exceptions the same *way* you used to do when we clicked "I understand the risks" then checked (or not) "Store a permanent exception" for self-signed certs. There is worse when FF allows anybody to send sensitive data in plain clear http. Should the FF devs completely drop standard http as well, following the way of thinking of NSS? This is a good school to have warnings sometimes to keep in mind the road is dangerous. Can you transmit the message if you know them and have a better audience than I'll never have? > (Aside aside: this is a general problem when we have bugreports which are > only explicit about "product X does Y and that's wrong" without making the > "... it should do Z instead" explicit.) I already said what Z is several times, e.g. user story and post#28 here https://bugzilla.mozilla.org/show_bug.cgi?id=1090765 and again, and once again just above. Another idea, provide a Bookmarks integration with ssh (don't forget PuTTY) so that if the target box has some ssh server inside you could ~seamlessly~ access it via the pain in the ass port:localhost:port thing. Here is for my expensive Promise SuperTrack EX8350 HBA RAID controller which doesn't have ssh inside. Not a real problem for me because I can can move to the machine and access the HBA via the BIOS (no need of FF/IE/O/GC/S...not even an OS), but think about others who can't go local. What ever here is for my Promise: openssl s_client -ssl3 -connect promise:8443 -showcerts < /dev/null CONNECTED(00000003) depth=0 C = TW, ST = Taiwan, L = Hsin-Chu, O = Promise Technology Inc., OU = NSSG, CN = PC verify error:num=18:self signed certificate verify return:1 depth=0 C = TW, ST = Taiwan, L = Hsin-Chu, O = Promise Technology Inc., OU = NSSG, CN = PC verify return:1 --- Certificate chain 0 s:/C=TW/ST=Taiwan/L=Hsin-Chu/O=Promise Technology Inc./OU=NSSG/CN=PC i:/C=TW/ST=Taiwan/L=Hsin-Chu/O=Promise Technology Inc./OU=NSSG/CN=PC -----BEGIN CERTIFICATE----- MIICZzCCAdCgAwIBAgIETRjydzANBgkqhkiG9w0BAQUFADB4MQswCQYDVQQGEwJU VzEPMA0GA1UECBMGVGFpd2FuMREwDwYDVQQHEwhIc2luLUNodTEgMB4GA1UEChMX UHJvbWlzZSBUZWNobm9sb2d5IEluYy4xDTALBgNVBAsTBE5TU0cxFDASBgNVBAMT C1BDLUNPQVJSQVpFMB4XDTEwMTIyNzIwMDkyN1oXDTIwMTIyNDIwMDkyN1oweDEL MAkGA1UEBhMCVFcxDzANBgNVBAgTBlRhaXdhbjERMA8GA1UEBxMISHNpbi1DaHUx IDAeBgNVBAoTF1Byb21pc2UgVGVjaG5vbG9neSBJbmMuMQ0wCwYDVQQLEwROU1NH MRQwEgYDVQQDEwtQQy1DT0FSUkFaRTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAr7STNnRd4ldqsB5NlsIX2gaHM1WxvdG5lPbgIof8WsC1svRLoIMWk3mT+VWi JThuss7drTXdbmTlQwa+T8Lcron/guPDqqSlxM3/FyqYVyELyLlMicWx5UpFw/y0 AcF+USdX2csiILTEQ26vYPrf/Uj5G7rJ4mlRJV9FGBwZ1PkCAwEAATANBgkqhkiG 9w0BAQUFAAOBgQCW73Oj5TqiKdzeQZVU4j0zcbegTkNN7F+2KtFz3pCaXuhKkUXF BP8DvqC6ieEQvInxZnYGZX4r1PqPqB0iwMlj2RIZy1P03motDTlv38uJjC4fgPrx 6BfN9sC0/l0oqK94/p8jdf6Z+2tGaj33eyUXnRV+kEINHNfMEeWSIqWMGA== -----END CERTIFICATE----- --- Server certificate subject=/C=TW/ST=Taiwan/L=Hsin-Chu/O=Promise Technology Inc./OU=NSSG/CN=PC issuer=/C=TW/ST=Taiwan/L=Hsin-Chu/O=Promise Technology Inc./OU=NSSG/CN=PC --- No client certificate CA names sent --- SSL handshake has read 1215 bytes and written 310 bytes --- New, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA Server public key is 1024 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : SSLv3 Cipher : EDH-RSA-DES-CBC3-SHA Session-ID: 559FDA2BF3B8FA5D6C7F5882610918FCAB4A6E04AC513267D97217039447F4E6 Session-ID-ctx: Master-Key: BC1D5B3A0FBC84F400B295CE154DE5CAEAE937ADD3FCEAE821998025E41A07DD9610C7A476BC84428B73A2253E8E5890 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1436539439 Timeout : 7200 (sec) Verify return code: 18 (self signed certificate) --- DONE Strange, the key is 1024 so it should work Again with tls1: openssl s_client -tls1 -connect promise:8443 -showcerts < /dev/null CONNECTED(00000003) depth=0 C = TW, ST = Taiwan, L = Hsin-Chu, O = Promise Technology Inc., OU = NSSG, CN = PC verify error:num=18:self signed certificate verify return:1 depth=0 C = TW, ST = Taiwan, L = Hsin-Chu, O = Promise Technology Inc., OU = NSSG, CN = PC verify return:1 --- Certificate chain 0 s:/C=TW/ST=Taiwan/L=Hsin-Chu/O=Promise Technology Inc./OU=NSSG/CN=PC i:/C=TW/ST=Taiwan/L=Hsin-Chu/O=Promise Technology Inc./OU=NSSG/CN=PC -----BEGIN CERTIFICATE----- MIICZzCCAdCgAwIBAgIETRjydzANBgkqhkiG9w0BAQUFADB4MQswCQYDVQQGEwJU VzEPMA0GA1UECBMGVGFpd2FuMREwDwYDVQQHEwhIc2luLUNodTEgMB4GA1UEChMX UHJvbWlzZSBUZWNobm9sb2d5IEluYy4xDTALBgNVBAsTBE5TU0cxFDASBgNVBAMT C1BDLUNPQVJSQVpFMB4XDTEwMTIyNzIwMDkyN1oXDTIwMTIyNDIwMDkyN1oweDEL MAkGA1UEBhMCVFcxDzANBgNVBAgTBlRhaXdhbjERMA8GA1UEBxMISHNpbi1DaHUx IDAeBgNVBAoTF1Byb21pc2UgVGVjaG5vbG9neSBJbmMuMQ0wCwYDVQQLEwROU1NH MRQwEgYDVQQDEwtQQy1DT0FSUkFaRTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAr7STNnRd4ldqsB5NlsIX2gaHM1WxvdG5lPbgIof8WsC1svRLoIMWk3mT+VWi JThuss7drTXdbmTlQwa+T8Lcron/guPDqqSlxM3/FyqYVyELyLlMicWx5UpFw/y0 AcF+USdX2csiILTEQ26vYPrf/Uj5G7rJ4mlRJV9FGBwZ1PkCAwEAATANBgkqhkiG 9w0BAQUFAAOBgQCW73Oj5TqiKdzeQZVU4j0zcbegTkNN7F+2KtFz3pCaXuhKkUXF BP8DvqC6ieEQvInxZnYGZX4r1PqPqB0iwMlj2RIZy1P03motDTlv38uJjC4fgPrx 6BfN9sC0/l0oqK94/p8jdf6Z+2tGaj33eyUXnRV+kEINHNfMEeWSIqWMGA== -----END CERTIFICATE----- --- Server certificate subject=/C=TW/ST=Taiwan/L=Hsin-Chu/O=Promise Technology Inc./OU=NSSG/CN=PC issuer=/C=TW/ST=Taiwan/L=Hsin-Chu/O=Promise Technology Inc./OU=NSSG/CN=PC --- No client certificate CA names sent --- SSL handshake has read 1191 bytes and written 361 bytes --- New, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA Server public key is 1024 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : EDH-RSA-DES-CBC3-SHA Session-ID: 559FE843280A6DD0AD183E3167B24081C4602F65E0D62C562093138FCF3E4F72 Session-ID-ctx: Master-Key: 9837F8CC0CB6A0E6AB7DA73274DBA25F7C7C23A8AF4AA4BB6868F56A82461BCF9173D6273A5ADB874492967BE5158EAC Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1436543046 Timeout : 7200 (sec) Verify return code: 18 (self signed certificate) --- DONE Maybe for this one a clever guy will find how to tweak the java jetty server... and let us know. > > I had also generic ssl > > error as stated in the first post > > Still doesn't seem like the same error as Ray's (well, without more details, > anyway), and in any case, that should be a different bug... if the NSS folks > hardcoded the constraint for >1023bit DH keys and can't do anything about > that, it may be possible to do something about the other errors, but you'd > need to provide more details. Here is one router with recent firmware: openssl s_client -ssl3 -connect ddwrt:443 -showcerts < /dev/null CONNECTED(00000003) depth=0 C = DE, ST = Saxon, L = Dresden, O = NewMedia-NET GmbH, OU = DD-WRT, CN = NewMedia-NET GmbH, emailAddress = info@dd-wrt.com verify error:num=18:self signed certificate verify return:1 depth=0 C = DE, ST = Saxon, L = Dresden, O = NewMedia-NET GmbH, OU = DD-WRT, CN = NewMedia-NET GmbH, emailAddress = info@dd-wrt.com verify return:1 --- Certificate chain 0 s:/C=DE/ST=Saxon/L=Dresden/O=NewMedia-NET GmbH/OU=DD-WRT/CN=NewMedia-NET GmbH/emailAddress=info@dd-wrt.com i:/C=DE/ST=Saxon/L=Dresden/O=NewMedia-NET GmbH/OU=DD-WRT/CN=NewMedia-NET GmbH/emailAddress=info@dd-wrt.com -----BEGIN CERTIFICATE----- MIIDrjCCApYCCQCcHsB556nEMzANBgkqhkiG9w0BAQUFADCBmDELMAkGA1UEBhMC REUxDjAMBgNVBAgTBVNheG9uMRAwDgYDVQQHEwdEcmVzZGVuMRowGAYDVQQKExFO ZXdNZWRpYS1ORVQgR21iSDEPMA0GA1UECxMGREQtV1JUMRowGAYDVQQDExFOZXdN ZWRpYS1ORVQgR21iSDEeMBwGCSqGSIb3DQEJARYPaW5mb0BkZC13cnQuY29tMB4X DTE0MTAyNjIzMTcxM1oXDTI0MTAyMzIzMTcxM1owgZgxCzAJBgNVBAYTAkRFMQ4w DAYDVQQIEwVTYXhvbjEQMA4GA1UEBxMHRHJlc2RlbjEaMBgGA1UEChMRTmV3TWVk aWEtTkVUIEdtYkgxDzANBgNVBAsTBkRELVdSVDEaMBgGA1UEAxMRTmV3TWVkaWEt TkVUIEdtYkgxHjAcBgkqhkiG9w0BCQEWD2luZm9AZGQtd3J0LmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAO4z3MC/LtFVUzCfgLqZXJmeHw1Yo7Tb vkxRkO+IvNXw0/nH881MXb4doGZ436m+sw+LGyfaoLSmytk9sjkXuwkRPQc1+EYP iGKQHgr43pPM9VNg6Ya80HQtGQNQJNndd8J6pyTQKxBq18DI2D2kDm0eAf9Yk+Qc 2SwxSfncOuZ3Mu9zxdLDcNEQFB7SMCV1Qr8nG2x2/86ZrbnsyeLa4+yH8NwzBOZ5 G7HUFd2CEfQXkyCpKtI0ebHySDxZx6yyFmg1ueJTmom7hJXAnzqZFbQUKma+5C21 OUZDD+E8QxQEGPfiR4+apbZvp3Z8Ff5vTQMRyOjvgAtiCerKGFoN4i0CAwEAATAN BgkqhkiG9w0BAQUFAAOCAQEASrDiC7UXN0JTvFOF+s1Wfdm3W9pAjwE5+en+szd5 9DLi3uFyy3InHItBoSermboSoP51GTkw4BMjnnqPLTS0lg491Rr9VdWracNcvn2c s2r3jzf0TMlu8zZe6S+j/J785rprOIZe2HGRnj+ITgAyiQn/coNe68SY+/hU3TiZ ffzq/tCSSD0tvfULu9lCk7PH8/BX9Na7188dc/GI6gpUOvTPh1V6eLePaWfE4fqo 1MGlydizOaGJ+WLOlsl68Zi1jyXkXxmPeiLLWUTHqw9+z4tfnwGmQUwrf2cZJH3X /WkpgJP0nn7KMXk/EQYHLxrul9ohlYyFlEM0R6vzyx0T5Q== -----END CERTIFICATE----- --- Server certificate subject=/C=DE/ST=Saxon/L=Dresden/O=NewMedia-NET GmbH/OU=DD-WRT/CN=NewMedia-NET GmbH/emailAddress=info@dd-wrt.com issuer=/C=DE/ST=Saxon/L=Dresden/O=NewMedia-NET GmbH/OU=DD-WRT/CN=NewMedia-NET GmbH/emailAddress=info@dd-wrt.com --- No client certificate CA names sent --- SSL handshake has read 1124 bytes and written 468 bytes --- New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : SSLv3 Cipher : DES-CBC3-SHA Session-ID: 010000008418B1279189FF71DA3C91F51D4E6646BCEC4D560DE201BB8188F14D Session-ID-ctx: Master-Key: 355AFC9C075028BAA810AF5ABEC060179F12C4900879499EF42E12D88A68E148D9D636B5A1EF212F7EEEB1FC756A7674 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1436542401 Timeout : 7200 (sec) Verify return code: 18 (self signed certificate) --- DONE and same with tls1 openssl s_client -tls1 -connect ddwrt:443 -showcerts < /dev/null CONNECTED(00000003) 140394124981920:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:598: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 0 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1436542620 Timeout : 7200 (sec) Verify return code: 0 (ok) --- And another one openssl s_client -ssl3 -connect cluchtomer:8800 -showcerts < /dev/null CONNECTED(00000003) depth=0 C = DE, ST = Saxon, L = Dresden, O = NewMedia-NET GmbH, OU = DD-WRT, CN = NewMedia-NET GmbH, emailAddress = info@dd-wrt.com verify error:num=18:self signed certificate verify return:1 depth=0 C = DE, ST = Saxon, L = Dresden, O = NewMedia-NET GmbH, OU = DD-WRT, CN = NewMedia-NET GmbH, emailAddress = info@dd-wrt.com verify return:1 --- Certificate chain 0 s:/C=DE/ST=Saxon/L=Dresden/O=NewMedia-NET GmbH/OU=DD-WRT/CN=NewMedia-NET GmbH/emailAddress=info@dd-wrt.com i:/C=DE/ST=Saxon/L=Dresden/O=NewMedia-NET GmbH/OU=DD-WRT/CN=NewMedia-NET GmbH/emailAddress=info@dd-wrt.com -----BEGIN CERTIFICATE----- MIICJDCCAc4CCQCJb11IbtwZuTANBgkqhkiG9w0BAQUFADCBmDELMAkGA1UEBhMC REUxDjAMBgNVBAgTBVNheG9uMRAwDgYDVQQHEwdEcmVzZGVuMRowGAYDVQQKExFO ZXdNZWRpYS1ORVQgR21iSDEPMA0GA1UECxMGREQtV1JUMRowGAYDVQQDExFOZXdN ZWRpYS1ORVQgR21iSDEeMBwGCSqGSIb3DQEJARYPaW5mb0BkZC13cnQuY29tMB4X DTEwMDgwNjIyNDkyN1oXDTIwMDgwMzIyNDkyN1owgZgxCzAJBgNVBAYTAkRFMQ4w DAYDVQQIEwVTYXhvbjEQMA4GA1UEBxMHRHJlc2RlbjEaMBgGA1UEChMRTmV3TWVk aWEtTkVUIEdtYkgxDzANBgNVBAsTBkRELVdSVDEaMBgGA1UEAxMRTmV3TWVkaWEt TkVUIEdtYkgxHjAcBgkqhkiG9w0BCQEWD2luZm9AZGQtd3J0LmNvbTBcMA0GCSqG SIb3DQEBAQUAA0sAMEgCQQC+k3NAQkhn+kYP5m9woSM56sIi0AdjuU8PRgPOux+r 5IBk4VddNNavkHFUlMuCoGsZ+fgEp64EX+f/S+ZsFzsXAgMBAAEwDQYJKoZIhvcN AQEFBQADQQC8t7e1nShAKuLKxp5PGTdgBj8D+N0uUemub/16NcrXpZ84BlzwMwcJ 1lFC4egtbua0dpbITzV/l37Uz/std2Yk -----END CERTIFICATE----- --- Server certificate subject=/C=DE/ST=Saxon/L=Dresden/O=NewMedia-NET GmbH/OU=DD-WRT/CN=NewMedia-NET GmbH/emailAddress=info@dd-wrt.com issuer=/C=DE/ST=Saxon/L=Dresden/O=NewMedia-NET GmbH/OU=DD-WRT/CN=NewMedia-NET GmbH/emailAddress=info@dd-wrt.com --- No client certificate CA names sent --- SSL handshake has read 730 bytes and written 276 bytes --- New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA Server public key is 512 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : SSLv3 Cipher : DES-CBC3-SHA Session-ID: 020000007FBE7585BFE626F8EDF86B31E9C46EC6E6D530EFB45EF41507D68E54 Session-ID-ctx: Master-Key: 7A0118C58AA26766921278144FB73E8C7D78B5038F6701377005A7850BF3B687A4C38BBB2F814AB8F7E6381F4977B824 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1436543314 Timeout : 7200 (sec) Verify return code: 18 (self signed certificate) --- DONE same device tls1: openssl s_client -tls1 -connect cluchtomer:8800 -showcerts < /dev/null CONNECTED(00000003) 139852248315552:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:598: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 0 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1436543342 Timeout : 7200 (sec) Verify return code: 0 (ok) --- > Per comment #4, I believe this is essentially cantfix/wontfix. Please let me > know if that makes sense or if you think there's something else that can be > done here given that the NSS folks have effectively vetoed allowing you to > bypass the limit. I hope Best regard (sorry for the **** above)
Flags: needinfo?(f0rhum)
(In reply to f0rhum from comment #18) > > You seemed to be asking for an exception. If > > I misunderstood, then what *do* you think we should be doing? > > Did you meant "...what do *you* think..." (sorry for my mean english)? If > yes, I don't ask an exception for me, not a special release for me, not at > all. Sure, I meant you want a way to add an exception for particular servers/certificates/sites. Sorry for my brevity. This: > I'd like (it seems I'm > not alone) we could be allowed to store exceptions the same *way* you used > to do when we clicked "I understand the risks" then checked (or not) "Store > a permanent exception" for self-signed certs. seems to match my interpretation. If NSS does not allow us to override the limit, then it is not possible to implement this (adding an exception for these servers) in Firefox.
So what is more dangerous? Connecting to a server with a self signed cert? Or connecting to a server with weak encryption? Why do we allow one to be overridden and not the other? Who makes the decision as to whether a user can override something?
(In reply to Mike Kaply [:mkaply] from comment #20) > So what is more dangerous? Connecting to a server with a self signed cert? > Or connecting to a server with weak encryption? > > Why do we allow one to be overridden and not the other? > > Who makes the decision as to whether a user can override something? Currently, it's more of a technical limitation than a policy limitation. Errors that occur down in NSS that are related to encryption (weak keys, hmac errors, etc.) can't be overridden. Cert-related errors take place in a different layer, which is why you are able to override errors related to them.
(In reply to April King from comment #21) > (In reply to Mike Kaply [:mkaply] from comment #20) > > So what is more dangerous? Connecting to a server with a self signed cert? > > Or connecting to a server with weak encryption? > > > > Why do we allow one to be overridden and not the other? > > > > Who makes the decision as to whether a user can override something? > > Currently, it's more of a technical limitation than a policy limitation. > Errors that occur down in NSS that are related to encryption (weak keys, > hmac errors, etc.) can't be overridden. Cert-related errors take place in a > different layer, which is why you are able to override errors related to > them. Is it possible to put a front end cert override in place preemptively (programmatically)? So that the NSS code doesn't happen at all? Or would the check still happen?
In general, checks that NSS makes aren't overridable. In some cases we can configure the behavior of NSS to change, but this isn't one of those cases (unless we as gecko patch NSS to have a different hard-coded limit).
Flags: needinfo?(dkeeler)
So it see I'm dead. I read that FF have (or had?) a hardcoded list of well known web sites or DN or servers still using weak security items and this list is (was) used to workaround the new NSS. Could we have an extension to this list of fqdn:port and ip:port that we could manage on our own. This could be provided as an add-on or only (better, with no AMO signed add-on at all to prevent high spread of the feature) as an entry in about:config? Thanks
I'm having trouble with a similar issue, namely I cannot use Firefox any more to access my Linksys router. Getting ssl_error_weak_server_cert_key. It is very disappointing to find out there's no way to add an exception (about:config style exception for a single ip would do). This just feels like NSS is deciding what I should be able to do with my own computer, not good. Workaround in comment 5 does not work for me and is even less wanted as it would affect all sites.
Probably Firefox should retry the connection with another cipher when possible. Example: www.acs.gazprombank.ru (which is kind of important for many people) Available ciphers: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 768 bits TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16) DH 768 bits So there are two compatible ciphers that could be utilised instead of rejecting the connection. Why doesn't this happen?
I am also having this trouble while using debit card online. my bank website acs.onlinesbi.com is not opening. I am also getting the error ssl_error_weak_server_ephemeral_dh_key
This is just appalling. Obviously need to find another browser that doesn't act so much like a police state.
While not a perfect solution, disable https on the router and only access via http. As long as you access from a cable and not wireless, there's nothing to intercept.
Even on wire communications can be intercepted. More thread if it is a remote device. And it is.
Regardless of the minor security concern, it's a workaround.
workaround != regression
Well, I know the workaround is a regression, but I can no longer connect to our company internal database. Which makes me 0% efficient. I have to switch back to Internet Explorer, which is detrimental to my mental health. True, the people who should fix this are our IT people, but the folks running the database don't know anything about this, and there is no IT department, as that would cost money. So, I disable security.ssl3.dhe_rsa_aes_xxx_sha and rely on not having problems somewhere externally.
Hi, please mark the bug a confirmed. Reading the thread it is evident that many people are encountering this. Particularly, it looks like the config screens of most linksys routers are now inaccessible from Firefox. Secondly, please consider treating this as a security issue. While it is not a security issue per se, it is a security issue that to use items such as routers, etc Firefox compels you to switch off completely https in the routers. Incidentally, how can this be all NSS fault? According to various sources, Google Chrome uses NSS too, but does not have such issue.
Whiteboard: Workaround: Install Disable DHE add-on https://addons.mozilla.org/ja/firefox/addon/disable-dhe/
Adding a error name to the summary to reduce unrelated noise. (In reply to Sergio Callegari from comment #34) > Incidentally, how can this be all NSS fault? According to various sources, > Google Chrome uses NSS too, but does not have such issue. The LinkSys router issue is bug 1182742. By the way, Chrome no longer uses NSS. It migrated to BoringSSL (a Google fork of OpenSSL).
Summary: Allow creating exceptions for servers using weak diffie-hellman keys → Allow creating exceptions for servers using weak diffie-hellman keys (ssl_error_weak_server_ephemeral_dh_key)
Thanks for the explanation on boringSSL. Wonder if it makes sense to keep an independent bug for any single device with weak keys as it is now: - There was one for "webmin" that was then closed because if you have your own instance of webmin, then you can change your keys. - There is one for Linksys (actually for the specific wrt54gl model, but I'm seeing this on a wrt160nl too). - There is this one that is sort of more generic Wouldn't it be better to make all reports duplicates of this one? Can someone who knows things well enough clarify the implications of setting security.ssl3.dhe_rsa_aes_xxx_sha to off to workaround the current issue? Would it be better to install the switch profile extension and have a specific profile with that setting just to admin legacy devices?
The fact is this isn't an issue about one person needing an exception like they are trying to make out. It is many devices with millions of users being hit with repercussions. Some of those devices could have their firmware update if they could be accessed. But no mozilla saw fit to do this with no major warning to the public at all. I feel it shows their utter disregard for how it effects others. If they really were concerned about security they would make a way people could access the device and then update it. A great deal of these are also on the interior of private networks and at next to no risk unless a system before it gets compromised first. Mozilla is acting ridiculous like the US government and its nanny state mentality. Ultimately though it is Mozilla's product and they can build it how they see fit. We can also choose to use another product and with the current licensing we could also use a fork of this product and say to hell with the one directly from them. Probably the best option at this time. At least till they realize their actions adversely effect others. But please Mozilla tell me how preventing me from accessing a device or server that needs SSL to be access via browser improves security of the internet if I can't get to it and update it. I sure as hell am not taking them down because you want to act like morons. Minimum certificate length isn't something the fast majority of internet users were ever told about. Before they implemented this they should have done a television campaign to inform the general public it was coming.
I'm also suffering from this security decision. I have older Cisco routers and several servers running webmin I can no longer administer using FF. The routers can't be upgraded and I'm not going to waste hours working on LAN servers that work fine. Is the official answer use another browser ? There really needs to be a way for a user to force the connection.
Welcome to the despite club Ed. They forced me to use FF38+SSL version control plugin 0.4.1-signed (no more available @AMO) beside some tweak in about:config Just sad.
(In reply to Ed from comment #39) > I'm also suffering from this security decision. I have older Cisco routers > and several servers running webmin I can no longer administer using FF. The > routers can't be upgraded and I'm not going to waste hours working on LAN > servers that work fine. Is the official answer use another browser ? There > really needs to be a way for a user to force the connection. I have some devices that I'm accessing using Firefox 24 ESR just because they're too old to access with anything new, doesn't matter if it's Firefox or Chrome.
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Recommending the Diasble DHE add-on that may cause other problems, rather than fixing the base issue. Is there no way to override this DHE problem with "private network" IP addresses in the 16-bit block of 192.168.##.# ??
+1 . more any address in 10.0.0.0/8 and 172.16.0.0/12 ranges
I also strongly urge to provide an override option. The current policy of not providing it is counter-productive. There are so many devices using weak ciphers, when in a local network the security risk is minimal to non-existent. In my case it's an UPS that needs to be adminned. It's not even accessible from the internet, only from the LAN. But in order to be able to access it I need to set [security.ssl3.dhe_rsa_aes_128_sha;false] globally, so now I won't even get a warning when connecting to sites using 128 ciphers on the internet. I *do* want strong warnings when accessing a site using a weak cipher on the internet. I *don't* want it to be made impossible to admin my own devices in my own LAN. Imho the solution is rather easy; change the above mentioned boolean into a list of exceptions. You could even append an extra warning when adding a public network address to the exceptions. The current policy is too rigid. On paper it may look good, but the harsh reality is that there are many, many devices around using weak ciphers. When users are forced to make global exceptions just to access those devices, overall security is weakened instead of strengthened. When hardening steel too much it becomes brittle, it must be able to bend. Please reconsider.
+1. Even worse, I have to stick to FF38+SSL Version control to access my internal old devices, which makes FF the less secure browser of all.
Bug 1279479 will make this unnecessary because we will no longer offer DHE (in the first handshake).
You need to log in before you can comment on or make changes to this bug.