Subject: Re: [xmpp] 3920bis-07

From: Simon Josefsson <[email-masked]>
Date: Sat, 01 May 2010 11:45:02 +0200

Peter Saint-Andre <[email-masked]> writes:

> On 4/29/10 1:53 AM, Simon Josefsson wrote:
>> Philipp Hancke <[email-masked]> writes:
>> 
>>> Simon Josefsson wrote:
>>>>> How is this text?
>>>>>
>>>>>    Implementations of TLS typically support multiple versions of the
>>>>>    Transport Layer Security protocol as well as the older Secure Sockets
>>>>>    Layer (SSL) protocol.  Because of known security vulnerabilities,
>>>>>    XMPP servers and clients SHOULD NOT support or offer SSL 2.0.  See
>>>>>    Appendix E.2 of [TLS] for further details.
>>>>
>>>> I propose MUST NOT instead of SHOULD NOT.
>>>
>>> Should servers reject SSLv2 client hellos that indicate that the
>>> client also understands SSLv3 and TLSv1 (such as those generated by
>>> openssl's SSL_v23_method)?
>> 
>> I don't think that follows.
>> 
>> Clients and servers should, however, reject any negotiation of SSLv2
>> because that is an insecure protocol.  I don't believe there are any
>> significant security problems in offering a SSLv2 client hello that ends
>> up negotiating TLSv1?  FWIW, GnuTLS supports SSLv2 client hellos in
>> server mode.
>
> Why offer it or request it if no one will support it?

I don't see any reason.  I don't see any strong reason (i.e., security
reason) to forbid it either, though.  I would prefer to forbid it in
order to reduce complexity (which can be seen as a security reason,
because higher complexity typically always leads to security issues).

>> On the other hand, I don't see the point of sending a SSLv2 client hello
>> if neither client and server will accept SSLv2.  But I also don't see a
>> strong reason to forbid that in the specification.  One reason to forbid
>> it may be to reduce complexity.
>
> Another reason might be that if we make a strong statement in the spec
> about prohibiting SSLv2 then we'll convince more implementations to drop
> support for it -- and that seems to be the right direction to go in.
>
> FYI, in my working copy I currently have the following text:
>
> ***
>
> 13.8.  TLS Versions
>
>    Implementations of TLS typically support multiple versions of the
>    Transport Layer Security protocol as well as the older Secure Sockets
>    Layer (SSL) protocol.  Because of known security vulnerabilities,
>    XMPP servers and clients MUST NOT request or offer SSL 2.0, and MUST
>    close the TCP connection if the other party to an XML stream requests
>    or offers SSL 2.0.  See Appendix E.2 of [TLS] for further details.
>
> ***

I like this!

Thanks,
/Simon

---

From: Kevin Smith <[email-masked]>
Date: Sun, 2 May 2010 15:09:23 +0100

>   or offers SSL 2.0.  See Appendix E.2 of [TLS] for further details.

I may well misunderstand, but I think that means that any 3290bis
client must refuse to connect to a server that offers (possibly as
well as SSL3) SSL2. Or the same with s2s. So anyone running a
pre-3920bis server that offers ssl2 will be unable to talk to new
clients or new servers - that sounds bad to me. MUST NOT negotiate
SSL2 sounds sane, but MUST terminate if it's offered sounds
over-zealous.

Or I just don't understand.

/K

---

From: Philipp Hancke <[email-masked]>
Date: Sun, 02 May 2010 19:50:32 +0200

> pre-3920bis server that offers ssl2 will be unable to talk to new

Can the client deduce the ability of the server to do sslv2 from the 
server hello's server_version?

 > SSL2 sounds sane, but MUST terminate if it's offered sounds

Most servers already send TLSv1 handshakes. I do not expect many 
failures, but it is easy to make some tests how this would affect
currently deployed servers.

philipp

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 02 May 2010 21:50:51 +0200

> SSL2 sounds sane, but MUST terminate if it's offered sounds

Any client or server using SSLv2 today is insecure.  Do you have numbers
to indicate that this is a real-world problem?  My perception is that
SSLv2 is rare these days.

/Simon

---

From: Kevin Smith <[email-masked]>
Date: Sun, 2 May 2010 21:13:51 +0100

> SSLv2 is rare these days.

Not at all. My knowledge of SSL is about as limited as it comes, so
I'm sorry if I'm just straight wrong. I thought it was possible to
advertise both SSL2 and SSL3 in the handshake, so an e.g. SSL3 only
server could connect to an SSL2/3 server securely, without needing to
ditch the connection because the second server would have been willing
to SSL2. If either I'm wrong, or there are simply no servers that
would do such a thing anyway, ignore me.

/K

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 02 May 2010 22:28:42 +0200

> would do such a thing anyway, ignore me.

It is possible to send a SSLv2 client hello and negotiate SSLv3.  I'm
not aware of any implementation that disconnects just because SSL2 is
advertised assuming SSLv3 is also supported, although some people may
like a policy like that.

However, since SSLv2 is insecure, I don't understand why you would want
to advertise support for SSLv2 if you (presumably) are not going to
accept negotiation of SSLv2.

Generally, if SSLv2 is widely used in the XMPP community, I think you
have some important security upgrading work to do!

/Simon

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 02 May 2010 20:07:13 -0600

> Or I just don't understand.

You do understand. We are proposing that the replacement for RFC 3920
will forbid SSLv2 in any form. Any clients or servers that request or
offer SSLv2 will not be in compliance with that RFC, and given the
security problems with SSLv2 that is a Good Thing[tm].

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 03 May 2010 14:58:06 -0600

> security problems with SSLv2 that is a Good Thing[tm].

Kevin and I chatted about this over IM and agreed that the clause about
terminating the TCP connection goes too far (because it means that if
the other party merely *offers* SSLv2 you will be forced to downgrade to
unencrypted, even if you never would have accepted SSLv2). Therefore the
text in my working copy now reads:

   Implementations of TLS typically support multiple versions of the
   Transport Layer Security protocol as well as the older Secure Sockets
   Layer (SSL) protocol.  Because of known security vulnerabilities,
   XMPP servers and clients MUST NOT request, offer, or use SSL 2.0.
   See Appendix E.2 of [TLS] for further details.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 03 May 2010 23:03:21 +0200

Peter Saint-Andre <[email-masked]> writes:

> Therefore the text in my working copy now reads:
>

Great, I think this wording is better.

/Simon

---

From: Ben Campbell <[email-masked]>
Date: Thu, 6 May 2010 14:13:40 -0500

> security problems with SSLv2 that is a Good Thing[tm].

This sounds like it might be a good application for Postel's law ( http://en.wikipedia.org/wiki/Postel%27s_law ), so long as we can prevent SSLv2 from actually getting used.

> 
> Peter
> 
> -- 
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> 
> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp