[sr-dev] Playing with TCP and TLS

[Klaus Darilion]

On 26.10.2012 22:03, Olle E. Johansson wrote:
>
> 26 okt 2012 kl. 21:08 skrev Klaus Darilion
> <klaus.mailinglists at pernau.at>:
>
>> Am 26.10.2012 14:08, schrieb Olle E. Johansson:
>>> 25 okt 2012 kl. 19:05 skrev Klaus Darilion
>>> <klaus.mailinglists at pernau.at>:
>>>
>>>> Kamailio uses the next hop target (probably the URI in the Path
>>>> header) and searches for open TCP connections to this target. I
>>>> guess the Path header contains the private IP address of the
>>>> outbound proxy, thus it does not match the open TCP connection.
>>>> If there is not outboundproxy, the solution is simple: as
>>>> always use fix_nated_register() on REGISTER. Then, after
>>>> lookup() the proxy will search for a TCP connection to the
>>>> "received" IP:port and find and uses the existing connection.
>>> Thinking about TLS - how do we match there?
>>
>> AFAIK there is no difference to TLS. If there is a TLS connection
>> whose remote address matches the next hop, it will be used.
>
> 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.

For servers, we usually want to have separate TLS connections for each 
direction. In your "untypical" scenario the NAT traversal should be 
fixed on the client side and then you could use 2 separate TLS connections.

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

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.

regards
Klaus
>
> /O
>