On Mon, Oct 7, 2013 at 3:20 PM, Robert Relyea <rrel...@redhat.com> wrote: > On 10/07/2013 12:44 PM, Wan-Teh Chang wrote: >> On Mon, Oct 7, 2013 at 11:17 AM, Brian Smith <br...@briansmith.org> wrote: >>> 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. >> The burden of maintaining the branch should fall on the people who >> still need SSL 2.0, so we should remove SSL 2.0 from the trunk. It is >> not that hard for a competent NSS developer to support an NSS 3.15 >> branch for another three years. > Please don't completely screw us over here. I would prefer to be able to > track NSS updates, particularly since they are pulled in by mozilla. (we > completely rebase nss whenever we have to pick up new mozilla releases > that need it).
I think if some Linux distributors would continue to use the code that contains SSL 2.0 support, then it would be better for Firefox to link libssl statically to avoid using that variant of libssl. > That being said, I think we could split the ssl 2.0 code out stand > along. The only issue is ssl2 hello->ssl3, which would probably mean > figuring out some why to make that transition that puts the burden on > the ssl2 code. > Ideally so ideally we could completely fork the SSL2 code to use it's > own gather buffers. This is much easier said than done, because many bits of data are shared between the implementation of SSL 2.0 and the later versions. The point of removing SSL 2.0 would be to make the code simpler so that we can be confident that it is correct, and to make it easier to improve. Refactoring the SSL 2.0 code in the manner you suggest is counterproductive to both of those aims, and recent experience gives clear evidence of that. > Right now I'm trying to see if I can get management to let us drop SSL2 > support in some upcoming RHEL 6 release. I've already dropped it in > RHEL7, and I think we may be at the point in RHEL-5 where we may not be > updating NSS except for some extreme fixes. That is a Red Hat problem, not a Mozilla problem. The Mozilla project is bigger than just Firefox and Gecko-based products, but I don't think the Mozilla project's interests extend so far as to be concerned about Red Hat backward compatibility guarantee to its customers. We are willing to help Red Hat when it is reasonable, but I think this issue has reached the point there it is now unreasonable to carry on as before. > One thing that could help is > to make sure the next mozilla CSB release supports SSL2 that will give > RHEL 6 some more runway... For a long time, Gecko-based products hard-code SSL 2.0 to be disabled and there is no option for enabling SSL 2.0 support in Gecko products. I would not accept the addition of such an option either. If there is some server that is SSL 2.0 only then I will be glad to have Firefox stop working with that server, so that the server admin feels pressure to improve the security of the server. Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
