Understanding DTLS Usage in VoIP Communications

• Introduction

• TL;DR

• Twilio Platform

  • Preparing Custom Setup

  • Traffic Interception and Analysis

    • Information Gathering

    • DTLS Demultiplexing

    • Intercepting Traffic to chunderm.gll.twilio.com

    • Signalling Traffic

    • Intercepting DTLS-SRTP

    • Terminating DTLS with SRTP Extension

    • Putting It All Together

    • Spoofing DTLS Certificate Fingerprint

  • Conclusion

• Wire

  • Setup

  • Traffic Analysis

  • TLS Certificates Validation

  • Media Flow Analysis

  • Conclusion

Introduction

When working on a mobile application security assessment we noted an unusual traffic flow. This was a DTLS handshake coming from a remote server to the mobile application listener. As we always pay close attention to transport security implementation in the applications we test, we were about to verify if certificates are properly validated in the observed case. However, it was not that simple.

The desire to test client-side TLS certificates validation led us to: development of custom tools, interception and digging through various types of network traffic, reading through RFC documents and even patching of binary files. Now we understand that we were facing DTLS handshake initiated to derive keys to secure media communications between parties, following WebRTC recommendations.

In this article we describe what we did, how we did that and what obstacles we had to overcome. This exercise helped us to formulate a methodology to test some aspects of WebRTC-capable applications from a security standpoint.

TL;DR

For readers who want a short summary of this article we suggest to jump to the conclusion section. In this case the most valuable part is the description itself as it provides a methodology applicable to similar cases. We also developed some tools which helped us during this assessment. However, they can only be applied to perform similar exercises and quite useless as a standalone software.

Twilio Platform

Preparing Custom Setup

We noted that the application we were initially testing uses Twilio platform to make voice calls. The Android build uses Twilio's Java module and corresponding native library. In order to avoid hitting our customer's infrastructure while performing our tests we decided to deploy our own solution. This way we can minimise the study surface and have full control over the software behaviour.

Twilio has great introductory articles: getting started for voice applications, getting started with Android client. They also allow to create a trial account for ~€10 which one can use to make voice calls between test applications. After completing "Getting started" guides your Twilio account will be properly configured, various tokens created, Google Firebase messaging configured. You will also have a working Android mobile application, a web server to route calls and to feed Twilio with your tokens. Same way you can get an iOS application, but in this article we will cover Android only.

Note that we were not assessing the whole Twilio solution, we were just interested in voice calls implementation. In that particular case it was enough to get an example Android application configured to use in our setup and install it on two devices. We used the suggested Android quickstart example with the following minor updates:

