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.