29 Oct
2012
29 Oct
'12
11:52 a.m.
On 26.10.2012 22:03, Olle E. Johansson wrote:
26 okt 2012 kl. 21:08 skrev Klaus Darilion
<klaus.mailinglists(a)pernau.at>at>:
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.
Am 26.10.2012 14:08, schrieb Olle E. Johansson:
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. 25 okt 2012 kl. 19:05 skrev Klaus Darilion
<klaus.mailinglists(a)pernau.at>at>:
AFAIK there is no difference to TLS. If there is a TLS connection
whose remote address matches the next hop, it will be used. 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? 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