Closed Bug 1084606 Opened 5 years ago Closed 5 years ago

Allow overrides for MOZILLA_PKIX_ERROR_INADEQUATE_KEY_SIZE (some cases of SEC_ERROR_INVALID_KEY in Fx33)

Categories

(Core :: Security: PSM, defect)

33 Branch
x86_64
All
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla36
Tracking Status
firefox34 --- fixed
firefox35 --- fixed
firefox36 --- fixed

People

(Reporter: f0rhum, Assigned: Cykesiopka)

References

Details

Attachments

(2 files)

Hi
As soon as I upgraded from FF32 to FF33, I got this error (translated from french)
Secure connection failure
An error happened during connection to www.xxx.yyy.zzz. The key does not manage the requested operation. (Error code : sec_error_invalid_key)...
 
Until this error I dayly used these web sites (they are https GUIs of routers) who use self-signed certificates for which I have security exceptions stored for years. I checked the certs with a FF32 and the revocation date is 2020).
Unfortunately I can't see a way to workaround but reverting back to FF32.

Maybe this is related to this bug "mozilla::pkix, cannot override sec_error..." : https://bugzilla.mozilla.org/show_bug.cgi?id=1042889
Severity: normal → blocker
OS: Linux → All
Version: 34 Branch → 33 Branch
Severity: blocker → normal
Did you try to test with a fresh profile?
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

If it's bug 1042889, it should be fixed in the next Nightly, so you can install it and test it tomorrow.
Yes I tested with a new fresh profile: same behaviour.
Severity: normal → blocker
This might be due to the key size checking added in Bug 360126. Could you try using Firefox 34 or above? If it is due to the key size, you should see the error code MOZILLA_PKIX_ERROR_INADEQUATE_KEY_SIZE.

(Yes, the re-use of SEC_ERROR_INVALID_KEY is confusing, I probably should have at least nominated the patch to update the error code for Firefox 33 as well.)
Flags: needinfo?(f0rhum)
Component: Security → Security: PSM
Product: Firefox → Core
f0rhum, it would be helpful to have a copy of the certificates the device you're trying to connect to sends. Can you post the output of the following command:

openssl s_client -connect host:port -showcerts < /dev/null

Thanks.
Not a blocker.
Severity: blocker → normal
openssl s_client -connect 192.168.22.253:443 -showcerts < /dev/null
CONNECTED(00000003)
139944457442976:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 305 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

NewMedia-NET GmbH
Identity: NewMedia-NET GmbH
Checked by: NewMedia-NET GmbH
Expires on: 03/08/2020

