24 jun 2013 kl. 10:18 skrev Daniel Pocock daniel@pocock.com.au:
On 24/06/13 09:03, Olle E. Johansson wrote:
21 jun 2013 kl. 18:14 skrev Emil Ivov emcho@jitsi.org:
On 21.06.13, 17:41, Olle E. Johansson wrote:
21 jun 2013 kl. 15:05 skrev Daniel Pocock <daniel@pocock.com.au mailto:daniel@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@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