• TWILIO_ACCESS_TOKEN_SERVER_URL pointed to our web server (which was based on another example.
• identy string was set to different values on each device we used for testing;
• app/google-services.json file was updated after integration with Google Firebase service;
• we enabled debug logging by adding Voice.setLogLevel(LogLevel.DEBUG); call to onCreate() method of app/src/main/java/com/twilio/voice/quickstart/VoiceActivity.java file.

As we had two mobile applications able to setup voice calls between each other, we started to investigate the network communications they produce.

Traffic Interception and Analysis

Information Gathering

We configured one of the test devices to be connected via WiFi access point setup on our test laptop. This way we observed all communications made by Twilio example application when issuing a phone call.

The application was contacting the following domains:

• eventgw.twilio.com
• ers.twilio.com
• our test web server holding Twilio tokens
• global.stun.twilio.com
• chunderm.gll.twilio.com

We noted that traffic towards eventgw.twilio.com, ers.twilio.com and access tokens server follows Android proxy rules. Thus, we observed the corresponding communication using our Burp proxy instance. Its certificate authority was installed on our test device in advance.

ers.twilio.com was accessed using HTTPS to check and update Twilio registration token. The application informed Twilio about events happening on the device by sending HTTPS POST requests to ers.twilio.com server. There was no interesting data in these communication channels.

TLS-protected packets were exchanged with chunderm.gll.twilio.com server over TCP/443. This communication ignored global proxy settings.

Then the application sent STUN binding request to global.stun.twilio.com over UDP/3478.

After more exchanges with chunderm.gll.twilio.com the application started UDP STUN communication with a server in 3.122.181.0/24 subnet (approximately). The server IP address and port were different each time we started a call. After STUN registration and binding requests **in the same channel** the application received **incoming** DTLS Client Hello message. You can see this on the following screenshot from Wireshark capture:

DTLS handshake was quickly established, no data packets were sent and traffic with RTP data continued to flow in the very same UDP channel.

Our objective was to verify the proper validation of the server's certificate by the client side (Twilio server in this case). In this scenario the role of the server was played by our mobile client.

Searching the Internet with traces we already collected revealed that what we observed is DTLS-SRTP protocol, defined in RFC5734. The idea here is to use DTLS protocol to derive key material to secure RTP data. DTLS is already defined and implemented, it authorises the remote party and secures sensitive data. When using key exchange algorithms based on elliptic curves, it works fast even on low powered devices. The corresponding packet exchange is described in RFC5764 as follows:

The SRTP keys are derived with help of a specific DTLS protocol "use_srtp" extension. The details here are not important to us, except that these keys stay inside DTLS library implementation and not transferred as Application Data. For this reason we will need a specific software to terminate such connections.

The security outcome here is that if DTLS certificates are not properly verified then a suitably positioned network-based attacker can obtain keys for encrypted media traffic.

The important remaining question is how such certificates can be verified? There is no particular "domain name" here. The client needs to rely on something else that we do not see yet. RFC5764 mentions this in the following passage:

Obscure, as it often happens with such documents. But it gives us a hint that we have to look into other channels. And we have such a candidate: chunderm.gll.twilio.com. Nevertheless, we have to redirect DTLS handshake to our DTLS server keeping other protocols untouched. Let's solve this problem first.

DTLS Demultiplexing

From our observations and RFC5764 specification, DTLS-SRTP traffic is a mix of STUN, DTLS and RTP protocols, all in the same UDP channel. Thus, we can not just forward this traffic to some listener and handle only DTLS packets. This will break the application logic.

We need a proxy tool which normally just redirects traffic between two endpoints. When it catches DTLS packets it forwards them to our fake listener. The responses have to be delivered back to their intended destination. Thus, the remote side and the mobile application will exchange STUN and RTP packets as usual but DTLS channel will be handled by us.

Determining the packet type is simple, it is described in RFC5764:

The following describes the traffic flows our proxy has to handle:

This was implemented in quick-and-dirty style using Go and can be grabbed from this repo.

This proxy requires the following parameters:

• Socket to listen on. This can be anything, we just redirect traffic to it using firewall.
• Fake DTLS server address. We fully control this parameter.
• Original destination. Well, here we have a problem. In our case it is different each time, so we have to figure out this parameter in runtime. This is covered in the next section.

Intercepting Traffic to chunderm.gll.twilio.com

From prior observations it became clear that essential information is transmitted inside TLS-protected data with chunderm.gll.twilio.com server (port 443). Unfortunately for us, the application properly verified TLS certificates. We were not able to bypass it with Xposed modules or Frida with objection framework.

The application uses libtwilio_voice_android_so.so native library which includes (but not linked to) resiprocate and boringssl sources. Thus, we can not just handle calls with Frida. In this situation we had to go the binary patching way.

We used Ghidra project for decompiling and patching. Binary patching is not well supported by Ghidra (yet?) but it is possible to overcome it with SavePatch external script.

We patched calls (five in total) to SSL_CTX_set_verify function (address 0x0026786c) which sets certificate verification mode in its second argument. To avoid verification this parameter has to be zero. You can see this in the following illustrations.

SSL_CTX_set_verify, the entry #1, original:

SSL_CTX_set_verify, the entry #1, patched

SSL_CTX_set_verify, the entry #2, original

SSL_CTX_set_verify, the entry #2, patched

SSL_CTX_set_verify, the entry #3, original

SSL_CTX_set_verify, the entry #3, patched

SSL_CTX_set_verify, the entry #4, original

SSL_CTX_set_verify, the entry #4, patched

SSL_CTX_set_verify, the entry #5, original

SSL_CTX_set_verify, the entry #5, patched

SSL_CTX_set_verify (offset 0x0016163c) also sets a callback which always has to return 1 as a result of successful verification.

Verification callback, original:

Verification callback, patched:

Even if verification succeeds, the library validates if domain name matches the expected one.

Common name verification, decompiled:

Common name verification, source code:

Common name verification, patched:

Common name verification, patched, decompiled:

On top of that, the library checks if common name ends with .twilio.com. It is of course an addition made to the resiprocate library. We left it untouched and just took this behaviour into account when configuring intercepting proxies.

Parent domain validation:

The final difference between the original file and the patched version:

This was still not enough. The library limits the list of trusted certificate authorities to the following list:

To overcome this we created our own CA which, when formatted as PEM, matches the length of one of the listed above.

We updated Amazon's root CA:

Our certificate:

We used organization field to make certificates sizes match. Then we just replaced one PEM string with another in the binary.

Uploading the patched library to the mobile device:

Altering the existing library on the device (as superuser):

With such alterations we were able to intercept the data transmitted between the mobile client and chunderm.gll.twilio.com.

Signalling Traffic

We are about to intercept the traffic flow between our test mobile application and chunderm.gll.twilio.com host. As chunderm.gll.twilio.com is load-balanced and deployed on Amazon services, it is better to fix its IP address to a single one. The easiest way to do this is to add the corresponding entry to /etc/hosts and to verify that the test device is using this configuration:

Traffic redirection can be configured with iptables:

When using DNAT to localhost do not forget to enable local routing:

The traffic we want to intercept is not a HTTPS one (as we quickly learned by trying to forward it to Burp proxy). Thus, we used a general-purpose proxy tool, viproxy. We used it like this:

Certificate chunderm.gll.twilio.com.crt was generated specifically for this purpose and signed by CA that we previously added to the libtwilio_voice_android_so.so library. Common name in this certificate was set to chunderm.gll.twilio.com. Thus, the application trusted our proxy and we were finally able to get the traffic in clear-text.

The traffic that we observed contained SIP signaling. It was used to indicate initiated calls to the remote party, receive notifications regarding call status and negotiate media channels parameters. Exactly for this purpose the Twilio voice native library includes resiprocate source code. Let's briefly analyse the intercepted SIP messages.

Client (our test mobile app) sent the following SIP INVITE message:

Note the fingerprint parameter: sha-256 1B:EA:BF:33:B8:11:26:6D:91:AD:1B:A0:16:FD:5D:60:59:33:F7:46:A3:BA:99:2A:1D:04:99:A6:F2:C6:2D:43.

The server replied with the following:

Note the parameters c=IN IP4 3.122.181.240 and m=audio 17612 RTP/SAVPF 111 0 126. This sets DTLS-SRTP remote endpoint to 3.122.181.240:17612.

There is another fingerprint parameter in server's reply: sha-256 33:4E:FE:3C:76:F2:04:B4:18:FC:95:85:56:3C:1C:A7:B0:87:39:15:3D:07:42:45:85:40:6C:2C:77:A9:80:76.

If we look into the corresponding traffic capture we will see the UDP channel established between our application and 3.122.181.240:17612. The mobile app presented to the client the following certificate during DTLS handshake:

This is exactly the same fingerprint that client has sent in the SIP INVITE message, that was described earlier.

We saw that SIP signalling exchange with chunderm.gll.twilio.com negotiated DTLS certificates fingerprints. They can be used to validate the client. We can assume that client certificate can contain arbitrary information, it just has to have the fingerprint matching the one, that was transmitted in the signalling channel. However, this is a subject to verify.

Another parameter that was negotiated in this signalling channel is the remote endpoint to establish DTLS-SRTP channel:

In this case it is 3.122.181.240:17612.

This format for transferring media parameters is called Session Description Protocol (SDP). As we later learned, it is one of the recommended approaches for negotiating media channels in WebRTC. The SDP Anatomy article describes the most common parameters.

One important outcome is that the remote party in this case is Twilio server. This means that it has full control over voice communications and can (in theory) intercept the traffic, decrypt it, record it and even modify. This is what can be found on Twilio website regarding this link:

However, what we observed before could be just Twilio's "demo account" feature (as we used demo subscription). Indeed, Twilio server somehow has to insert "thank you for using Twilio demo account" voice message when making outgoing call.

Anyway, the idea of this exercise is to test resilience against man-in-the-middle attacker, not if Twilio servers sniff communications. Thus, the next step is to intercept DTLS-SRTP.

Intercepting DTLS-SRTP

Now we have our demultiplexing proxy tool ready and we know how to determine the remote endpoint it needs to connect to. We can automate it with "replace" scripts feature of viproxy tool. For that we launch it like this:

Where replace_run-stunproxy.rb contains the following:

We still need to forward DTLS-SRTP traffic from the mobile app to the intercepting proxy. This can be achieved with the following iptables command:

We are almost ready, the remaining step is to prepare DTLS server.

Terminating DTLS with SRTP Extension

As we learned from RFC5764, DTLS handshake in DTLS-SRTP protocol relies on use_srtp extension. Thus, we need a TLS library which supports it. We chose GnuTLS as it has a useful API and plenty of examples for many cases.

We used mini-dtls-srtp server as an example and combined it with the corresponding documentation. The source code is published as dtls-srtp-server.

DTLS server should present some certificate to the remote client. We assumed that there are no specific requirements for it (at the time of writing we did not have any evidences saying the opposite). Thus, we tried to make it close to the ones we observed with the validity period extended:

However, we noted that there is a requirement for private key used along with the certificate. It has to be generated with prime256v1 elliptic curve. This was a practical observation and the default curve used by GnuTLS.

For now we left the certificate and the corresponding private key hardcoded in our DTLS server. If we spot cases when client verifies certificate parameters other than fingerprint, we will add the corresponding test to our qsslcaudit tool.

Putting It All Together

As we have all the components ready, we can now test if Twilio server properly verifies client's DTLS certificate.

When our test application received the incoming voice call, our viproxy instance intercepted several SIP messages and determined remote DTLS-SRTP endpoint. Knowing its address, the proxy launched DTLS-SRTP multiplexing tool. This tool transparently forwarded all packets, except for DTLS. The latter was redirected to our DTLS server which terminated the connection.

Communications diagram:

Surprisingly our DTLS server returned negotiated SRTP keys:

Wireshark captured the following DTLS handshake:

As can be seen in the screenshot, there is no DTLS alert message. Did we successfully spoofed the client? (Un)fortunately, no: immediately after this handshake, the server sent SIP BYE message:

It is the same message that was sent during normal voice call termination, no explicit error message provided. From user experience point of view, the application just stops the call.

The corresponding error message in the application's debug log (over ADB) is not verbose at all:

Previously enabled debug logging did not help either. However, it produced quite a lot of output, including SIP signalling messages.

The "Call Error" is returned by the following hook in its Java source code:

We did not identify the exact source code responsible for handling the case that emits onConnectFailure() event.

In order to be confident that we did all things properly, we have to simulate the valid client's behaviour.

Spoofing DTLS Certificate Fingerprint

We configured our intercepting proxy to substitute mobile application's DTLS certificate fingerprint with the one that we use. This was accomplished by the following script for viproxy tool:

The corresponding viproxy commandline:

Having such setup, we intercepted network traffic. Now the mobile client did not display any errors and we observed SRTP traffic:

There is no DTLS handshake in this excerpt, as we intercepted it before it reached the mobile client.

This means that our setup was correct. Twilio server indeed verifies the mobile client's DTLS certificate fingerprint.

Our DTLS server negotiated the following SRTP keys:

We checked if we can decrypt the intercepted SRTP traffic with these keys. We tried to use ffmpeg project tools to avoid writing our own SRTP decrypt-assemble-play implementation.

Preparing the key in ffmpeg format:

Running ffmpeg:

We replayed SRTP traffic that was originally sent by server to our mobile application:

For some reason, ffplay did not produce any output or sound. However, it printed the following errors when we used the incorrect key:

This confirms that the keys we obtained can indeed be used to decrypt voice traffic.

Conclusion

With this exercise we learned a bit about DTLS-SRTP protocol (defined in RFC5764) and how it is used by Twilio platform for voice communications between Android mobile clients.

We were able to prepare the setup which allowed us to intercept various communication channels. The most important of them were the aforementioned DTLS-SRTP and SIP signalling channels. This required advanced usage of transparent TCP proxy to parse signalling data and development of following tools: DTLS server and SRTP-DTLS demultiplexor.

We confirmed that Twilio properly verifies the fingerprint of mobile client's DTLS certificate. Together with proper validation of SIP signalling channel security, this prevents man-in-the-middle attacks against voice communications.

The described activity encouraged us to test other products which use DTLS-SRTP protocol. This we describe in the next section.

Wire

After looking into Twilio platform described above, we decided to assess other applications which use DTLS-SRTP protocol. Our fist victim was Wire platform/application. This was a lucky choice as it was a pleasure to work with an open source client which is well designed and written in clean style.

When we initiated this assessment we began with tooling and approach developed when working on Twilio platform. However, it turned out that some alterations were required. As a result, the description you have read in the previous chapter was slightly rewritten to comply with the updated software.

Our objective is not to fully assess Wire application but to make our understanding of media communications better, improve testing approach and corresponding software. Thus, we focused on intercepting and analysing network traffic during phone calls, keeping the rest to other researchers.

Setup

The application was installed on two different Android devices from Google Play store. Two new accounts were created. For brevity, let's call one device and application app1 and another one app2.

The application's version at the moment was 3.46.890:

Traffic Analysis

We captured the traffic the application produces when making the phone call. To capture DNS requests we started the capture process before the application launch.

We used the following setup:

• app1 was running on the device with IP address 192.168.12.118
• app2 was running on another device having IP address 192.168.0.221
• the first device was connected to 192.168.0.0/24 network via test laptop, serving as a gateway, with IP address 192.168.12.1

If we exclude TLS-encrypted traffic, the application starts with STUN communications between two servers:

• turn04.de.prod.wire.com, 116.203.131.31:3478 (both UDP and TCP)
• turn03.de.prod.wire.com, 116.203.137.142:3478 (both UDP and TCP)

Both STUN channels were used to determine peer address in peer-to-peer setup (probably, for redundancy). In this case the negotiated peers were 192.168.0.221:55831 and 192.168.12.118:33880. The endpoints were negotiated in XOR-PEER-ADDRESS STUN attribute. Note that these are the IP address of app1 and app2. This allowed media traffic to be transmitted on the local network, without crossing the Internet.

After defining the peer channel, the applications establish DTLS-SRTP communication with each other over 192.168.0.221:55831 / 192.168.12.118:33880. In this channel, followed by several STUN messages, app2 starts DTLS handshake with app1:

Certificate presented by DTLS server:

We also noted that after initial handshake there were several data packets transmitted inside DTLS channel. Then SRTP flow starts with the first packet from app2:

When we initiated the similar call once more after relaunching the application, we noted that initial STUN communications were established with the same servers. The DTLS certificate presented by app1 was different:

TLS Certificates Validation

We performed client-side TLS implementation test using our qsslcaudit tool. We checked all communication channels that we noted:

• prod-nginz-https.wire.com
• prod-nginz-ssl.wire.com
• turn03.de.prod.wire.com
• turn04.de.prod.wire.com

The results were perfectly fine for prod-nginz-https.wire.com and prod-nginz-ssl.wire.com, see the following excerpt:

However, the client trusts any certificate when connecting to TURN servers:

It is a weird result, but we can not consider this as a security issue. The application transmits the same data simultaneously in plain text, using UDP and TCP channels. This communication channel is not used to transfer any sensitive data.

Media Flow Analysis

As was briefly mentioned previously, STUN protocol is used to negotiate peers. We have to parse the protocol in runtime and extract them. For this purpose we developed a stunpeersniff tool. This tool searches for XOR-PEER-ADDRESS attribute and launches UDP demultiplexor with the corresponding parameters. This UDP demux tool was described earlier: it searches for DTLS packets and forwards them to our DTLS server instance.

We forwarded STUN traffic, that was sent by app1, towards our TCP proxy with the following iptables command:

iptables command to forward DTLS-SRTP traffic to UDP demultiplexor:

STUN proxy command:

This setup intercepted the communications we need and forwarded DTLS handshake to our DTLS server.

DTLS server received Alert (Bad Certificate) DTLS error immediately after providing certificate. This confirms that the remote party (another mobile client in our case) validates DTLS certificate. It is a more robust behaviour than we observed with Twilio: DTLS handshake does not reach the point to derive SRTP encryption keys.

We noted that if we redirect DTLS handshake into nowhere, the call establishes successfully and both parties can talk. The captured traffic reveals that SRTP data is transmitted using a TURN channel. This traffic goes between the mobile application and remote TURN server. To decode it with Wireshark we followed this advice.

You can see the result in the following illustration:

We tried to identify how (_if_) DTLS handshake is now established. Apparently, the corresponding data is transmitted inside TURN channel in this case. You can see this in the following screenshot from Wireshark. The certificate presence is revealed by WebRTC common name string and expiration date 200418 encoded as a string:

This data exchange continues using TURN channel data messages:

Wire application is based on Wire signaling library in terms of media communications. This library uses Google's WebRTC reference implementation to handle the communications we observed.

WebRTC library implements a single module that handles DTLS handshake and fingerprint verification (p2p/base/dtlstransport.cc). The DTLS transport implementation does not depend on a particular communication channel and is fed with data by the rest of the library. This allows us to assume that the single DTLS validation test we performed earlier is enough to be sure that parties are properly verified in other cases too.

We also tried to figure out how signalling data is transmitted. WebRTC standard does not explicitly define how this should be implemented. According to src/econn/README.md file of the AVS Wire library source code, SDP data is sent as SETUP message via Backend. Backend in this case can be arbitrary communication channel. Mobile clients receive remote signalling via WebSockets protocol which transmits end-to-end encrypted messages. In upstream direction encrypted messages are sent as POST requests to prod-nginz-https.wire.com. WebSockets message example:

According to src/peerflow/peerflow.cpp source of AVS Wire library, some messages use WebRTC data channel. Data channel interface is defined in WebRTC's api/datachannelinterface.{hh,cc}. It is encapsulated in SCTP protocol which goes inside DTLS channel and which is transmitted over STUN/TURN messages.

Conclusion

Working with Wire allowed us to observe some WebRTC internals. Compared to Twilio platform, Wire uses vanilla WebRTC approach to establish peer-to-peer multimedia communications. Due to its open source nature we were able to check our observations against the implementation.

Overall security of media data transmitted by Wire mobile application follows WebRTC guidelines:

• RTP media data is secured as SRTP.
• Keys for SRTP are derived by DTLS handshake.
• DTLS handshake fails if peer fingerprint does not match the announced one.
• Peer fingerprint is transmitted as end-to-end encrypted data inside WebSocket, secured with TLS.
• Critical TLS servers certificates are properly validated by Android client.

In order to intercept Wire media traffic the same tools and firewall configuration is needed as with Twilio case. Additionally, we wrote a STUN sniffer tool stunpeersniff which is required to determine peers on the fly and configure DTLS-SRTP proxy accordingly.