29 Oct
2012
29 Oct
'12
8:16 a.m.
29 okt 2012 kl. 11:57 skrev Iñaki Baz Castillo <ibc(a)aliax.net>et>:
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...
Right. Thanks for that explanation. Missed that. But if the
server for some reason
opens FROM 5060 we're back in my issues.
[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.
Should be URI alt names with sip:server1.mydomain.com etc.
2012/10/29 Olle E. Johansson <oej(a)edvina.net>et>:
Agree.
>> 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...
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