[Serusers] TLS comments

[Andrei Pelinescu-Onciul]

On Feb 03, 2006 at 16:02, Klaus Darilion <klaus.mailinglists at pernau.at> wrote:
> Andrei Pelinescu-Onciul wrote:
> >On Feb 03, 2006 at 15:48, Jan Janak <jan at iptel.org> wrote:
> >
> >>Andrei Pelinescu-Onciul wrote:
> 
> >>>> 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.
> 
> I think this is not possible in all cases. There are many SIP scenarios 
> where you can not check the domains. For example in-dialog requests with 
> forwarding scenarios. Orwhen the TLS connection has to reestablished for 
> responses. Then which SIP domain do you use?

That's why you should set tls certificates/cas on an ip base (it would
be easy to choose the correct certificate/ca).
The tls "extended" certificate checks will just make sure that the
certificate was issued for the ip or dns name of the peer.

This should be a configuration option (e.g tl_verify= off|on|extended).
What I'm trying to say is that certificate validity checks don't make
sense in the script, in the "normal scenarios".
You could use them (with tls_verify=on), but not to deny access in
general, just for some limited resources (e.g. allow local calls, but
permit relaying only if <extra certificate checks>).


Andrei


> 
> regards
> klaus