On Thu, Jul 7, 2011 at 3:11 PM, Olle E. Johansson <o...@edvina.net> wrote:
> > > 2) not perform validation of the upstream element cert. Because by > > > forwarding a response, by definition, it acts as a server in this > particular > > > transaction(request, and any responses to it). > > > > > > Why one would care validating a certificate of an upstream element when > > > forwarding a response, if one doesn't case about that validity when > he's > > > forwarding a request? > > > > It could occur that proxy A presents to proxy B a client TLS > > certificate owning domain atlanta.com, and then proxy A routes a > > request witth From domain "atlanta.com" to proxy B. Let's also suppose > > that the Via contains "myserver.org" in sent-by-host. > > > > proxy B cannot forward a response to proxy A using the TLS connection > > so resolves myserver.org and connects there using TLS. Then proxy A > > shows a certificate for domain atlanta.com rather than myserver.org. > > Should proxy B allow it? > > > > 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. > Two policies are possible, the server-only cert validation, and mutual cert validation. We are discussing server-only cert validation scenario. Why would Proxy B want to _validate_ the certificate of Proxy A if it have not done so when Proxy A established a connection? Proxy B might want to _verify_ that Proxy A presented the same certificate when Proxy B falls back. If connection is invalid Proxy B(UAS) doesn't become a UAC to Proxy A just because the underlying connection was closed and Proxy B is now reconnecting. Proxy B is forwarding a _response_, therefore its role is UAS. And in the scenario in question, UAC cert is not validated. > Anyhow, I agree that it does not make sense to verify a certificate > > when sending a response using the fallback mechanism (sending it to > > the Via sent-by-host). > > > If you still have a valid connection. But if you don't.... > You silently discard the response. This is as per rfc3261, Section 16.9. This is one helluva topic! Regards, Brez _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
