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.