On 09/01/2010 07:52 PM, Robert Relyea wrote:
On 08/27/2010 03:46 PM, Wan-Teh Chang wrote:
I propose that we remove SSL 2.0 support from the NSS
trunk (NSS 3.13).
SSL 2.0 is an old and insecure protocol. No products
should be using SSL 2.0 today.
That should be sufficient reason to remove it. It's not only that it's a
drag to maintain going forward. Its continued presence per se is a net
negative.
But removing the SSL
2.0 code from NSS has one major benefit to the continual
development of NSS's SSL library: it'll make the code
base easier to maintain.
As much as I'd like to get rid of SSL 2.0. I'm a little leary of
removing it.
The arbiter of all objective truth (Wikipedia) speaks thusly:
> The SSL protocol was originally developed by Netscape. Version 1.0
> was never publicly released; version 2.0 was released in February
> 1995 but "contained a number of security flaws which ultimately led
> to the design of SSL version 3.0". (Rescorla 2001) SSL version 3.0
> was released in 1996.
This SSLv2 we're talking about was the recommended released version for
just a year before it was replaced by its own creator for cause. That
was 15 years ago.
Compared with the "mainstream" SSL 3.0/TLS 1.0 code
in NSS, the SSL 2.0 code was written in a different style
and worse, uses some data structures in a different way.
This confuses people like me who are still learning our
way around the code base but need to add new features.
In addition, when we fix a bug, we always wonder if we
should also fix the bug in the SSL 2.0 code path.
Wan-Teh is being very diplomatic here and saying it nicely.
But listen to what he is saying!
I'll put it more directly. My interpretation:
"The SSLv2 codebase has bitrotted to the point that we can no longer
maintain it to an acceptable level of quality. It will not be receiving
any new features yet changes to shared code may introduce future
breakage. It is likely that it has unfixed bugs, probably some of which
were publicly disclosed long ago. Using this code is a bad idea. We
recommend against its continued use but if you still choose to use it
anyway we cannot guarantee your security."
As we add TLS 1.1 and TLS 1.2 code, it also makes
sense to remove the SSL 2.0 code to reduce the code
size.
If no one objects, I will be happy to do the work.
consider this a token objection.
...
> Particularly if it is a requirement for servers. I don't
> have the option of staying on old versions of NSS for servers and new
> ones for clients.
Is the basis of your objection then really the library versioning and
code branching policies of your organization? I know you guys go the
extra mile for long term maintenance. But is it really fair to ask the
maintainers, users, and everyone to continue to bear the overhead of
increased complexity and attack surface costs from it?
Surely an end customer who is stuck on such a deprecated, insecure, and
truly ancient protocol will be grateful for whatever they get. They will
not complain that they merely end up on a library fork with a
nonincreasing major version number.
- Marsh
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
