Twilio now allows TLS & SRTP connections with their Elastic SIP Trunking. However, there are some issues with the way they've done it that prevent Asterisk from being able to verify their server's certificate.
First of all, their documentation
tells you to download the Thawte Primary Root CA,
when the certificate I saw was signed with the
Thawte Premium Server CA instead.
This caused me to get ERROR[...] tcptls.c: Certificate did not verify: self signed certificate in certificate chain
.
Downloading the Premium Server CA fixed the self signed issue, but then I started getting ERROR[...] tcptls.c: Certificate common name did not match (myhost.pstn.us1.twilio.com)
. Eventually, I figured out that Twilio is using a wildcard certificate for *.pstn.us1.twilio.com
, but RFC 5922 section 7.2 specifically states that implementations MUST NOT accept wildcard certificates. Asterisk follows the RFC and will not accept the wildcard match.
Since setting tlsdontverifyserver=yes
as
Twilio's Asterisk Elastic SIP Trunking Interconnection Guide using Secure Trunking
directs causes you to miss out on much of the benefit of TLS, I wanted to fix this.
I can't fix Twilio's certificate, so I patched Asterisk to allow it.
This patch allows any certificate for .twilio.com
to match any hostname ending with .twilio.com
.
Other domains are not affected. I didn't bother with true wildcard support, since it's against the RFC.
The patch is for Asterisk 13.5.0, although it shouldn't be hard to port to other versions.
After applying the patch and recompiling Asterisk, you can follow
Twilio's Asterisk Guide,
but make sure tlscafile
or tlscapath
points to the
Thawte Premium Server CA.
Then you can set tlsdontverifyserver=no
and get actual secure trunking from Asterisk to Twilio.
It doesn't appear that Twilio verifies Asterisk's certificate, so origination from Twilio to Asterisk is still vulnerable to an active MITM.
Here is my attempt at porting the patch to 15.3.0.