[SIP Beyond VoIP] TLS certificate of sip2sip.info is "wrong"

[Adrian Georgescu]

As a parenthesis, my opinion is that any intermediate hop TLS cert, right or wrong as far as the common name is concerned, is very week for privacy purposes for an end-to-end service like SIP. The only thing it can resonably protect is against those who managed to access the LAN. As all certs are issued by third-parties, you cannot trust them as anyone who hijacks the connection and controls the CA can foul you into thinking you are taking to the right party. Better said, TLS encryption can be considered compromised unless you use your own CA. Secondly, because data is decrypted by any intermediate hop owning the TLS cert for the purpose of routing, you can also consider any signalling information compromised by design as you do not know who controls the service. What’s left in practice is end-to-end media encryption techniques where things can be negotiated end-to-end like OTR and zRTP. Assuming calls to encryption libraries on your local hardware are not hijacked as well by the host OS.

Adrian

On 22 Jan 2014, at 12:41, Iñaki Baz Castillo <ibc at aliax.net> wrote:

> 2014/1/22 Iñaki Baz Castillo <ibc at aliax.net>:
>> 2014/1/22 Adrian Georgescu <ag at ag-projects.com>:
>>> I believe the cert is bound to the A record where the client attempts to connect after NAPTR and SRV record lookups. A domain is served by different A records for different services and the client should use the A record name for validation rather than the original domain.
>> 
>> Hi Adrian!
>> 
>> Honestly, I must re-check it, but for now I will say that AFAIR I am
>> right and you are wrong, so the domain in the certificate must match
>> the *original* SIP domain the client is connecting to, this is: the
>> domain in the Request-URI !
> 
> 
> Adrian, look at this please:
> 
> 
> RFC 5922:
> 
> 
> 7.3.  Client Behavior
> 
>   A client uses the domain portion of the SIP AUS to query a (possibly
>   untrusted) DNS to obtain a result set, which is one or more SRV and A
>   records identifying the server for the domain (see Section 4 for an
>   overview).
> 
>   The SIP server, when establishing a TLS connection, presents its
>   certificate to the client for authentication.  The client MUST
>   determine the SIP domain identities in the server certificate using
>   the procedure in Section 7.1.  Then, the client MUST compare the
>   original domain portion of the SIP AUS used as input to the RFC 3263
>   [8] server location procedures to the SIP domain identities obtained
>   from the certificate.
> 
> 
> So let me say that I am right ;)
> 
> 
> 
> 
> -- 
> Iñaki Baz Castillo
> <ibc at aliax.net>
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.ag-projects.com/pipermail/sipbeyondvoip/attachments/20140122/82875d4e/attachment.pgp>