On 13-10-2005 10:34, Klaus Darilion wrote:
Jan Janak wrote:
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.
This can be done in a client2proxy scenario, but not in a proxy2proxy scenario where user interaction is not possible.
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.
Any real life values for the introduced delay? I think (open)ser should be able to reuse TLS connections and thus the handshake happens only once in a while.
It took several seconds to close the ring, I do not recall exact value. Most of the proxies had to establish TLS connection and perform TLS handshake.
Jan.