7 jul 2011 kl. 14.11 skrev Brez Borland: > On Thu, Jul 7, 2011 at 12:09 PM, Iñaki Baz Castillo <i...@aliax.net> wrote: > 2011/7/7 Brez Borland <brez...@gmail.com>: > > I think once TLS context is invalidated(i.e. rejected to be resumed by Proxy > > A), Proxy B should either: > > > > 1) return an error to the downstream UAS (i.e. failure to send response > > _permanently_), or > > What does mean "return an error to the downstream UAS"? This is, the > UAS has sent to proxy B a SIP response, and proxy B is not able to > forward it to proxy A. How could proxy B "return an error to the UAS"? > There is no SIP mechanism for that, do I miss soemthing? > > You are right, I meant to say that Proxy B should just drop the response. > This is as per rfc3261, Section 16.9. > > > > > 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.
> > Regards, > > > > 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.... /O _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
