[sr-dev] Playing with TCP and TLS

[Olle E. Johansson]

29 okt 2012 kl. 11:57 skrev Iñaki Baz Castillo <ibc at aliax.net>:

> 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.
Agree.
> 
> 
> 
>>> 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.
Yes, the reuse has a big hole. How do I know if it's a client2server or a server2server connection
that was opened to my server? If it's a server2server and I want to reuse it, I should require
a TLS certificate. It fails to tell me how I separate them. Now, if I could reject the first request
with a response code and reason that says "reopen with client cert" we could upgrade the connection.

In jabber, they are separate ports and SRv records...
> 
> 
> 
>>> 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?
Right. Thanks for that explanation. Missed that. But if the server for some reason
opens FROM 5060 we're back in my issues.

> 
> 
> 
> 
>>>> 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.
[event-route:TLS-connect-out] and [event-route:TLS-connect-in] are needed for this. One when we receive a connection and one when we connect somewhere else.

> 
> 
> 
> 
>>> 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
Should be URI alt names with sip:server1.mydomain.com etc.

> 
> 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...
Right.

> 
> ...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...
Should they do that with outbound? Just haul it down the open flow...

But yes, broken clients stop progress. I need to start testing this.

Thanks to both of you for valuable feedback! 
/O