7 jul 2011 kl. 16.45 skrev Brez Borland: > 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. Proxy A sets up a connection to proxy B and have a request with a SIP target URI in mind. It needs to validate proxy B before transmitting the message. I think we're in agreement there.
When proxy B sets up a connection to proxy A with another target SIP URI, it needs to validate that URI. It can't assume anything, nothing, since it has never gotten a certificate from proxy A... > > 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. RIght. That's one way of doing it. > > > > This is one helluva topic! Agree! /O _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
