-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
I've been interested for some time in federated secure communications systems and in particular voice systems. I am a firm believer in the right to privacy. I am appalled but not entirely surprised by the latest revelations concerning PRISM.
I recently updated Daniel-Constantin Mierla's:
http://kb.asipto.com/kamailio:skype-like-service-in-less-than-one-hour
for kamailio 4 + jitsi, see below:
https://www.johncahill.net/wiki/index.php/Skype_like_conferencing_System
This config allows for TLS+ZRTP encrypted calls to be made between jitsi clients connected to different kamailio servers.
I would like some feedback on how to improve this config. I will flag up some failings straight away:
* Inter-domain peer to peer presence sharing doesn't work. Only intra-domain presence sharing. * TLS is enforced crudely by an iptables based firewall only allowing communications on port TCP 5061 TLS * The config uses DNS to establish the transport available on the remote proxy. It doesn't use DNSSEC to do this.
I will add any improvements to to my wiki and please feel free to cut paste + share.
I would like to share working recipes in a similar way to that done by Daniel Pocock and others on this list. Thanks, you work has inspired me.
Cheers, John
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 21/06/13 01:18, johnc wrote:
Hi,
I've been interested for some time in federated secure communications systems and in particular voice systems. I am a firm believer in the right to privacy. I am appalled but not entirely surprised by the latest revelations concerning PRISM.
I recently updated Daniel-Constantin Mierla's:
http://kb.asipto.com/kamailio:skype-like-service-in-less-than-one-hour
for kamailio 4 + jitsi, see below:
https://www.johncahill.net/wiki/index.php/Skype_like_conferencing_System
This config allows for TLS+ZRTP encrypted calls to be made between jitsi clients connected to different kamailio servers.
I would like some feedback on how to improve this config. I will flag up some failings straight away:
- Inter-domain peer to peer presence sharing doesn't work. Only
intra-domain presence sharing.
- TLS is enforced crudely by an iptables based firewall only allowing
communications on port TCP 5061 TLS
If the TCP and UDP ports are disabled in the Kamailio config, does that have a similar effect, forcing everything over TLS?
Is there any technical issue in Kamailio preventing mutual TLS validation from occurring?
One of the reasons I recommend Kamailio to people over the other SER variants is the TLS support is intended to do these things.
- 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
I will add any improvements to to my wiki and please feel free to cut paste + share.
I would like to share working recipes in a similar way to that done by Daniel Pocock and others on this list. Thanks, you work has inspired me.
Once it is more refined, I'd be happy to integrate it with the site www.rtcquickstart.org
Have you tested calling between a Kamailio user and repro user? Ideally they should be fully interoperable and if there is any fault on the repro side, please raise it on repro-users
21 jun 2013 kl. 15:05 skrev Daniel Pocock 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?
DNSsec verification tells you that you have a authorized binding between the hostname and the IP.
TLS will tell you that you have a binding between the URI you're looking for and the server.
That's two different things.
DANE - TLS verification using DNSsec - is an alternative to the current rather insecure way of handling CA certificates. But that's another story. I think you're mixing DANE with DNSsec in your statement, Daniel.
/O
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 6/21/13 9:41 AM, 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?
DNSsec verification tells you that you have a authorized binding between the hostname and the IP.
TLS will tell you that you have a binding between the URI you're looking for and the server.
That's two different things.
DANE - TLS verification using DNSsec - is an alternative to the current rather insecure way of handling CA certificates. But that's another story. I think you're mixing DANE with DNSsec in your statement, Daniel.
DANE will be a good alternative, once it is more widely deployed. Unfortunately I think that won't happen very quickly. :(
Peter
- -- Peter Saint-Andre https://stpeter.im/
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
Emil
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)
/O
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
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 6/24/13 2:33 AM, Olle E. Johansson wrote:
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.
RFC 6125 covers this stuff in gory detail (although not specifically for SIP, although the specs about SIP cert handling might be updated someday to track RFC 6125).
http://datatracker.ietf.org/doc/rfc6125/
Peter
- -- Peter Saint-Andre https://stpeter.im/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 24/06/13 21:01, Peter Saint-Andre wrote:
On 6/24/13 2:33 AM, Olle E. Johansson wrote:
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.
RFC 6125 covers this stuff in gory detail (although not specifically for SIP, although the specs about SIP cert handling might be updated someday to track RFC 6125).
This extends it for SIP (it is based on RFC 5741 which is the ancestor of RFC 6125):
http://datatracker.ietf.org/doc/rfc5922/
On 21/06/13 17:41, Olle E. Johansson wrote:
21 jun 2013 kl. 15:05 skrev Daniel Pocock 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?
It is a relative level of trust (there is no 100% trust)
If the cert is signed by your private root CA you may trust it more than the DNSSEC trust anchor from ICANN.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
Thanks for the feedback. I've resolved a couple of issues on my snag list:
* My config now enforces TLS properly. I had to work around this unfixed bug though:
http://lists.kamailio.org/pipermail/sr-users/2012-November/075642.html
I've reported it again via the Kamailio email list.
* Inter domain/proxy presence now works as a result of fixing the above also.
* Mutual TLS. I think this should happen for proxy <--> proxy but isn't worth it for the client authing to the server. My current set-up only requires an end user to enter a username and password. Jitsi pulls the TLS config and proxy configuration automatically from SRV records. My experience of supporting people with SIP soft clients is that anything more complex than this fails miserably. At least without lots of technical support.
looking forward to your feedback. My updated config is located at the same URL.
If you can supply me with an account on a repro proxy I will do some testing and report back.
Thanks.
Cheers, John