Proposal to remove SSL 2.0 support from NSS trunk (NSS 3.13)

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal to remove SSL 2.0 support from NSS trunk (NSS 3.13)

Wan-Teh Chang-3
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.  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.

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.

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.

Wan-Teh
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to remove SSL 2.0 support from NSS trunk (NSS 3.13)

Hanno Böck-4
Am Samstag 28 August 2010 schrieb Wan-Teh Chang:
> SSL 2.0 is an old and insecure protocol.  No products
> should be using SSL 2.0 today.  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.

May I make a provocative enhancement proposal? Just remove SSLv3 altogether
with it.

The reason are bugs like this:
https://bugzilla.mozilla.org/show_bug.cgi?id=450280

I think this is unfixable as long as one wants to support SSLv3 (see comment
#15), though when using SNI, this is imho a rather serious issue.

--
Hanno Böck Blog: http://www.hboeck.de/
GPG: 3DBD3B20 Jabber/Mail: [hidden email]

http://schokokeks.org - professional webhosting

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Proposal to remove SSL 2.0 support from NSS trunk (NSS 3.13)

Brian Smith-19
Hanno Böck wrote:
> May I make a provocative enhancement proposal? Just remove SSLv3 altogether
> with it.
>
> The reason are bugs like this:
> https://bugzilla.mozilla.org/show_bug.cgi?id=450280
>
> I think this is unfixable as long as one wants to support SSLv3 (see comment #15),
> though when using SNI, this is imho a rather serious issue.

Let's not mix in that discussion with the SSL 2.0 discussion. Removing SSL 3.0 support is clearly not realistic. Similar issues will arise when TLS 1.1 & 1.2 support is added. I believe there are ways to make TLS version rollback safer in the short term while maintaining a high level of compatibility. For example, a mechanism similar to IE8's compatibility view list could be used to accelerate the rollback for known-bad sites, prevent rollback for slow-but-good sites, and maybe make longer timeouts for unknown websites more bearable.

A long term solution will involve creating better documentation for server administrators and better server software that makes it less likely that less experienced server administrators will configure their servers poorly due to naming confusion (e.g. thinking "SSL 3.0 > TLS 1.0 because 3.0 > 1.0"), compatibility worries, or performance concerns. For example, given [1], many server administrators will either enable SSL2 along with safer versions because that's Apache's default, and many will enable only SSLv3 because it says that is what most browsers support and TLS 1.0 "has been obsoleted."

[1] http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslprotocol

Regards,
Brian

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

RE: Proposal to remove SSL 2.0 support from NSS trunk (NSS 3.13)

Brian Smith-19
In reply to this post by Wan-Teh Chang-3
Wan-Teh Chang wrote:
> I propose that we remove SSL 2.0 support from the NSS trunk (NSS 3.13).

Would this include support for SSLv2->v3 upgrade hellos?

> SSL 2.0 is an old and insecure protocol.  No products should be using SSL
2.0
> today.

Can you share any information you have about how common SSL-2.0-only servers
are?

> 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.

It is easier to remove SSL 2.0 with short notice from client products than
it is from server products. For this and many other reasons, it is worth
considering splitting the codebase into client, server, and shared
components (at least at the source code level). Then this decision could be
done independently for client and server products and Windows desktop
products can avoid shipping large chunks of (effectively) dead
security-critical code.

Regards,
Brian

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to remove SSL 2.0 support from NSS trunk (NSS 3.13)

Wan-Teh Chang-3
On Mon, Aug 30, 2010 at 8:12 AM, Brian Smith <[hidden email]> wrote:
> Wan-Teh Chang wrote:
>> I propose that we remove SSL 2.0 support from the NSS trunk (NSS 3.13).
>
> Would this include support for SSLv2->v3 upgrade hellos?

I forgot to talk about this issue.  We'll need to keep the
server-side code that handles SSLv2-compatible ClientHello.

> Can you share any information you have about how common SSL-2.0-only servers
> are?

I don't have this info, but the products that need to support
SSL 2.0 can stay with NSS 3.12.x.

> It is easier to remove SSL 2.0 with short notice from client products than
> it is from server products. For this and many other reasons, it is worth
> considering splitting the codebase into client, server, and shared
> components (at least at the source code level). Then this decision could be
> done independently for client and server products and Windows desktop
> products can avoid shipping large chunks of (effectively) dead
> security-critical code.

This is a good goal, but it can be a very intrusive change.
I'm going for the most bang for the buck.

I do think ssl3con.c is too big.  At 9503 lines, it takes a
long time to load ssl3con.c in mxr.mozilla.org, and that
hurts developer productivity.  (I use MXR to help me
understand the code.)  So if we're going to break ssl3con.c
into parts, we can follow your suggestion -- client, server,
and shared.

Wan-Teh
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to remove SSL 2.0 support from NSS trunk (NSS 3.13)

Nelson B Bolyard-2
On 2010/08/30 17:32 PDT, Wan-Teh Chang wrote:
> On Mon, Aug 30, 2010 at 8:12 AM, Brian Smith <[hidden email]> wrote:
>> Wan-Teh Chang wrote:
>>> I propose that we remove SSL 2.0 support from the NSS trunk (NSS 3.13).

The entire "gather" logic, by which incoming records are received,
could be simplified enormously, and made much more efficient, once SSL
2.0 support is removed.

The existing "gather" logic seems to have been written by someone who
feared that he might ever read a byte out of a socket that he could not
immediately use, and that he would then need to buffer for some time, as
if that was some sort of onerous burden.  This led to code that does
lots and lots of tiny little reads into a buffer.

I would rewrite it to allocate a buffer large enough to hold a maximum
posisble size SSL3.x record, and then would always attempt to read in
enough data to fill that buffer in a single read.

It's something I wanted to do for YEARS, but for as long as I was
employed to work on NSS, I was told that continued support for SSL2 was
an ongoing business requirement.  I am sad that the opportunity to make
those simplifications did not come along until it was too late for me.
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to remove SSL 2.0 support from NSS trunk (NSS 3.13)

Robert Relyea
In reply to this post by Wan-Teh Chang-3
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.  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. 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.

> 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.
>
> 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.
> Wan-Teh
>  



--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to remove SSL 2.0 support from NSS trunk (NSS 3.13)

Marsh Ray-3
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
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re[8]: Proposal to remove SSL 2.0 support from NSS trunk (NSS 3.13)

Konstantin Andreev-2
In reply to this post by Wan-Teh Chang-3
On 08/31/10 05:01, Nelson B Bolyard wrote:
> On 2010/08/30 17:32 PDT, Wan-Teh Chang wrote:
>> I propose that we remove SSL 2.0 support from the NSS trunk (NSS 3.13).
>
>[... skip ...]
>
> It's something I wanted to do for YEARS, but for as long as I was employed to work on NSS, I was told that continued support for SSL2 was an ongoing business requirement.  I am sad that the opportunity to make those simplifications did not come along until it was too late for me.

Hello, Nelson.

Do I understand right, - the current product (NSS) owner (Mozilla Foundation ?) has no certain opinion regarding SSLv2 support ?

Regards,
--
Konstantin.
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to remove SSL 2.0 support from NSS trunk (NSS 3.13)

Nelson B Bolyard-2
On 2010-09-07 06:20 PDT, Konstantin Andreev wrote:

> On 08/31/10 05:01, Nelson B Bolyard wrote:
>> On 2010/08/30 17:32 PDT, Wan-Teh Chang wrote:
>>> I propose that we remove SSL 2.0 support from the NSS trunk (NSS
>>> 3.13).
>> [... skip ...]
>>
>> It's something I wanted to do for YEARS, but for as long as I was
>> employed to work on NSS, I was told that continued support for SSL2 was
>> an ongoing business requirement.  I am sad that the opportunity to make
>> those simplifications did not come along until it was too late for me.
>
> Hello, Nelson.
>
> Do I understand right, - the current product (NSS) owner (Mozilla
> Foundation ?) has no certain opinion regarding SSLv2 support ?

For years, NSS has been a collaboratively owned project, without any
one collaborator being viewed at the exclusive, or even primary, owner.
Today, the companies that continue to make significant contribution to
NSS, either with development staff, or with IT support (servers of
various kinds), or both, include Google, Red Hat, Oracle (formerly Sun), and
Mozilla.

The people whom I regard as the present NSS module owners are Bob and
Wan-Teh, from Red Hat and Google, respectively.

Regarding the companies who have sponsored the project in various ways:

- Apparently Google (as represented by Wan-Teh) favors removing SSL2 support.
- I do not know what position Red Hat has on this.  (Bob?)
- I believe Mozilla would not object at all, since they have disabled SSL2
support in their clients, but they provide only IT support.
- When I worked at Sun (now Oracle), they believed they had ongoing
obligations to support SSL2 for some of their customers.  I imagine they
will attempt to support those customers with a LOOOONG lived NSS 3.12
branch, and hence may not object to removing SSL2 from 3.13.  But that's
pure speculation on my part.  (I hope Oracle's remaining NSS developer
will speak to this here.)

--
/Nelson Bolyard    (speaking only for myself)
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to remove SSL 2.0 support from NSS trunk (NSS 3.13)

Nelson B Bolyard-2
In reply to this post by Konstantin Andreev-2
(This is a repost.  I posted this message earlier today, but it seems
not to have gone out.  Please let me know if you get two copies.)

On 2010-09-07 06:20 PDT, Konstantin Andreev wrote:

> On 08/31/10 05:01, Nelson B Bolyard wrote:
>> On 2010/08/30 17:32 PDT, Wan-Teh Chang wrote:
>>> I propose that we remove SSL 2.0 support from the NSS trunk (NSS
>>> 3.13).
>> [... skip ...]
>>
>> It's something I wanted to do for YEARS, but for as long as I was
>> employed to work on NSS, I was told that continued support for SSL2 was
>> an ongoing business requirement.  I am sad that the opportunity to make
>> those simplifications did not come along until it was too late for me.
>
> Hello, Nelson.
>
> Do I understand right, - the current product (NSS) owner (Mozilla
> Foundation ?) has no certain opinion regarding SSLv2 support ?

For years, NSS has been a collaboratively owned project, without any
one collaborator being viewed at the exclusive, or even primary, owner.
Today, the companies that continue to make significant contribution to
NSS, either with development staff, or with IT support (servers of
various kinds), or both, include Google, Red Hat, Oracle (formerly Sun), and
Mozilla.

The people whom I regard as the present NSS module owners are Bob and
Wan-Teh, from Red Hat and Google, respectively.

Regarding the companies who have sponsored the project in various ways:

- Apparently Google (as represented by Wan-Teh) favors removing SSL2
support.
- I do not know what position Red Hat has on this.  (Bob?)
- I believe Mozilla would not object at all, since they have disabled SSL2
support in their clients, but they provide only IT support.
- When I worked at Sun (now Oracle), they believed they had ongoing
obligations to support SSL2 for some of their customers.  I imagine they
will attempt to support those customers with a LOOOONG lived NSS 3.12
branch, and hence may not object to removing SSL2 from 3.13.  But that's
pure speculation on my part.  (I hope Oracle's remaining NSS developer
will speak to this here.)
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto