[Free-RTC] kamaillio script for federated communications

[Olle E. Johansson]

24 jun 2013 kl. 10:18 skrev Daniel Pocock <daniel at pocock.com.au>:

> On 24/06/13 09:03, Olle E. Johansson wrote:
>> 21 jun 2013 kl. 18:14 skrev Emil Ivov <emcho at jitsi.org>:
>> 
>>> 
>>> On 21.06.13, 17:41, Olle E. Johansson wrote:
>>>> 21 jun 2013 kl. 15:05 skrev Daniel Pocock <daniel at pocock.com.au
>>>> <mailto:daniel at pocock.com.au>>:
>>>> 
>>>>>> * The config uses DNS to establish the transport available on the
>>>>>> remote proxy. It doesn't use DNSSEC to do this.
>>>>> I'm not sure if DNSSEC matters if the TLS certificate is valid - some
>>>>> people may prefer to trust the TLS cert and not place any trust in the
>>>>> DNSSEC trust model
>>>> THat's quite a misguided statement. If DNS points to an incorrect
>>>> destination that succeeds
>>>> in providing a certificate that you accept - how can that be a good
>>>> solution?
>>> That's a bit inaccurate. If I am trying to reach jit.si through TLS and a malicious DNS record sends me toward evil.example.com, it wouldn't be enough for evil.example.com to just have a valid cert.
>>> 
>>> It would need to provide a valid certificate for jit.si
>> Of course - that's the only one you should accept. (hopefully)
> 
> Just to clarify: in reSIProcate, when we look at a client or server-side
> cert,
> 
> a) we check if it has subjectAltName (sometimes dubbed SAN) - if there
> is one or more subjectAltName attributes, we take all of their values as
> valid domains and put them in a list called TlsConnection::mPeerNames
> 
> b) if there is no subjectAltName, we take the common name (CN) which can
> have only one value and put that in mPeerNames (so it is a vector with
> just 1 value)
> 
> c) higher-level authentication checks then look at each incoming message
> and screen it against mPeerNames
> 
> The CN or subjectAltName can be in a domain name format or an email
> address format.  E.g. a Jitsi client may send CN=daniel at pocock.com but a
> server-server connection might send CN=pocock.com.au
> 
> Does Kamailio have the ability to analyze the certs in the same detail,
> e.g. extracting subjectAltName and using both DNSname and email values? 
> Are the values available from the configuration script?  In other words,
> I would think (a) and (b) would be in the TLS code and (c) would be part
> of the cfg file
I was aware that Resiprocate did this correctly, since we've tested it
many times at SIPit :-)

The important thing here for other implementations is that if there are 
SANs in the certificate you should NOT check the CN. Just ignore whatever
is in there. Also, you can not reuse that connection in the other direction
unless you got a client cert. 

I need to check the Kamailio outbound connections TLS code if we do this on outbound
connections, unless Daniel can make a comment here. He knows that code better than
I do.

For client certificates we have great support and you can check most fields in the X.509
structure with routing script functions. We are working to implement a way
to check the outbound connection TLS properties in the routing script before we send any
message.

The Asterisk TLS implementation is marked experimental since many releases and
many years. Hopefully the new SIP stack will finally give Asterisk a proper TLS
implementation.

Cheers,
/O