[Users] Re: [Serusers] trusting peers

[Jan Janak]

On 12-10-2005 17:16, Klaus Darilion wrote:
> Jan Janak wrote:
> >On 12-10-2005 13:09, Klaus Darilion wrote:
> >
> >>Cesc wrote:
> >>
> >>>Hi,
> >>>
> >>>Klaus, i think that you hit the fountain of truth :)
> >>>As of now, ser-tls only provides transport layer authentication. Not 
> >>>more. Who is allowed to authenticate? all those you trust, that is, all 
> >>>those with the cert signed by the CAs you trust. If you picked a 
> >>>ruthless CA that would give away certs to hacking.incorporated.com 
> >>><http://hacking.incorporated.com> ... sorry :)
> >>>
> >>
> >>So, in current ser, there is no domain comparison between the requested 
> >>domain (request URI) and the domain in the certificate (for outgoing 
> >>TLS)? This should be done by TLS part automatically in t_relay()
> >
> >
> >   I disagree that it should be done automatically. First of all domain
> >   comparison is not plain string comparison (domains versus IP
> >   addresses). Secondly there is no guarantee that the domain of the
> >   proxy server will be in the Request-URI. Think about pre-loaded route
> >   sets and in-dialog requests. Such requests would typicaly contain
> >   the IP of the proxy server, not domain.
> 
> Yes, you are right. Validation should be against the next hop (whatever 
> it is, request URI or Route URI.

  And this would be an IP address, most likely. So you will need to find
  out the domain/hostname in order to compare it with the
  domain/hostname in the certificate.

> But we need to handle the validation of the domain in the certifiacte 
> somehow. Is it useful to differ between in-dialog and out-of-dialog 
> requests?
> 
> I wonder why there are no best practises/guidelines how to handle the 
> certificate's domain validation in SIP. Does someone know how they 
> handle this at the sipit events?

  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.

  Unfortunately such warnings are common. Real certificates (verified by
  trusted CAs) are quite expensive and sometimes hard to obtain. Real
  CAs also have very strict policies sometimes.
  
  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.

     Jan.