29 okt 2012 kl. 11:57 skrev Iñaki Baz Castillo <[email protected]>: > 2012/10/29 Olle E. Johansson <[email protected]>: >>>> 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 _______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
