On Sat, March 7, 2015 12:20 pm, kim.da...@safe-mail.net wrote: > Looking for comments about feasibility of breaking-up Firefox > TLS/SSL-handling code into easily-removable sections. > > I want to fully separate NSS code from code that handles: > > 1) MD5 signature handling > > 2) SHA1 signature handling > > 3) RSA key exchange > > 4) CBC mode > > 5) RC4 ciphers > > 6) SSLv3 > > 7) TLSv1.0, TLSv1.1 > > 8) SEED, IDEA, 3DES, Camellia cyphers > > 9) Secondary/Fallback handshake > > 10) Insecure TLS version feedback > > and likely others. > > The intention is to phase out and eventually remove support for all of the > above. > > Disabling those technologies in browser options is insufficient. > FREAK-like attacks will exploit holes in the disabling mechanism to > reenable them. Alternatively, malware, misguided forks, or clueless users > will change those settings for the worse. > > Removing code from the source code is the only secure way. This also helps > code maintainability, review, and certifiability. > > To facilitate easier code removal, the code needs to be properly separated > first - and that is the goal of this project.
Hi Kim, Unfortunately, I believe you start from a flawed premise, and thus the rest sort of falls apart. That is, while removing the code may help long term, separating the code out does not help maintainability or readability - and in fact, can greatly hinder them. Plenty of implementations that have striven to fully separate out their TLS 1.0, TLS 1.1, and TLS 1.2 stacks have thus fallen victim to bugs. For example, I can think of one prominent implementor that failed to fix BEAST because they only fixed one of their implementations, and left the others vulnerable. TLS version fallback, for example, is not implemented in NSS. MD5/SHA1 signature handling is already separated, but you still need it in some contexts, but not others. Even more so CBC - whose use in NSS extends far beyond SSL and has many independent applications that would need independent timelines for deprecation. In short, I think the plan of separating out that code to be well-intentioned, but misguided. It's also something that, as a mature software project with many consumers, will require care and caution rather than wholesale deleting. And since I've been accused in the past (amusingly so) of trying to keep backdoors in, no, this is about the tension of a responsible and open software development practice and balancing the needs for security. I also don't think there's the same urgency to delete the code. The argument you give - that malware will enable it - is unfortunately an unsolvable problem. I refer you to https://technet.microsoft.com/en-us/library/hh278941.aspx to understand why this is inherently so. The other arguments are equally problematic. Misguided forks (there have been none yet) and clueless users (whom, if we accept as a threat model, can do anything and everything hostile to security, including running malware) are similarly specious. Rather than focus on removing the code, perhaps it's better to think about how best to phase things out - with attention being paid to the attendant issues. For example, NSS is enabling TLS 1.2 by default ( https://bugzilla.mozilla.org/show_bug.cgi?id=1083900 ) and disabling SSL 3 by default ( https://bugzilla.mozilla.org/show_bug.cgi?id=1140029 ), but both of these are huge steps with *real* interop issues for applications using NSS. We can't just ignore those and say "Too bad, so sad" - including for the most obvious reason, in that applications would just switch to TLS libraries that understood and appreciated interop concerns. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
