[sr-dev] about tls_method

[Andrei Pelinescu-Onciul]

On Oct 04, 2010 at 10:48, Juha Heinanen <jh at tutpro.com> wrote:
> jan,
> 
> thanks for your comments.
> 
> > If sip-communicator uses openssl then it should also support SSLv23
> > and TLSv1. It maybe be configured to use the SSLv23 mode by default
> > which should theoretically provide the best compatibility with other
> > implementations because it supports all other protocols (TLSv1, SSLv3,
> > SSLv2).
> 
> there are on configuration options in sip-communicator ui regarding ssl
> protocol versions.
> 
> > In SSLv23 the client is supposed to send the initial hello in SSLv2
> > for compatibility reasons.
> > 
> > If you configured your server to use TLSv1 then it will accept TLSv1
> > hellos only and the SSLv2 hello won't be accepted.
> 
> if SSLv23 supports all protocol versions (also TLSv1) then i think sip
> router tls module needs a fix:  if i tls_method TLSv1 is set, then sr
> should accept whatever hellos as long as the final result of the
> negotiation is TLSv1.
> 
> andrei, any commend on this?

Strictly speaking according to the RFCs, only TLSv1 should be supported
(and this includes only a TLSv1 hello messsage!).

The problem with SSLv23 is that it should use SSLv23 only when it acts
as server (if it uses SSLv23 when it acts as client a TLSv1 only server
will not allow it to connect). Moreover if you use SSLv23 you might end
up accepting a SSLv2 client.  Theoretically we could workaround this in
the code by setting SSL_OP_NO_SSLv2 and SSL_OP_NO_SSLv3 (probably only
for the server part, the client would still have to support only  TLSv1)
but I never tested it.

OTOH if you don't care about accepting clients using SSLv2 or SSLv3, you
could set in the tls config the method to TLSv1 for default client mode
and SSLv23 for the default server mode.

> 
> > > also, it was not clear from tls/README that if i set
> > >
> > >      modparam("tls", "tls_method", "SSLv23")
> > >
> > > will it mean that TLSv1 connections (as required by rfc3261) are not
> > > accepted if UA only support TLSv1 and proposes in client hello?
> > 
> > Yes. But if the client is configured to use SSLv23, they could
> > exchange the initial hellos in SSLv2 and then upgrade to TLSv1.
> 
> yes, but as i mention in above, looks like sr's tls_method TLSv1 does
> not wait for the upgrade, but reject the connection attempt at first
> hello.
> 
> > Although RFC3261 requires TLSv1, it is not clear to me whether they
> > mean that TLSv1 connections should be used from start or if upgrading
> > to TLSv1 after the initial hello in SSLv2 is also considered
> > compliant.
> 
> it sounds reasonable to me that as long the result is TLSv1, it should
> not matter what kind of negotiation was done to achieve it.  the old
> rule is be liberal in what you expect.

In this case the client is wrong and to support it we would need to quickly
add some untested code to the new release... We would also need some
other/extended config option (strict TLSv1 and compat TLSv1).
Maybe for the 3.2 or 3.1.1.


Andrei