29 okt 2012 kl. 11:57 skrev Iñaki Baz Castillo ibc@aliax.net:
2012/10/29 Olle E. Johansson oej@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