Messenger was not forced to wiretap but…

By david drexler – Flickr, CC BY 2.0, Link

 

Back in August, Reuters reported on a “secret legal fight” between the FBI and Facebook about wiretapping Messenger calls. The Verge as they found our old post about reverse-engineering Messenger from 2015 and had a number of follow-up questions on it for a Messenger wiretapping article they ran. Technical details on the case are quite hard to find so I was not able to dig deeper into the specifics around wiretapping.

Reuters now reports that Facebook will not be forced to wiretap Messenger calls with the FBI noting:

currently, there is no practical method available by which law enforcement can monitor

This is great news for privacy concerned users, but my previous review still left me concerned. I decided to take a new look at my analysis – what I still found is troubling and quite frankly surprising given Facebook’s resistance to wiretapping.

Messenger and WebRTC

We looked at Messenger and its use of WebRTC back in 2015 as part of our Blackbox Exploration series. It was using the webrtc.org library open-sourced by Google with a number of modifications. It also used the SDES mechanism for encrypting calls between the apps. A short summary of the implications for wiretapping is given below.

The post ended with paragraph:

The widely known downside of that is that the encryption keys are sent via the signaling servers and can be used to retroactively decrypt traffic. Government agencies will surely rejoice at the news of this being applicable to 10% of the mobile VoIP traffic

SDES vs DTLS-SRTP and Wiretapping

The WebRTC specifications say explicitly that WebRTC MUST NOT implement SDES. The technical arguments for why this is have not changed much since Eric Rescorla’s IETF presentation from 2013.

Back then, there were two contenders for the key exchange in WebRTC: SDES and DTLS-SRTP. SDES basically means that the key used for encrypting the VoIP traffic is sent in plain via the signaling servers. From a cryptographers point of view SDES also means that an attacker on the signaling path can silently listen to the key exchange and then capture the packets without being detectable.

DTLS-SRTP is better in many regard. It uses a TLS handshake to generate the keying material, meaning the signaling server does not have access to the keying material. Wiretapping a call is only possible by having the signaling server perform an active man-in-the-middle attack. This is detectable and more effort than simply logging the SDES key.

The downside to DTLS-SRTP from a pure technical perspective is increased performance requirements. However, the availability of ECDSA certificates which are fast to generate even on mobile devices only increased the argument further in favor of DTLS-SRTP.  This is speculating, but back in 2015 Facebook may have been concerned with mobile performance and went with the MUST NOT SDES mechanism on mobile while using DTLS-SRTP in the browser for compatibility.  They were not necessarily unique among early WebRTC adopters in holding onto their SDES implementations –  Google Hangouts did the same.

Facebook Messenger likes WebRTC, 2018 edition

I was not able to take another look at Messenger before answering the questions from The Verge’s Russell Brandom back in August. Chad and I got around to doing this this past weekend.

We looked at both in the browser as well as between two Messenger mobile clients. For the first call, I used Chrome so chrome://webrtc-internals was helpful as usual. The offer from Chad’s Android looked fine, no signs of an a=crypto  line that would indicate SDES usage:

So DTLS-SRTP must be used which is good. It is also pretty interesting to see the old RTP-based DataChannels in the offer — this doesn’t interoperate with the browser unfortunately so we can’t easily sniff what is going on there.

However, taking a look at the signaling using the network console showed that the a=crypto line from SDES was still there:

And mind you, if I can see it in the network console, so can the Facebook servers. If you want to look yourself, the request containing the offer SDP is much larger than the others which helps finding them. The full offer can found here.

This is rather odd – it looks like the JavaScript code removes the a=crypto line before passing it to the WebRTC API since Google changed the fallback behaviour when both the DTLS-SRTP a=fingerprint  and the SDES a=crypto  line are present back in December 2017. This now throws an error

Thank you Google for making it more inconvenient to use SDES! Now if you could rip out SDES from Chrome entirely… (please star this bug to indicate your support!)

This did not bode well. We repeated the experiment using the Messenger app on iOS and Android and did not find any sign of a DTLS handshake either.

We took a Wireshark dump from the call and looked at the result, filtering all UDP traffic:

What we do not see here is a DTLS client hello that indicates the start of a DTLS session. We just see a couple of STUN messages and then immediately RTP packets. Together with the SDP we have from the app calling the browser this suggests that SDES is used.

Conclusions

With respect to the lawsuit, I have many questions. Did Facebook have the actual call data, i.e. the RTP packets? Probably not since 1:1 calls are using a peer-to-peer connection most of the time. Which might have been why the Reuters article says you “only play a small technical role”.

Law enforcement might have had access to those packets from other parties though, such as capturing them at the cell tower. With SDES, this could have been matched up with the keying data Facebook had. Facebook could also have been asked to relay the call through one of their TURN relay servers, which happens in normal circumstances for part of their calls anyway, which would have made wiretapping there possible.

But Facebook maintained it could not be ordered to alter its software or hack its user in order to help the FBI. From a privacy point of view that is good news, the implications for many other WebRTC or VoIP applications would have been tremendous.

On the technical side, It is quite disappointing to see SDES still in use between the Messenger apps. The IETF decided to make SDES a MUST NOT for WebRTC back in 2013. Even without end-to-end encryption of messages, using DTLS-SRTP would greatly increase the effort required to wiretap. This would also prevent retroactive decryption. Products like Google Duo have proven that you can have a fast call setup using DTLS-SRTP (see the KrankyGeek talk we had on this).

DTLS-SRTP is already supported in the Messenger application as well so it is really just a matter of turning off the old stuff.

Dear Messenger folks: please stop using SDES.

{“author”: “Philipp Hancke“}