[Free-RTC] kamaillio script for federated communications

[Daniel Pocock]

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