[sr-dev] Playing with TCP and TLS

[Iñaki Baz Castillo]

2012/10/29 Olle E. Johansson <oej at edvina.net>:
>>> That's bad. We need to check the domains in the certificate before
>>> re-using it. If they showed NO client cert, we should open a new
>>> one. If they showed a client, we should verify.
>>
>> Not necessarily. Usually SIP clients are behind NAT (not servers) and thus we need NAT traversal for these clients and these clients usually do not have a client certificate.

And that is 100% covered by Outbound RFC 5626.



>> For servers, we usually want to have separate TLS connections for each direction.

Unless RFC 5923 is implemented and requested. But after read this RFC
I strongly think that it's very hard to implement. Even more, it
requires inspecting the server certificate before connecting. Kamailio
does not provides callbacks for the user to decide wheter to accept
connecting to a TLS server or not onve the server's certificate is
retrieved.



>> In your "untypical" scenario the NAT traversal should be fixed on the client side and then you could use 2 separate TLS connections.

Olle's scenario is very hard IMHO. If like a server asking for
Outbound RFC 5626 usage, which is anti-RFC5626 (no proxies, but just
UAs can do Outbound and just when connecting to their edge proxy).


> Will that happen with Kamailio today? Won't the TCP matching make us reuse the existing connection?

You receive a TCP connection from 1.2.3.4:9999. And later you need to
send a request to 1.2.3.4:5060. Why do you assume that you can reuse
the connection from 1.2.3.4:9999? why if there are two SIP nodes
listening into different ports (i.e. 5060 and 6060) within the same
server with IP 1.2.3.4?




>>> Will the on-send route give me the possibility or is it triggered
>>> before kamailio selects a tcp connection? I'm a bit unclear of the
>>> exact situation where the on-send route is called.
>>
>> [on-send] is just before the message is sent. AFAIK it is executed before the message is handled over to the transport layer - thus I think TLS paramters of the new connection are not available.

Kamailio needs a callback for the user to inspect client's or server's
TLS certificates and decide whether to continue or reject the TLS
session.




>> Generally, domain verification against the certificate name is broken. For example if you have to reopen a TLS connection for an in-dialog request, there is no proper URI (RURI, next hop Route URI) to compare against the certificate.

The trick is:

- The proxy forwarding a request via TLS needs to set a domain in the
Record-Route.
- Such a domain should not have SRV records (otherwise the indialog
request could arrive to other server).

This may require having a TLS certificate with varios AltSubjectName entries:

- mydomain.com
- server1.mydomain.com
- server2.mydomain.com
- server3.mydomain.com

mydomain.com has NAPTR/SRV resouorces while the others are just A/AAAA
resources. Clients are configured to use mydomain.com, but each proxy
in the server infraestructure should set the proper
serverN.mydomain.com in Record-Route when routing via TLS. This should
fix the problem...

...but then you realize that lot of clients CANNOT resolve a domain in
a Route header, so they cannot send in-dialog requests if the
Record-Route contains a domain...



-- 
Iñaki Baz Castillo
<ibc at aliax.net>