On Fri, Oct 4, 2013 at 6:52 PM, Ludovic Hirlimann <ludovic+n...@mozilla.com> wrote: > Hi, > > AFAIK NSS still contains code for SSL2 , but no product uses it. SSL2 > has been turned off at least 2 years ago. By removing SSL2 code we get : > > Smaller librarie > faster compile time + test time > > What do you guys think ?
Hi Ludovic, I do think it is time to remove SSL 2.0 support from libssl. The size of libssl won't be much different and it won't compile much faster. However, removing SSL 2.0 code from libssl will enable us to make the code much easier to understand in ways that I am 100% sure will positively impact the security of our SSL3/TLS code. So, I propose that libssl remove SSL 2.0 support in NSS 3.16. I will be happy to write the patch for it; I actually have it partially done already. I can think of at least one serious bug in libssl that likely would have been avoided if not for the additional complexity of needing to deal with SSL 2.0. Plus, not having to deal with the SSL 2.0 code will definitely enable us to improve the SSL3/TLS code easier in the future. I can think of multiple times where the need to deal with the SSL 2.0 code has slowed down the implementation of improvements to the newer protocols. This is an unreasonable cost for us to have to incur for a feature that we know nobody should be using. When the NSS team discussed this topic previously, we had agreed that we wouldn't remove the SSL 2.0 code before TLS 1.2 was implemented, so that Red Hat could have a version of NSS with both SSL 2.0 and TLS 1.2 for their long-term release. Now TLS 1.2 is implemented and we should move forward with the removal. I think it is likely that some vendors of NSS-based products with very conservative backward-compatibility guarantees, like Oracle and maybe Red Hat, may need to continue supporting SSL 2.0 in their products due to promises that they've made. If so, either we should create a branch for these organizations to maintain, or we should create a branch of libssl without SSL 2.0. I am OK with doing things either way, though I prefer to have the NSS trunk be the SSL-2.0-less branch that Mozilla contributes to. Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
