Authentication: Man-In-The-Middle Vulnerability
xloem opened this issue · 2 comments
I create this issue to represent the call authentication security concerns written up at https://crysp.uwaterloo.ca/opinion/wire/ .
When securing a conversation, confidentiality (hiding the contents of the conversation) is not the only desirable property. Without also authenticating the conversation, an attacker located in the network (e.g., a malicious actor intercepting traffic on a user's LAN, or a compromised ISP) can insert themselves between the endpoints. Wire provides both properties for text-based conversations.
The Wire protocol uses SRTP to secure audio/video calls. SRTP requires an external mechanism to establish the initial cryptographic key to protect the data. Wire uses a DTLS handshake to establish this initial key. DTLS is a UDP-based analog of TLS (used to secure HTTPS web browsing). Consequently, the key exchange in a DTLS handshake needs to be authenticated by a certificate authority, as in the case of web certificates. Based on some quick packet captures, it appears that the certificates used by Wire for this DTLS handshake are self-signed. If this is truly the case, then the handshakes do not provide any authentication in the presence of an active network attacker (i.e., a network attacker that can modify traffic), making Wire audio/video calls vulnerable to man-in-the-middle attacks.
The Wire security whitepaper says that "the authenticity of the clients is also verified during the handshake", but this is not consistent with the use of self-signed DTLS certificates. If the certificates are authenticated by the central Wire servers, then this prevents call interception by anyone except for the Wire operators.
In either case, the use of DTLS here is highly unusual and the security it provides is sub-optimal. A better approach would be to use a protocol like ZRTP (the standard used by Signal, Jitsi, Linphone, and others) to establish the initial SRTP key, or perhaps a more advanced key exchange scheme. The authentication for this scheme should not be based on certificates (as in DTLS); instead, the authentication should be bound to the long-term keys that are used by Wire's text-based conversations. A very simple solution would be to transparently perform a well-known unauthenticated key exchange (e.g., Diffie-Hellman) over an authenticated Wire text conversation, and to use the resulting key to initiate SRTP for the audio/video call.
The Wire security whitepaper mentions that authenticating audio/video calls against the cryptographic identities used for the text messaging protocol is future work, so this issue appears to be known.
Hello, this is also something that will be addressed with the next version of calling. Please stay tuned.
Sorry for the late reply. This issue has been addressed with the introduction of our new signalling protocol as described in this blog post: https://medium.com/@wireapp/the-road-to-a-more-private-and-secure-calling-protocol-a8f22d23f112