Re: Proposal: Disable SSLv3 in Firefox ESR 31
On Tue, 2014-10-21 at 01:40 +0200, Kai Engert wrote: On Thu, 2014-10-16 at 20:51 +0200, Kai Engert wrote: Do you claim that Firefox 34 will continue to fall back to SSL 3 when necessary? Yes. If I understand correctly, it seems that Firefox indeed still falls back to SSL3, even with SSL3 disabled. I'm sorry if I got this wrong, inspired by Florian's claim (still falling back) and my quick reading of the code. Let's get this clarified. My reading of the source indicated that adjustForTLSIntolerance would fall back until it reaches SSL3. However, trying to connect to a SSL3-only server like https://bod.bodmillenium.com using Firefox 33 and 36 fails (with min.tls set to 1). So hopefully I was wrong. 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
- Original Message - From: Julien Pierre julien.pie...@oracle.com To: mozilla's crypto code discussion list dev-tech-crypto@lists.mozilla.org Sent: Tuesday, 21 October, 2014 1:59:44 AM Subject: Re: Proposal: Disable SSLv3 in Firefox ESR 31 Kai, On 10/20/2014 16:47, Kai Engert wrote: On Mon, 2014-10-20 at 16:45 -0700, Julien Pierre wrote: What is the purpose of Firefox continuing to do any fallback at all ? IMO, making a second connection with any lower version of SSL/TLS defeats the intent of the SSL/TLS protocol, which have built-in defenses against protocol version downgrade. Isn't it time this fallback gets eliminated at last ? I'm stating what I found, I'm not making that decision. Sorry, I didn't mean to blame you for that decision - but IMO this should be pointed out to whoever made that call. The whole TLS_FALLBACK_SCSV would be unnecessary if not for this browser misbehavior - and I hope the IETF will reject it. Yes, it's external to the TLS, and yes, it's bad that browsers do use the manual fallback. Yes, the servers should be regularly updated and as such bugs that cause it fixed. Yes, the configurations should be updated to align them with current recommendations. But it doesn't happen in real world. So either we can push for policies which will never be implemented and be workable in real world, or we can try to make the systems secure in real world for people that care (both users and server admins that do apply updates regularly). Yes, I'd like to live in a world where it's not necessary, but we don't. -- Regards, Hubert Kario -- 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
* Julien Pierre: The whole TLS_FALLBACK_SCSV would be unnecessary if not for this browser misbehavior - and I hope the IETF will reject it. Technically, we still need the codepoint assignments from the IETF draft because of their widespread use, and that requires Standards Action, which means publication of a standards-track RFC. Although the RFC could simply say, do not use these codepoints. (I think TLS_FALLBACK_SCSV is a mistake, too.) -- 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
So, let's get this clarified with test results.
I've tested Firefox 34 beta 1.
Because bug 1076983 hasn't landed on the beta branch yet, the current
Firefox 34 beta 1 still has SSL3 enabled.
With this current default configuration (SSL3 enabled), Firefox will
fall back to SSL3.
Then I used about:config and changed security.tls.version.min to 1
(which means TLSv1, thereby disabling SSL3).
With SSL3 disabled, Firefox 34 no longer falls back to SSL3.
When attempting to connect to a SSL3-only server, I see Firefox 34
attempting three connections, with TLS 1.2 {3,3}, TLS 1.1 {3,2} and TLS
1.0 {3,1}, but not SSL3.
In other words, with SSL3 disabled, Firefox 34 doesn't attempt a
fallback to use SSL3.
With these new results, it's no longer clear to me what Florian was
referring to.
On Thu, 2014-10-16 at 20:27 +0200, Florian Weimer wrote:
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?
Florian, did you assume that Firefox would still fall back to SSl3?
That's not happening.
With SSL3 disabled, the intention, as I understand it, is to disable
SSL3 completely, not even using it when falling back.
On the other hand, Firefox will continue to fall back to non-disabled
versions of TLS (such as TLS 1.1 and TLS 1.0).
Is this what you're worried about?
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
* Kai Engert:
When attempting to connect to a SSL3-only server,
Which is now treated as version-intolerant, it seems.
I see Firefox 34 attempting three connections, with TLS 1.2 {3,3},
TLS 1.1 {3,2} and TLS 1.0 {3,1}, but not SSL3.
This still shows the fallback attempts, to TLS 1.0 even, which isn't
exactly stellar from a CBC padding perspective, either.
With these new results, it's no longer clear to me what Florian was
referring to.
I still think the fallback behavior you have shown is a browser bug,
and should be fixed there, but its removal. There seems to be rather
vehement disagreement, but I don't get way.
People who desparately need to connect to old devices can keep old
browser versions around, or you could offer a per-site configuration
knob (chances are you need that for SSL 3.0 support anyway). These
old devices frequently demand old browser or Java versions, so yet
another reason to keep an old browser around does not seem
particularly cumbersome to me.
The benefit from that would be that regular users are protected even
if servers do not implement TLS_FALLBACK_SCSV.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Updates to the Server Side TLS guide
--On October 20, 2014 16:43:01 -0700 Julien Pierre julien.pie...@oracle.com wrote: Hubert, On 10/20/2014 05:10, Hubert Kario wrote: So I went over the https://wiki.mozilla.org/Security/Server_Side_TLS article with a bit more attention to detail and I think we should extend it in few places. Especially if it is supposed to be also the general recommendation for servers, not just for ones that are part of Mozilla network. This document seems to be fairly OpenSSL-centric. Some servers actually use Mozilla's NSS library., as well as other libraries. At this point, the OpenSSL-style cipher suite adjustment string has become a de-facto standard. So I believe NSS should be modified to follow that de-facto standard rather than expecting those writing security advice to do extra work: https://bugzilla.mozilla.org/show_bug.cgi?id=967235 It's not a sexy change to NSS, but it would be very useful. Enterprise administrators of Firefox would probably appreciate this as well as server admins for servers using NSS. - Chris -- 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
Hubert, On 10/21/2014 05:06, Hubert Kario wrote: Yes, it's external to the TLS, and yes, it's bad that browsers do use the manual fallback. Yes, the servers should be regularly updated and as such bugs that cause it fixed. Yes, the configurations should be updated to align them with current recommendations. But it doesn't happen in real world. So either we can push for policies which will never be implemented and be workable in real world, or we can try to make the systems secure in real world for people that care (both users and server admins that do apply updates regularly). Yes, I'd like to live in a world where it's not necessary, but we don't. IMO, reasonable decisions can be made to drop support for TLS intolerant servers. Those who have legacy devices that can't be updated could still use legacy browsers to connect to them, or there could be an explicit legacy mode of operation in current browsers that preserves it. This way, browsers won't subject the requests to 99.999% of servers that are not TLS-intolerant to needless MITM attacks, not to mention extra network bandwidth and round trips. Julien -- 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/21/2014 06:38, Florian Weimer wrote: I still think the fallback behavior you have shown is a browser bug, and should be fixed there, but its removal. There seems to be rather vehement disagreement, but I don't get way. +1 , any fallback is a bug. SSL has built-in protocol version negotiation. People who desparately need to connect to old devices can keep old browser versions around, or you could offer a per-site configuration knob (chances are you need that for SSL 3.0 support anyway). These old devices frequently demand old browser or Java versions, so yet another reason to keep an old browser around does not seem particularly cumbersome to me. We think alike The benefit from that would be that regular users are protected even if servers do not implement TLS_FALLBACK_SCSV. Indeed. Servers that care about the SSL3 issue aren't going to upgrade software to pick up TLS_FALLBACK_SCSV . They will just disable SSL3 in the configuration, which is much simpler and much quicker to do . Some servers may do both, but it won't be the majority. TLS_FALLBACK_SCSV serves no purpose except to perpetuate the illusion that the browser fallback makes some sort of sense. Julien -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Updates to the Server Side TLS guide
Chris, On 10/21/2014 11:43, Chris Newman wrote: At this point, the OpenSSL-style cipher suite adjustment string has become a de-facto standard. So I believe NSS should be modified to follow that de-facto standard rather than expecting those writing security advice to do extra work: https://bugzilla.mozilla.org/show_bug.cgi?id=967235 It's not a sexy change to NSS, but it would be very useful. Enterprise administrators of Firefox would probably appreciate this as well as server admins for servers using NSS. - Chris I wasn't even specifically referring to cipher strings, but the whole document seems to be about servers running OpenSSL, though I did see a few references to GnuTLS as well. There are also servers running NSS, Microsoft SSL stacks, proprietary SSL stacks, etc. Julien -- 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
Kai,
On 10/21/2014 05:31, Kai Engert wrote:
So, let's get this clarified with test results.
I've tested Firefox 34 beta 1.
Because bug 1076983 hasn't landed on the beta branch yet, the current
Firefox 34 beta 1 still has SSL3 enabled.
With this current default configuration (SSL3 enabled), Firefox will
fall back to SSL3.
Then I used about:config and changed security.tls.version.min to 1
(which means TLSv1, thereby disabling SSL3).
With SSL3 disabled, Firefox 34 no longer falls back to SSL3.
When attempting to connect to a SSL3-only server, I see Firefox 34
attempting three connections, with TLS 1.2 {3,3}, TLS 1.1 {3,2} and TLS
1.0 {3,1}, but not SSL3.
That's a lot of fallbacks.
Do we know of TLS 1.0 servers that reject connections with TLS 1.2 or
1.1 in ClientHello instead of falling back to 1.0 ?
Or TLS 1.1 servers that reject connections with 1.2 in ClientHello
instead of falling back to 1.1 ?
Just how many broken servers are there out there ?
Julien
--
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/21/2014 05:24, Florian Weimer wrote: * Julien Pierre: The whole TLS_FALLBACK_SCSV would be unnecessary if not for this browser misbehavior - and I hope the IETF will reject it. Technically, we still need the codepoint assignments from the IETF draft because of their widespread use, and that requires Standards Action, which means publication of a standards-track RFC. Although the RFC could simply say, do not use these codepoints. Sorry I misspoke - I'm not that familiar with the intricacies of the IETF RFC process. Julien -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Updates to the Server Side TLS guide
On 2014-10-21 19:20, Julien Pierre wrote: I wasn't even specifically referring to cipher strings, but the whole document seems to be about servers running OpenSSL, though I did see a few references to GnuTLS as well. There are also servers running NSS, Microsoft SSL stacks, proprietary SSL stacks, etc. Out of the 8 configuration examples listed in [1], 4 are openssl specific, 3 are proprietary, one is an entire tls stack entirely. Specifying a ciphersuite with a deterministic ordering is impossible to do in GnuTLS. NSS is very rarely used in servers. OpenSSL dominates that ecosystem, so it is natural that the document would use its syntax. - Julien [1] https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Server_Configurations -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
