Re: [Kamailio-Users] about kamailio and tls

Hi Mustafa! mustafa samara wrote: Yes, this should be no problem. Just configure TLS support in kamailio (I suggest to use kamailio 1.5). For testing with pjsip you can either use pjsua client (included in pjsip), or you could also use QjSimple (http://www.ipcom.at/index.php?id=560) which is a prototype SIP client based on pjsip with support for TLS and SRTP. First you have to differ between signaling and media transport. Signaling uses SIP, media transport uses (at least for audio and video) RTP. For both protocols exists mechanisms to encrypt the payload. If you want to encrypt SIP, you can use SIP over TLS, thus the SIP signaling is encrypted. If you want to encrypt the media transport you use SRTP. With SRTP only the media payload itself is encrypted. There are a few differences between SIP and RTP encryption. When using SIP over TLS - the whole SIP signaling is encrypted - but only between the hops which use TLS as transport. For example if a client (caller) sends the SIP message with UDP to the proxy, and the proxy forwards the SIP message to another client (callee) over TLS, only the part between proxy and the callee is encrypted. When using SRTP, not the whole message, but only the media payload is encrypted. The RTP headers are still sent in clear text. Usually the encryption is end-to-end between caller and callee. Now, as you see, SIP and RTP a rather independent. You can use SIP over TLS and RTP, you can use SIP over UDP and SRTP, or you can use SIP over TLS and SRTP. Thus, from a technical point of view you can encrypt signaling, media, or both. For SRTP, both parties need to know a shared secret - the encryption key. There are several methods for SRTP key exchange (google for: srtp sdes mikey dtls). Currently the most used SRTP key exchange is "SDES" (RFC 4568). With SDES, the encryption key is exchanged in the session description (SDP) - similar to codec negotiation. When using SDES, the encryption is in plain text in the SDP. Thus, sending SIP over unencrypted transports but using SRTP is rather nonsense, as the attacker can get the key from the unencrypted SDP and decrypt the SRTP packet. Thus, when using SDES, some SIP clients (e.g. pjsip) give you the configuration option to use SRTP (with SDES) only if the SIP signaling is sent over encrypted transport (TLS). Finally the difference between TLS and SIPS: TLS can be used as transport (just like UDP or TCP) between any hops. When addressing a target with a sip: URI, the SIP nodes can use any of these protocols the send the SIP message. When addressing a target with a sips: URI, the standard requires that the message is sent from sender to receiver over encrypted transport. As a practical result: A message to a sip: URI can use any transport (UDP,TCP,TLS) whereas a mesage to a sips: URI must use encrypted transport on every hop (TLS). regards Klaus - the RTP header is still in plain text (this is different to