7 jul 2011 kl. 16.28 skrev Iñaki Baz Castillo: > 2011/7/7 Olle E. Johansson <o...@edvina.net>: >>> Proxy B should not discard data(certificates previously received) >>> associated with Proxy A when it tries to reconnect to it. I think Proxy B >>> should retain the certificate atlanta.com, and have it associated with >>> myserver.org, at least for the lifetime of transaction. So after resolving >>> and connecting to myserver.org it could compare the newly received >>> certificate atlanta.com with the one in caches. >>> >> Never ever. You can't assume that because you got a certificate valid for >> one domain that it's valid for another based on reverse DNS... If the target >> URI domain doesn't match the certificate, it's not a valid connection. TLS >> and certificates doesn't give room for "assuming" or "guessing". That's just >> wrong. > > So that would require that the Via in the request sent from proxy-A to > proxy-B to be a domain. If it's an IP, then when proxy-B connects to > it for sending the response (fallback mechanism) the certificate > validation would fail. > > And this also requires that the domain in the request Via sent-by to > point *just* to proxy-A server (no SRV stuff or varios A/AAAA > records). If not, proxy-B could decide to contact other proxy rather > than proxy-A itself (so the response would not be matched within its > transaction and would be discarded by the new proxy). > > And of course, the domain in Via sent-by should be included within the > certificate proxy-A presentates to proxy-B. This means that, for > example: > > - atlanta.com points (via NAPTR/SRV) to proxy-A1, proxy-A2 and proxy-A3. > - proxy-A1 has a certificate including domains atlanta.com and > proxy-a1.atlanta.com. > - proxy-A2 has a certificate including domains atlanta.com and > proxy-a2.atlanta.com. > - proxy-A3 has a certificate including domains atlanta.com and > proxy-a3.atlanta.com. > - proxy-A1 connects to proxy-B and presents its certificate (valid, > OK). Also proxy-B presents its cert (OK). > - proxy-A1 sends a request with From domain "atlanta.com" and Via > sent-by "proxy-a1.atlanta.com". > - TLS connection gets broken and proxy-B does fallback resolving > "proxy-a1.atlanta.com" (Via sent-by). > - proxy-B then opens a new TLS connection with proxy-A1 and receives > the certificate with includes "proxy-a1.atlanta.com" domain, so > proxy-B is happy and sends the response. > > In *any* other case this would not work at all, which means that this > will NEVER work, not at least during this Century. But it could be > cool to write a paper about it XD > > Well, the question is what to put in the Via header. You need something that points back if you have transaction state in one of your proxys... The received parameter helps with that. You don't want to have IP addresses or host names in certs either. So -without checking any RFCs - I think the via should contain a domain that's valid in a cert and the received header points back to the proxy that actually sent the message.
This stuff will become even more important with SIP+dtls... /O _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
