How to intercept all Wire voice and video calls
Wire advertises itself as a private messaging and calling app. In their announcements, they claim things like:
Wire’s voice calls have always been end-to-end encrypted. Today, we expand this to include all conversation content — text messages, video calls, photos, sketches. It is all now encrypted end-to-end, which means it is private and secure.
According to Wire, their voice and video calls have been “end-to-end encrypted” since 2014. These would be wonderful claims, if true, but in this post I will show how it is possible for Wire, most governments, and many employers to intercept Wire voice and video calls. They are not end-to-end encrypted, and have not been since 2014.
The technology
It’s nice that some of Wire’s software is open source, but the source is extremely messy, spread out, and hard to read, which makes it difficult to do any kind of reasonable auditing. I doubt anyone has looked at it closely, because it is almost impossible to look at.
With a lot of digging, you can eventually find the code responsible for calling. Wire voice and video is transmitted over SRTP, which is a symmetrically encrypted version of RTP.
The SRTP key is critically important for Wire voice/video security, because anyone with the SRTP key can decrypt all Wire voice and video traffic.
Wire’s audio/video module negotiates the SRTP key over a DTLS channel between the calling device and the device receiving the call. DTLS is SSL/TLS, but over a UDP connection rather than a TCP connection.
Any TLS connection (DTLS included), requires the proper use of certificates, otherwise anyone can “man-in-the-middle” the connection. If someone could MITM Wire’s DTLS connection, they could get the SRTP key, and intercept all of Wire’s voice/video traffic.
The problem
Unlike apps that are built with security in mind, communication from Wire to Wire’s server uses basic TLS, and those connections use CA certificates with no certificate pinning. These are connections that almost all governments and many employers have the ability to intercept. You can see the CA certificates on their server here: https://prod-nginz-https.wire.com and the calling code with no certificate pinning here.
When Wire places a call, the client makes one of these normal TLS connections to the server and tells the server who the client wants to call. As part of that process, the client communicates in plaintext to the server the fingerprint of the DTLS certificate it is going to use in its SDP payload, which looks like this (highlighted in bold below).
That’s right, in plaintext, not end-to-end encrypted:
v=0
o=bob 16833 0 IN IP4 0.0.0.0
s=
t=0 0
a=ice-ufrag:c300d85b
a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2
a=fingerprint:sha-1 99:41:49:83:4a:97:0e:1f:ef:6d:f7:c9:c7:70:9d:1f:66:79:a8:07
m=audio 49203 RTP/AVP 109
c= IN IP4 98.248.92.77
a=rtpmap:109 opus/48000
a=ptime:20
a=sendrecv
a=candidate:0 1 UDP 2113667327 192.168.1.7 49203 typ host
a=ccandidate:1 1 UDP 1694302207 98.248.92.77 49203 typ srflx raddr 192.168.1.7 rport 49203
a=candidate:0 2 UDP 2113667326 192.168.1.7 60065 typ host
a=candidate:1 2 UDP 1694302206 98.248.92.77 60065 typ srflx raddr 192.168.1.7 rport 60065
m=video 63130 RTP/SAVP 120
c= IN IP4 98.248.92.771
a=rtpmap:120 VP8/90000
a=sendrecv
a=candidate:0 1 UDP 2113667327 192.168.1.7 63130 typ host
a=candidate:1 1 UDP 1694302207 98.248.92.77 63130 typ srflx raddr 192.168.1.7 rport 63130
a=candidate:0 2 UDP 2113667326 192.168.1.7 56607 typ host
a=candidate:1 2 UDP 1694302206 98.248.92.77 56607 typ srflx raddr 192.168.1.7 rport 56607That is the only thing which secures the DTLS connection used to negotiate the SRTP key. Even though Wire advertises “full end-to-end encryption,” the only thing securing the connection against MITM is transmitted in plaintext over a normal TLS connection secured with a CA certificate.
Anyone who can modify that value can intercept all Wire voice and video calls, and the participants would never be alerted or have any way of knowing. A full, invisible, MITM, which has been available to governments, employers, Wire, or anyone that hacks Wire since 2014.
If you have to trust the service, it’s not end-to-end encrypted
The worst part is that this isn’t a bug, it’s an architectural decision. Wire knows that these calls aren’t really protected end-to-end, but keeps advertising that they are even though they can be intercepted with simple, publicly available tools.
One main tenant of end-to-end encryption is that you don’t have to trust the server or anyone who compromises the server, because the server doesn’t have access to the content. In this case, the server is completely trusted.
Wire makes a big deal about being a “Swiss” company, which might make us feel better about this level of trust in their servers. After all, it means the server is safe in Switzerland, right?
$ host prod-nginz-https.wire.com
prod-nginz-https.wire.com has address 46.137.80.25
prod-nginz-https.wire.com has address 46.137.190.107
prod-nginz-https.wire.com has address 46.137.189.237$ host 46.137.80.25
25.80.137.46.in-addr.arpa domain name pointer ec2-46-137-80-25.eu-west-1.compute.amazonaws.com.$ whois 46.137.80.25inetnum: 46.137.0.0 - 46.137.127.255
netname: AMAZON-EU-AWS
descr: Amazon Web Services, Elastic Compute Cloud, EC2, EU
remarks: The activity you have detected originates from a
dynamic hosting environment.
For fastest response, please submit abuse reports at
http://aws-portal.amazon.com/gp/aws/html-forms-controller/contactus/AWSAbuse
For more information regarding EC2 see:
http://ec2.amazonaws.com/
All reports MUST include:
* src IP
* dest IP (your IP)
* dest port
* Accurate date/timestamp and timezone of activity
* Intensity/frequency (short log extracts)
* Your contact details (phone and email)
Without these we will be unable to
identify the correct owner of the IP address at that
point in time.
country: IE
admin-c: ADSI2-RIPE
tech-c: AENO1-RIPE
tech-c: AEA61-RIPE
status: ASSIGNED PA
mnt-by: MNT-ADSI
mnt-domains: MNT-ADSI
created: 2010-12-02T15:38:53Z
last-modified: 2010-12-02T15:38:53Z
source: RIPErole: Amazon Data Services Ireland Technical Role Account
address: Amazon Data Services Ireland
address: Digital Depot
address: Thomas Street
address: Dublin 8
address: Ireland
mnt-by: MNT-ADSI
admin-c: MA11338-RIPE
tech-c: AA25560-RIPE
nic-hdl: ADSI2-RIPE
created: 2006-03-06T15:06:13Z
last-modified: 2013-08-29T01:03:24Z
source: RIPE # Filtered
The Wire servers are owned and operated by Amazon, a US company, located in the Ireland.
What Wire should do
Wire should either immediately end-to-end encrypt their calls by using end-to-end encryption for their SDP offer, or stop advertising end-to-end encryption. One way or the other, they should also notify their users that their calls have been vulnerable to interception since 2014.
Even if they do fix this, though, they’ve knowingly been operating a service that can easily be intercepted by most governments, many employers, Wire, or anyone who compromises Wire servers (operated by a US company in Ireland) while advertising it as “end-to-end encryption” since 2014. It will be hard to ever trust the rest of their claims.
Wire should also stop advertising or implying that user data is safe in Switzerland.
