Proposal: Disable SSLv3 in Firefox ESR 31
Hey all, By now, you've probably heard about the POODLE attacks on SSLv3, and our decision to disable SSLv3 by default in Firefox 34 [1]. Several people have proposed that we also make this change in Firefox ESR 31. So I wanted to propose that we also disable SSLv3 by default in ESR 31 at about the same time as we do it in 34, that is, around November 25. If there are any objections or comments on that proposal, please raise them in this thread. Thanks, --Richard [1] https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/ -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal: Disable SSLv3 in Firefox ESR 31
On Thu, 2014-10-16 at 10:31 -0700, Richard Barnes wrote: By now, you've probably heard about the POODLE attacks on SSLv3, and our decision to disable SSLv3 by default in Firefox 34 [1]. Several people have proposed that we also make this change in Firefox ESR 31. So I wanted to propose that we also disable SSLv3 by default in ESR 31 at about the same time as we do it in 34, that is, around November 25. If there are any objections or comments on that proposal, please raise them in this thread. FYI, it's actually more than a proposal. It has been clarified in the bug, disabling it in Firefox 31.3 is already planned: https://bugzilla.mozilla.org/show_bug.cgi?id=1076983#c73 So, if you have any objections, please speak up. Thanks Kai -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal: Disable SSLv3 in Firefox ESR 31
* Richard Barnes: If there are any objections or comments on that proposal, please raise them in this thread. A lot of this has already been hashed out on the IETF TLS WG mailing list, with a slightly different perspective. Why is disabling SSL 3.0 acceptable, but getting rid of the broken fallback which will keep endangering users for a long time to come is not? -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal: Disable SSLv3 in Firefox ESR 31
On Thu, 2014-10-16 at 20:27 +0200, Florian Weimer wrote: A lot of this has already been hashed out on the IETF TLS WG mailing list, with a slightly different perspective. Why is disabling SSL 3.0 acceptable, but getting rid of the broken fallback which will keep endangering users for a long time to come is not? Please let's make sure there are no misunderstandings. Do you claim that Firefox 34 will continue to fall back to SSL 3 when necessary? I was hoping that Firefox 34 would completely disable SSL 3, no longer accepting servers requesting to use that version, and no longer initiating any SSL 3 connections, not even when falling back. Did I understand incorrectly? Kai -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal: Disable SSLv3 in Firefox ESR 31
On Thu, 16 Oct 2014 20:27:24 +0200 Florian Weimer f...@deneb.enyo.de wrote: * Richard Barnes: If there are any objections or comments on that proposal, please raise them in this thread. A lot of this has already been hashed out on the IETF TLS WG mailing list, with a slightly different perspective. Why is disabling SSL 3.0 acceptable, but getting rid of the broken fallback which will keep endangering users for a long time to come is not? Are you talking about implementing TLS_FALLBACK_SCSV (bug 1036737) or disabling the insecure TLS version fallback to SSLv3 (bug 689814)? The former is riding the release trains and should be in Firefox 35. The latter is no longer needed now that SSLv3 is disabled (though I guess it could still be implemented for those people who require SSLv3 still be enabled). ~reed -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal: Disable SSLv3 in Firefox ESR 31
* Reed Loden: On Thu, 16 Oct 2014 20:27:24 +0200 Florian Weimer f...@deneb.enyo.de wrote: * Richard Barnes: If there are any objections or comments on that proposal, please raise them in this thread. A lot of this has already been hashed out on the IETF TLS WG mailing list, with a slightly different perspective. Why is disabling SSL 3.0 acceptable, but getting rid of the broken fallback which will keep endangering users for a long time to come is not? Are you talking about implementing TLS_FALLBACK_SCSV (bug 1036737) or disabling the insecure TLS version fallback to SSLv3 (bug 689814)? Neither. I'm talking about the out-of-protocol insecure version negotiation for TLS implemented in Firefox. That's a broader scope than bug 689814, which is strictly about fallback to SSL 3.0. I suspect you think it is necessary based on bogus telemetry. There will be some breakage, but I doubt it will be more than the fallout from disabling SSL 3.0 by default. And the long-term benefits are so much greater. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Announcing Mozilla::PKIX, a New Certificate Verification Library
On Monday, April 7, 2014 6:33:50 PM UTC-4, Kathleen Wilson wrote: All, We have been working on a new certificate verification library for Gecko, and would greatly appreciate it if you will test this new library and review the new code. Background NSS currently has two code paths for doing certificate verification. Classic verification has been used for verification of non-EV certificates, and libPKIX has been used for verification of EV certificates. As many of you are aware, the NSS team has wanted to replace the classic verification with libPKIX for a long time. However, the current libPKIX code was auto-translated from Java to C, and has proven to be very difficult to maintain and use. Therefore, Mozilla has created a new certificate verification library called mozilla::pkix. Request for Testing Replacing the certificate verification library can only be done after gaining sufficient confidence in the new code by having as many people and organizations test it as possible. We ask that all of you help us test this new library as described here: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Request_for_Testing Testing Window: The mozilla::pkix certificate verification library is available for testing now in Nightly Firefox builds. We ask that you test as soon as possible, and that you complete your testing before Firefox 31 exits the Aurora branch in June. (See https://wiki.mozilla.org/RapidRelease/Calendar) Request for Code Review The more people who code review the new code, the better. So we ask all of you C++ programmers out there to review the code and let us know if you see any potential issues. https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Request_for_Code_Review We look forward to your help in testing and reviewing this new certificate verification library. Mozilla Security Engineering Team Mozilla::pkix includes some changes in support of current best practices and policies, as listed below. If you notice an issue due to any of these changes, please feel free to let us know. However, we believe that in most cases, the simplest resolution will be to update the SSL certificate in your webserver. YOU F**KTARDS.. SOMETIMES WE HAVE ABSOLUTELY ZERO F**KING CONTROL OVER THE SSL CERT PRESENTED.. WE **know** IT SHOULD BE TRUSTED BECAUSE ITS AN INTERNAL F**KING DEVICE, AND DON'T GIVE ONE FLYING F**K IF THE CERT IS VALID OR NOT.. WE **SHOULD** BE ALLOWED REGARDLESS OF THE F**KING CAUSE, TO ADD AN EXCEPTION.. TAKE THE SAME F**KING URL TO ANY OTHER BROWSER, AND AT WORST YOU GET CHROME WHICH NOW WON'T REMEMBER USER/PASS COMBOS TO GET INTO THOSE SITES BUT IT STILL F**KING LETS YOU GET TO THE GOD DAMNED F**KING SITE! WHY IS IT THAT YOU SMART A** F**KERS CAN'T UNDERSTAND YOU **CAN NOT FORCE THIS ON PEOPLE** YOU **MUST** ALLOW THEM TO ADD AN EXCEPTION EVEN IF TEMPORARY! OTHERWISE BY NOT ALLOWING US TO DO SO YOU FORCE US TO USE ANOTHER BROWSER.. FOR SOME OF US AS PART OF OUR JOB.. AND WHAT THEN IS THE POINT OF HAVING FIREFOX IF YOU CAN'T USE IT TO DO YOUR F**KING WORK? F**KTARD DEVELOPERS you think you're so smart, you think you know everything and that because YOU think vendors of broken hardware should be forced to fix.. or what.. buy something new? ... F U devs.. you fix this.. or see people abandon you and loose what little cred you had in the browser war! -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal: Disable SSLv3 in Firefox ESR 31
Florian, On 10/16/2014 12:50, Florian Weimer wrote: Neither. I'm talking about the out-of-protocol insecure version negotiation for TLS implemented in Firefox. That's a broader scope than bug 689814, which is strictly about fallback to SSL 3.0. +1 This fallback needs to get removed, yesterday. SSL/TLS have had a secure mechanism for preventing protocol version downgrade attacks from day 1. Firefox circumvents this. It's about time Firefox - and others - to conform to the standard. TLS_FALLBACK_SCSV is a one-time band-aid that won't do any good in the long run. Any server administrator that cares about security will simply disable SSL3 in their server, rather than go through the process of upgrading their software to support this draft. Julien -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