Subject name
C (Pays):	DE
ST (État):	Saxon
L (Localité):	Dresden
O (Organisation):	NewMedia-NET GmbH
OU (Unité d'organisation):	DD-WRT
CN (Nom courant):	NewMedia-NET GmbH
EMAIL (Adresse électronique):	info@dd-wrt.com
Issuer name
C (Pays):	DE
ST (État):	Saxon
L (Localité):	Dresden
O (Organisation):	NewMedia-NET GmbH
OU (Unité d'organisation):	DD-WRT
CN (Nom courant):	NewMedia-NET GmbH
EMAIL (Adresse électronique):	info@dd-wrt.com
Issued certificate
Version:	1
serial number:	00 89 6F 5D 48 6E DC 19 B9
Non valid before:	2010-08-06
Non valid after:	2020-08-03
Certificate checksum
SHA1:	49 CC 60 20 D5 9B 7A 5D AE AA 11 DD 95 16 03 F1 EF 53 69 1F
MD5:	68 F9 6C 7E D6 2E 81 45 56 18 EA 7C AC 9A E2 9D
Pub key info
Key algorithm:	RSA
Key parameters:	05 00
Key size:	512
Key SHA1 checksum:	9B 8E D0 85 10 34 D8 AC C7 53 75 8A 47 A4 A0 D8 8D C9 E1 78
Public Key:	30 48 02 41 00 BE 93 73 40 42 48 67 FA 46 0F E6 6F 70 A1 23 39 EA C2 22 D0 07 63 B9 4F 0F 46 03 CE BB 1F AB E4 80 64 E1 57 5D 34 D6 AF 90 71 54 94 CB 82 A0 6B 19 F9 F8 04 A7 AE 04 5F E7 FF 4B E6 6C 17 3B 17 02 03 01 00 01
Signature
Signature algorithm:	SHA+ with RSA
Signature parameters:	05 00
Signature:	BC B7 B7 B5 9D 28 40 2A E2 CA C6 9E 4F 19 37 60 06 3F 03 F8 DD 2E 51 E9 AE 6F FD 7A 35 CA D7 A5 9F 38 06 5C F0 33 07 09 D6 51 42 E1 E8 2D 6E E6 B4 76 96 C8 4F 35 7F 97 7E D4 CF FB 2D 77 66 24
Flags: needinfo?(f0rhum)
With FF34.0b1 :

"Error happend when connecting to 192.168.22.253. Server shew a certificate whose key size is too little to establish a secure connection. (Error code: mozilla_pkix_error_inadequate_key_size)."

Will we have an warning+override for this?
Same with 34.0 (update channel: beta)
I'm also looking for an override for this. I've had exceptions for all my servers forever. Now when I attempt to access a page I get "Secure Connection failed (Error code: sec_error_invalid_key)". When I attempt to re-add my exception through Preferences->Advanced->Certificates->View Certificates->Add Exception I get "Unable to obtain identification status for the given site". Re-importing the certificate from a file creates a line with a wildcard for server, but has no effect on my ability to access the site. In the meantime, I'm using Chrome which does not currently have this problem.
I confirm that this happens on 33 while trying to connect to a Tomato router.
Tomato by default generates 512 bit RSA key. I generated 2048 bit key manually and the problem is over.
The HIGHLY INTELLIGENT developers at Mozilla et. al. SHOULD refrain for arbitrarily imposing such restrictions on it's users.  Instead Mozilla et. al. SHOULD notify users SEVERAL VERSION in advance - at least 2 - when security that they're using is going to become invalid.

That way anyone using "embedded" where performance is an issue SHOULD be able to address their security issues IN A TIMELY MANNER rather than on a Monday after everyone upgraded their Firefox browser.

IE When I log into my Linksys with DD-WRT for version of Firefox 31 and 32, I SHOULD have been notified that my RSA KEY LENGTH was too small and would be unsupported in future version, and possible offered some Ron Jeremy pills to compensate for my inadequate length.

Decisions like this are why I get questions from management such as: "Why aren't we using Chrome if it works?"

While I understand the technical reason for imposing these limits - at least I like to think I do - I do not agree in the manner in which Mozilla informed me of such limits.

Some security is better than none.  This router, and my home router - Linksys WRT-54G r2, which is running Open-WRT - have https only access.  At some point the limits will be raised that force me to either A) Buy a new router because the SoC in my current router isn't fast enough for the imposed limits or B) Download a new browser because it supports my poor security choices.

The appropriate method to solve this is to notify the users of the deprecation of their security configuration at least version in advance - probably 2 with Firefox's update schedule.  Increase the DEFAULT limits in the next version or two.  Allow the choices to be overridden by the user.

NIST has increased the limits from 256 to 2048 in the span of 5 years.  Chances are, these limits will be raised again.  Stop breaking networks with use your product.  Inform the user, change the default, allow the limits to be manually lowered.
Same problem with WRT54GL with the firmware linksys 04/08/2013 Ver.4.30.16 (Build 6).
I am stuck...
I wrote a tutorial describing how to generate a longer (than 512 bit) key on Tomato routers:

http://stackoverflow.com/a/26520093/2178047

Maybe it will be helpful to some.
See Also: → 1089179
I posed the question of what to do about this bug on #security over IRC:

> 1:16:00 PM - keeler: Cykesiopka: I think that might be fixed by the plan in 
> bug 1042889 (i.e. heuristically determine if a certificate isn't in the "real"
> pki and allow overrides in more cases if so)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Secure connection failure .... sec_error_invalid_key → Allow overrides for MOZILLA_PKIX_ERROR_INADEQUATE_KEY_SIZE (some cases of SEC_ERROR_INVALID_KEY in Fx33)
With the latest FF34beta windowsXP, I now have no more specific error message on error: instead I get some generic message:
"Connection was broken (La connexion a été interrompue)

The connection to 192.168.xx.xx:8080 was broken when loading page
    The site may be temporarily unvailable or overloaded. Retry later ;
    If you can't browse any web site, check network connection of your computer ;
    If your pc/netwrk is firewall/proxy protected, make sure Firefox is allowed to Web"

from linux:
openssl s_client -connect 192.168.xx.xx:8080 -showcerts < /dev/null 
CONNECTED(00000003)
140465755293344:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 305 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE

I posted attachments in the FF34 thread : https://bugzilla.mozilla.org/show_bug.cgi?id=1089179
After reading s_client man,
"-ssl2, -ssl3, -tls1, -no_ssl2, -no_ssl3, -no_tls1, -no_tls1_1, -no_tls1_2
           these options disable the use of certain SSL or TLS protocols. By default the initial handshake uses a method which should be compatible with all
           servers and permit them to use SSL v3, SSL v2 or TLS as appropriate.

           Unfortunately there are still ancient and broken servers in use which cannot handle this technique and will fail to connect. Some servers only work if
           TLS is turned off."



I tried and this time got info:
openssl s_client -connect 192.168.xx.xx:8080 -showcerts -no_tls1  < /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-----
MIIDrjCCApYCCQC7QY1XOk0Y6TANBgkqhkiG9w0BAQUFADCBmDELMAkGA1UEBhMC
REUxDjAMBgNVBAgTBVNheG9uMRAwDgYDVQQHEwdEcmVzZGVuMRowGAYDVQQKExFO
ZXdNZWRpYS1ORVQgR21iSDEPMA0GA1UECxMGREQtV1JUMRowGAYDVQQDExFOZXdN
ZWRpYS1ORVQgR21iSDEeMBwGCSqGSIb3DQEJARYPaW5mb0BkZC13cnQuY29tMB4X
DTE0MTAyNzAwMTExMFoXDTI0MTAyNDAwMTExMFowgZgxCzAJBgNVBAYTAkRFMQ4w
DAYDVQQIEwVTYXhvbjEQMA4GA1UEBxMHRHJlc2RlbjEaMBgGA1UEChMRTmV3TWVk
aWEtTkVUIEdtYkgxDzANBgNVBAsTBkRELVdSVDEaMBgGA1UEAxMRTmV3TWVkaWEt
TkVUIEdtYkgxHjAcBgkqhkiG9w0BCQEWD2luZm9AZGQtd3J0LmNvbTCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMUU9GNFU4pN7Yif8osjEGQQiJMh5T9g
wFzswoeztwxbJSETf/idydF4J0ZMTFRJfE/KARnsgawv/Rp/NR6TTOLXtMXxkM+W
S6EluooEgyIkI+2VE7TfgC8WAs5BzVJEiJxv2w0YKkJfmws2UctL1BtNKtJjRiby
qaBR/GlzuYrVKOgsaHCmq20SoUf9GWi8oIu7a3Qi/ZkKuRZRA0b9urGwHMdXyXHZ
2L0NQhBYZAYRyXeOyaVuKrv4kPlrnGyaW8x7TRZtNNLsw0QpUoD/IzSAxCuciIlm
8GstzjSX6OH98Xhv5cTIHQF86JIjcGYMpKFuEzFKS4LVG9gqKmVsu3ECAwEAATAN
BgkqhkiG9w0BAQUFAAOCAQEAmnzZvPhGBxWTadWqRuZZy2bBdkg9/nNZGyGqSbPS
p8Ol2ceKCtYFHA8t08cDFjb90HPswbEvkV/jRlZoTwnyxPmWnJg0oJ+oaNVCx+g0
Ngk9f76pXRBurEi0A9ANchacyG3F8W3I5jxttahH5qCxkYvy7mf2DLugAcS/N4kn
fIDTMhoqj0iaA+LCIOmySP5dhm8GkD7Ms3ji1xYoltopK2ONnZm84226EZEa+UKs
1ZNPK/o8h6SWNjDSQFk1xjveVroIimgtpqFFCPmDd2Ye6toG7ZEwRwWv2wi0N4QJ
iUbmS2bthPJlx+WC5YZNKEUTONLyP/MfhFXKwulkUyvL2g==
-----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 478 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: 04000000EBDDC6A29A0CB93C27DCA970EF08B1F1D99664D758BAF3CFBA70BC95
    Session-ID-ctx: 
    Master-Key: 4AE6837D7F3A482022525A5C43AA77E04F3A21C1F401ED944C481135BD921BCC9D83FA8FA2EE217A6E1A513C617AA81E
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1414522797
    Timeout   : 300 (sec)
    Verify return code: 18 (self signed certificate)
---
DONE


Hope this helps
PS: After I reached to upgrade 2 out of all my routers to a recent firmware, I could also have a try with FF33 on a linux machine:
With new cert/firmware FF33 can connect.
Although, FF34+Aurora35 in Windows fail to connect to these new certs and only issue a generic error message with no code.
(In reply to f0rhum from comment #20)
> PS: After I reached to upgrade 2 out of all my routers to a recent firmware,
> I could also have a try with FF33 on a linux machine:
> With new cert/firmware FF33 can connect.
> Although, FF34+Aurora35 in Windows fail to connect to these new certs and
> only issue a generic error message with no code.

Based on Comment 19 and 20, this might be related to Bug 1076983 disabling SSL3 to mitigate POODLE.

f0rhum: Let's move this to Bug 1089179 since it's a separate issue.
Well OK, so it can be set as a duplicate of Bug 1089179 ? Should I set it myself?
Thank you for support Cykesiopka
(In reply to f0rhum from comment #22)
> Well OK, so it can be set as a duplicate of Bug 1089179 ? Should I set it
> myself?
> Thank you for support Cykesiopka

No problem.

I don't think this bug is a duplicate of Bug 1089179 (or Bug 1090765).
Depends on: 1091778
Developers, this isn't the first time Firefox has locked us out of systems with a certificate that did not meet new security guidelines. I totally understand that this is a good security measure for end users but Mozilla needs to make certain that developers, engineers, IT support, etc. have an easy way to override this. Just as Ben says above I have some older systems that are only accessible internally with self-signed certificates on them that we can no not access.

There should be an easy way for us to put exceptions in for this. There is no need for us to regenerate the certificates as these systems are not high security but are used regularly. I guess I have to install Chrome, which I've been trying to avoid.
(In reply to Slim Shady from comment #12)
> The HIGHLY INTELLIGENT developers at Mozilla et. al. SHOULD refrain for
> arbitrarily imposing such restrictions on it's users.  Instead Mozilla et.
> al. SHOULD notify users SEVERAL VERSION in advance - at least 2 - when
> security that they're using is going to become invalid.
> 
> That way anyone using "embedded" where performance is an issue SHOULD be
> able to address their security issues IN A TIMELY MANNER rather than on a
> Monday after everyone upgraded their Firefox browser.
> 
> IE When I log into my Linksys with DD-WRT for version of Firefox 31 and 32,
> I SHOULD have been notified that my RSA KEY LENGTH was too small and would
> be unsupported in future version, and possible offered some Ron Jeremy pills
> to compensate for my inadequate length.
> 
> Decisions like this are why I get questions from management such as: "Why
> aren't we using Chrome if it works?"
> 
> While I understand the technical reason for imposing these limits - at least
> I like to think I do - I do not agree in the manner in which Mozilla
> informed me of such limits.
> 
> Some security is better than none.  This router, and my home router -
> Linksys WRT-54G r2, which is running Open-WRT - have https only access.  At
> some point the limits will be raised that force me to either A) Buy a new
> router because the SoC in my current router isn't fast enough for the
> imposed limits or B) Download a new browser because it supports my poor
> security choices.
> 
> The appropriate method to solve this is to notify the users of the
> deprecation of their security configuration at least version in advance -
> probably 2 with Firefox's update schedule.  Increase the DEFAULT limits in
> the next version or two.  Allow the choices to be overridden by the user.
> 
> NIST has increased the limits from 256 to 2048 in the span of 5 years. 
> Chances are, these limits will be raised again.  Stop breaking networks with
> use your product.  Inform the user, change the default, allow the limits to
> be manually lowered.

Please be mindful of the Bugzilla Etiquette this is not a forum but a place for tracking bugs and while we understand your frustration there is no need to ridicule https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

We are looking into this.
Benjamin Kerensa:  I figured this bug was a double header, including issues relating to: "Devs not using usage statistics when implementing potentially damaging changes".  Could you please report a bug to that effect if this is not the place to make such observations pertaining to this bug.

I'm sure there were many usage statistics sent to Mozilla that could have been narrowed down to keys of a certain size, which would then be blocked by this change.  Sure it would have seemed to be a trivial number of servers.  Oddly enough, though, I would expect to see that of this trivial ratio of request, they are all of the same nature.  Private network gateways.

I'm certain there must have been enough information to tell the devs, or the reviewers, that the biggest impact of this change was to people who were accessing network infrastructure - which generally isn't updated unless it needs to be.  This infrastructure might be low powered devices not capable of performing optimally with larger keys, or infrastructure which is secured better than default no-key settings.

The exact reasoning into implementing such a change is the exact same reasoning that is used why NOT to make such a change.  So obviously there was some thought process regarding computer power vs key length.  Just single minded focused attention and lack of vision to details.  A simple question could have easily been asked and answered: "How many people will this affect, and how?"  Oh look, everyone's SoC router is going to be inaccessible via https, and completely inaccessible if http is disabled.  Every aspect of this issue is ridiculous.  Have you ever seen a router which did not allow the disabling of http and enabling of https which has been released in the past 10 years.  What study was done to say the hardware being affected by this should easily handle the change of a key 4 times longer.

I'm providing a solution to avoid these types of bugs.  I am appalled at the oversight and the detrimental effect.  I find making people feel stupid for doing stupid things helps teach them to think twice: IE Is this stupid?

Should I just turn off usage statistics and stop using nightly because it's pointless and disregarded anyway?  Is that what you're telling me?  No, Ben, that would be ridiculous and I would expect to be ridiculed for not helping the community.  Ridicule IS required when people do ridiculous things.  This is Bananas.  B-A-N-A-N-A-S.
After talking with :keeler, it looks like Bug 1091778 won't be uplifted. So in the mean time, we'll just make this error overridable. I'll try and get the change uplifted to Firefox 34 and 35 if I can as well.
Assignee: nobody → cykesiopka.bmo
Status: NEW → ASSIGNED
No longer depends on: 1091778
Just asking for feedback for now - In particular, I'm not sure if it's necessary to test chains with inadequately sized intermediates and roots as well.

https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=376a3d5b7d89
Attachment #8520471 - Flags: feedback?(dkeeler)
Comment on attachment 8520471 [details] [diff] [review]
bug1084606_v0.patch

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

Looks great, but I think you're going to have to modify nsUsageArrayHelper as well: http://hg.mozilla.org/mozilla-central/annotate/a926116946f8/security/manager/ssl/src/nsUsageArrayHelper.cpp#l145
Also, for any branch where bug 1057497 hasn't landed, you'll have to modify dom/browser-element/BrowserElementChildPreload.js similarly.
I think we don't actually need to test intermediates/roots because we already have xpcshell tests that ensure the correct error is returned in those cases, right? This is basically just an integration test that ensures that if that error is encountered, it'll be overridable.
Attachment #8520471 - Flags: feedback?(dkeeler) → feedback+
(In reply to David Keeler (:keeler) [use needinfo?] from comment #32)
> but I think you're going to have to modify nsUsageArrayHelper
> as well:
> http://hg.mozilla.org/mozilla-central/annotate/a926116946f8/security/manager/
> ssl/src/nsUsageArrayHelper.cpp#l145

The MOZILLA_PKIX_ERROR_INADEQUATE_KEY_SIZE case is already handled there (unless you meant I should change what should be returned for this case?)

> I think we don't actually need to test intermediates/roots because we
> already have xpcshell tests that ensure the correct error is returned in
> those cases, right? This is basically just an integration test that ensures
> that if that error is encountered, it'll be overridable.

Yes, we have xpcshell tests to ensure this. Thanks for the confirmation!
Attachment #8520471 - Flags: review?(dkeeler)
(In reply to Cykesiopka from comment #33)
> (In reply to David Keeler (:keeler) [use needinfo?] from comment #32)
> > but I think you're going to have to modify nsUsageArrayHelper
> > as well:
> > http://hg.mozilla.org/mozilla-central/annotate/a926116946f8/security/manager/
> > ssl/src/nsUsageArrayHelper.cpp#l145
> 
> The MOZILLA_PKIX_ERROR_INADEQUATE_KEY_SIZE case is already handled there

Right - I don't know what I was talking about, there.
https://hg.mozilla.org/mozilla-central/rev/483034cc549a
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
Approval Request Comment
[Feature/regressing bug #]: Bug 360126, which added key size checking, but didn't allow overrides
[User impact if declined]: Users with old/broken equipment that can't or won't be updated will continue to be unable to access them until Firefox 36
[Describe test coverage new/current, TBPL]: New test case to existing xpcshell test
[Risks and why]: Low - typical patch to allow an override
[String/UUID change made/needed]: None

(I'm aware this is very late for beta, but I did say I would at least try).

Aurora 35:
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=c454b841a289

Beta 34:
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=00d0819f269b
(I assume win64 doesn't work in 34 at all)
Attachment #8524104 - Flags: review+
Attachment #8524104 - Flags: approval-mozilla-beta?
Attachment #8524104 - Flags: approval-mozilla-aurora?
Comment on attachment 8524104 [details] [diff] [review]
bug1084606_aurora35_beta34_v1.patch

It's late but we've caused pain with this type of sec issue that requires an override recently and this patch looks simple enough that it's worth the risk. Let's take this in beta10. Beta+ Aurora+
Attachment #8524104 - Flags: approval-mozilla-beta?
Attachment #8524104 - Flags: approval-mozilla-beta+
Attachment #8524104 - Flags: approval-mozilla-aurora?
Attachment #8524104 - Flags: approval-mozilla-aurora+
f0rhum@free.fr, can you confirm this fixes your issues with the latest 34 Beta 10 build from ftp://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/34.0b10-candidates/build1/? Note that the Windows build should be available ~1-2 hours from now.
Flags: needinfo?(f0rhum)
Thanks!  That fixed my issues.
Florin, I have a mitigated answer (FF34b10):
With old routers/firmware like this one:
openssl s_client -connect spiq: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-----
MIICJDCCAc4CCQCvlxpYBqKdzDANBgkqhkiG9w0BAQUFADCBmDELMAkGA1UEBhMC
REUxDjAMBgNVBAgTBVNheG9uMRAwDgYDVQQHEwdEcmVzZGVuMRowGAYDVQQKExFO
ZXdNZWRpYS1ORVQgR21iSDEPMA0GA1UECxMGREQtV1JUMRowGAYDVQQDExFOZXdN
ZWRpYS1ORVQgR21iSDEeMBwGCSqGSIb3DQEJARYPaW5mb0BkZC13cnQuY29tMB4X
DTA5MDcyMDIzNTg1NloXDTE5MDcxODIzNTg1NlowgZgxCzAJBgNVBAYTAkRFMQ4w
DAYDVQQIEwVTYXhvbjEQMA4GA1UEBxMHRHJlc2RlbjEaMBgGA1UEChMRTmV3TWVk
aWEtTkVUIEdtYkgxDzANBgNVBAsTBkRELVdSVDEaMBgGA1UEAxMRTmV3TWVkaWEt
TkVUIEdtYkgxHjAcBgkqhkiG9w0BCQEWD2luZm9AZGQtd3J0LmNvbTBcMA0GCSqG
SIb3DQEBAQUAA0sAMEgCQQC5S+wsJXpd3JomYK2N9sfX5p4IvFBJ+8KWd/EAEf0m
Mxlb/AshJpoP+taZvbRWGTEwDBtH06EEq8XnG8nJggihAgMBAAEwDQYJKoZIhvcN
AQEFBQADQQCj7weXosMmgwI60YC8NYSeLyzUrhXbxJ9d04t1fqIDQRn2H9Ru9oid
zFDSPnx/HeyxY2PvBBCtmmvY6a6PUQ+H
-----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 453 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: 04000000A7E8E7FC791055C851D2025C879A0E869E81524A7D274C8038F17A7A
    Session-ID-ctx: 
    Master-Key: 69F5EE5ED9466F253613AD216EB55C1D6969ECA2DDFCD077118D83FFB6CFC2D11CE3D5B0741DAA936617BACEAC9719AF
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1416567287
    Timeout   : 300 (sec)
    Verify return code: 18 (self signed certificate)
---
DONE
I get the message: ssl_error_no_cypher_overlap
Only with SSL Control Version plugin set to SSLv3 I can now connect fine (both with the previously stored exception and once deleted I can create a new one after a while). Cool job, even if I'd rather like I don't need a plugin.


With a more recent router/firmware, no way to connect :
openssl s_client -connect spiq:8098 -showcerts < /dev/null
CONNECTED(00000003)
139842649704096:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 305 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
openssl s_client -connect spiq:8098 -showcerts -no_tls1 < /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 286 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: 01000000D8D59C43F2230B8F52A38E838950164A13D0043E76BCC5380226B7B4
    Session-ID-ctx: 
    Master-Key: A0E645690ED8B485F628089BF6E3D2854715BA5ACD9A64AB7481418E2459C0FA331E9E3AC3EC2AB59626792757A73543
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1416568308
    Timeout   : 300 (sec)
    Verify return code: 18 (self signed certificate)
---
DONE
Flags: needinfo?(f0rhum)
Note that there are MANY devices out there that cannot update their certificates and are stuck in the past.  Notably, I'm now locked out of all my Dell PowerEdge C6100 IPMI consoles until I configure a Windows VM, since they don't play nice with Chrome for different reasons.
So, there are plenty of valid use cases for allowing the user to override this 
I'm using firefox 34.0~b7+build1-0ubuntu0.12.04.1.
(And if you discover a way to change the SSL cert on the BMC of a Dell PowerEdge C-series IPMI controller, please let me know.)
(In reply to athompso from comment #44)
> Note that there are MANY devices out there that cannot update their
> certificates and are stuck in the past.  Notably, I'm now locked out of all
> my Dell PowerEdge C6100 IPMI consoles until I configure a Windows VM, since
> they don't play nice with Chrome for different reasons.
> So, there are plenty of valid use cases for allowing the user to override
> this 
> I'm using firefox 34.0~b7+build1-0ubuntu0.12.04.1.
> (And if you discover a way to change the SSL cert on the BMC of a Dell
> PowerEdge C-series IPMI controller, please let me know.)

The override has already been added for Firefox 34 and above. Note that it landed in Beta *10*, so you'll need to update to be able to add an override.
Oops.  Confirming that yes, beta 11 does let me back in.
You need to log in before you can comment on or make changes to this bug.