[Serusers] TLS comments

[Andrei Pelinescu-Onciul]

On Feb 03, 2006 at 15:48, Jan Janak <jan at iptel.org> wrote:
> Andrei Pelinescu-Onciul wrote:
> > On Feb 01, 2006 at 14:43, Jan Janak <jan at iptel.org> wrote:
> >> Cesc wrote:
> >>> On 2/1/06, Klaus Darilion <klaus.mailinglists at pernau.at> wrote:
> >>>> Hi!
> >>>>
> >>>> I've tried the new TLS module:
> >>>>
> >>>> 1. It breaks compatibility with old TLS stack: Even when configured to
> >>>> use TLSv1, it sends an SSLv2 compatible HELLO:
> >>>>
> >>>> server2:~# ssldump
> >>>> New TCP connection #1: 10.10.0.41(33107) <-> 10.10.0.42(5063)
> >>>> 1 1  0.0088 (0.0088)  C>S SSLv2 compatible client hello
> >>>>    Version 3.1
> >>>>
> >>>>
> >>>> I do not know if this is a problem with the new or the old stack.
> >>>> Further I do not know what other TLS enabled SIP products use. Do they
> >>>> accept SSL compatible HELLOs?
> >>>>
> >>> Klaus, i don't think this is a bug ... i think that the hello is
> >>> always v2 and then (with the server hello message) the handshake is
> >>> upgraded to v3 or tlsv1. This way, you can have an sslv2-only client
> >>> try connecting to  any server, but the server will send back sslv3 or
> >>> tlsv1 server hello, thus disconnecting the client.
> >>   Yes, I think this is correct. The protocol version should be set to
> >>   TLSv1  afterwards, you can test this with @tls.version:
> > 
> > No, he is right, this is a bug.
> 
>    There was a problem in the configuration, since the protocol version
>   was not set correctly (this is now separated), so in fact the TLS
>   client in tls module was configured with SSLv23. Only tls server was
>   configured for TLSv1.
> 
> > A normal TLSv1 server will accept only TLS hello messages (version =
> > 3.1) and since sip is supposed to work only with TLS, this should be the
> > default (tls_method=TLS_USE_TLSv1).
> > The SSLv23 stuff will accept any type of hello. A client
> >  with the SSLv23 method will send a hello v2 message, indicating in it
> >  also tls and ssl 3.0 support (they will include tls specific ciphers
> >  a.s.o). The client sending v2 hellos is not exactly standard behaviour
> >  for TLS. It is a hack for backward compatibility, but a TLS only server
> >  will not accept it.
> > One of the clients that used a SSLv23 equivalent was Windows Messenger
> >  (it was doing this in 2003 when I wrote my ser tls code).
> > 
> > The tls method should be configurable to allow older/strange clients
> > support, but it should default to TLSv1 (btw: this is how you can reject
> >  v2 clients without SSL_OP_NO_SSLv2).
> 
>   Right now it defaults to SSLv23, should we change the defaults ?

Yes, I think so, a normal SIP implementation should speak TLSv1.

> 
> >>   if (@tls.version == "SSLv2") {
> >>        sl_send_reply("400", "Bad TLS protocol version");
> >>        break;
> >>   }
> > 
> > I think we should not handle TLS errors from the script. A TLS client
> > will expect the handshake phase to fail if it uses an unsupported SSL
> > version or the wrong certificate. Accepting the ssl connection and then
> > returning a SIP error or plainly dropping it, it's just wrong IMHO and
> > not very TLS frienldy/conformant.  That's what the handshake phase for.
> 
>   This was just debugging tip for Klaus. I think that the only case when
>   sending a SIP reply back is when the client presents a valid certificate
>   but the common name (or any other field used for authentication) is
>   invalid. That is if the client presented a valid certificate but incorrect
>   one then we should reject politely, otherwise tls handshake just fails.
> 
> > Moreover if you go to the trouble to accept the connection just to
> > reject it immediately you will waste more resources.
> > If you don't want to accept V2, then just change the method.
> > For cetificates: you either verify them (you can have verify off, verify
> >  but don't check host name/ip, verify all) or not. 
> 
>   The verification process does not include checking of common name, subject
>   alternative name and other certificate fields. This is what you should do
>   in the script.

No, I think you should have a verify all option.
You could use then the script to allow access to certain resources only
to certain clients, but the certificate validity checks should be done
at the tls level.

BTW: the above example should use exit -1  instead of break (to force
 close the tls connection, which otherwise would remain open until it
 timeouts or the remote side closes).


Andrei