On 12-10-2005 17:16, Klaus Darilion wrote:
Jan Janak wrote:
On 12-10-2005 13:09, Klaus Darilion wrote:
Cesc wrote:
Hi,
Klaus, i think that you hit the fountain of truth :) As of now, ser-tls only provides transport layer authentication. Not more. Who is allowed to authenticate? all those you trust, that is, all those with the cert signed by the CAs you trust. If you picked a ruthless CA that would give away certs to hacking.incorporated.com http://hacking.incorporated.com ... sorry :)
So, in current ser, there is no domain comparison between the requested domain (request URI) and the domain in the certificate (for outgoing TLS)? This should be done by TLS part automatically in t_relay()
I disagree that it should be done automatically. First of all domain comparison is not plain string comparison (domains versus IP addresses). Secondly there is no guarantee that the domain of the proxy server will be in the Request-URI. Think about pre-loaded route sets and in-dialog requests. Such requests would typicaly contain the IP of the proxy server, not domain.
Yes, you are right. Validation should be against the next hop (whatever it is, request URI or Route URI.
And this would be an IP address, most likely. So you will need to find out the domain/hostname in order to compare it with the domain/hostname in the certificate.
But we need to handle the validation of the domain in the certifiacte somehow. Is it useful to differ between in-dialog and out-of-dialog requests?
I wonder why there are no best practises/guidelines how to handle the certificate's domain validation in SIP. Does someone know how they handle this at the sipit events?
I am beginning to think that it should be perhaps the caller who decides whether a request should be forwarded to the proxy server if the domain name in the certificate does not match the domain in the Request-URI. Web browsers do the same, they do not refuse a https connection if the server certificate domain does not match the hostname in the HTTP URI, they just warn the user that the authenticity of the server cannot be established.
Unfortunately such warnings are common. Real certificates (verified by trusted CAs) are quite expensive and sometimes hard to obtain. Real CAs also have very strict policies sometimes.
I do not recall anyone doing that sort of test at sipits (but I did not test with everyone). Even certificate validation was problem during TLS multiparty tests, not even speaking about the delay all the TLS hanshakes introduced in a ring of 6 proxies.
Jan.