[asterisk-dev] Notes from setting up SIP+TLS/RTP+DTLS

[Ben Klang]

> Il giorno Nov 10, 2014, alle ore 1:15 AM, Joshua Colp <jcolp at digium.com> ha scritto:
> 
> Ben Klang wrote:
>> Tonight I finally got Asterisk 13 working with chan_pjsip and SIP+TLS
>> and RTP+DTLS. It’s 12:45am so I won’t spend a lot of time on this now,
>> but I wanted to share the notes I took while setting this up as I feel
>> the documentation is pretty lacking in this area.
>> 
>> 
>> *media_encryption is not well documented in pjsip.conf*
>> * In my case, it needed to be set to “dtls”, but I think that some
>> endpoints may need “srtp"
> 
> For traditional SIP endpoints the common would be SDES. This exchanges the keys in the SDP. WebRTC requires DTLS which negotiates the keys using DTLS.
> 
>> * my first-guess setting of “yes” results in a cryptic/unhelpful error
>> on the console, and the syntax error caused the entire endpoint to be
>> un-useable
> 
> An invalid configuration (such as setting yes there) is considered fatal currently.
> 
>> * dtls vs.srtp is not mentioned at all (as far asI could find) in either
>> the Asterisk Wiki nor the configs/sample/pjsip.conf
> 
> DTLS is SRTP, as is SDES. Just a difference in how keys are exchanged.
> 

Ugh. That's what I get sending emails too quickly. Everywhere in this email that I wrote "srtp" I meant "sdes". 


>> * The default is “no” - I had thought that SRTP and DTLS were not
>> mutually exclusive - are they? If not, can we set a default that permits
>> them to be used if requested by the endpoint?
> 
> In practice you can't really have them both. The problem comes in outgoing calls. How do you offer both SDES and DTLS? A DTLS stream with crypto attribute? It's rather undefined in the real world of what behavior things will have. From my experience and talking to others it generally won't work.
> 
>> 
>> *Configuring certificates*
>> There is no mention of the fact that endpoints need DTLS certificates
>> configured at all on endpoints in the Asterisk Wiki.
>> The Asterisk Wiki covers setting up TLS on the transport, and that
>> mostly worked on the first go *except* that the config key is
>> erroneously referenced as “privkey_file” (missing an underscore). I made
>> a comment on the Wiki so someone can correct this, but it appears to
>> have been included in sample config files for some time, so the bad info
>> is out there: https://duckduckgo.com/?q=asterisk+%22privkey_file%22
>> <https://duckduckgo.com/?q=asterisk+"privkey_file">
>> Also, it might be worth mentioning that TLS runs over TCP, not UDP, as I
>> had that wrong in my firewall on the first attempt.
>> 
>> Setting certificates has to be done at least twice (transport + endpoint)
>> * There is no automatic setting of the DTLS CA/Cert/Privkey from the
>> SIP+TLS configuration for the transport. I know this would potentially
>> be difficult if multiple transports were set with different TLS keys,
>> but still…this is non-obvious.
> 
> Correct, media transport and signaling transport are completely separate.
> 
>> * Can we somehow default the endpoint’s CA/Cert/Privkey to that of the
>> transport? If not, can we somehow associate the endpoint with the
>> transport so it doesn’t have to be configured twice?
> 
> Not... really. At least, not easily. Transports generally aren't selected until a message is sent.
> 
>> The pjsip configuration keys are subtly different for SIP+TLS on the
>> transport vs. RTP+DTLS on the endpoint. Examples:
>> 
>> cert_file =X ; transport
>> dtls_cert_file = X ; endpoint
>> ; dtls_ prefix, weird but ok - srtp doesn’t appear to have a
>> corresponding setting, so do we even need the prefix?

sdes again here. 

Since SDES negotiates SRTP, it also uses certificates, right? I didn't notice any srtp_ prefixed confit options. Does it use the dtls_ prefixed ones?

>> 
>> priv_key_file = X ; transport
>> dtls_private_key = X ; endpoint
>> ; priv_key_file vs. private_key?
>> 
>> ca_list_file =X ; transport
>> dtls_ca_file = X ; endpoint
>> ; _list or not?
>> 
>> I’m not familiar with Sorcery. I know that Asterisk 13 is out meaning
>> these config settings are set in stone for the next couple of years. But
>> could we create aliases that were more consistent, just to preserve some
>> peoples’ hair?
> 
> Maybe. All of the DTLS configuration occurs in common logic across the code base. Provided it's fed what is expected then it's happy.
> 
> It sounds like overall we just need better documentation of this.
> 
> Cheers,
> 
> -- 
> Joshua Colp
> Digium, Inc. | Senior Software Developer
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
> Check us out at: www.digium.com & www.asterisk.org
> 
> -- 
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>  http://lists.digium.com/mailman/listinfo/asterisk-dev