Wire is fantastic and I hope they address this authentication issue soon. What is the value of verifying contact fingerprints if other communication stages are not verified?<p>I would like to see more disclosure on server retention of encrypted messages and documents, especially when:<p>(a) msgs/docs have been delivered to all devices<p>(b) msg / doc has been manually deleted by the sender<p>Twitter posts [1] suggest that encrypted msgs are retained on the server for weeks, even if already delivered. This creates an attack target. Wire has promised to open-source their Haskell server code, so maybe the community can help remove this technical limitation by implementing a proper store-and-forward mechanism.<p>It would also be good to have the option of choosing P2P E2E msgs that go directly between devices and never touch the Wire server. This would only be useful for synchronous conversations, but would again reduce the central server as an attack target.<p>[1] <a href="https://twitter.com/wire/status/822421405937659908" rel="nofollow">https://twitter.com/wire/status/822421405937659908</a>
Tl;dr: Wire voice and video chats use SRTP encryption, but the key is transmitted over the Wire server using normal TLS without further authentication checks or Certificate Pinning. A Wire employee or malicious government could MitM the claimed end to end encryption.
Can someone explain how Certificate Pinning works in a "trust no one" scenario? From my understanding, the idea is that you grab the certificate for a given domain once with the correct public key and then store it for later so that you can be notified when you're being MitM'd. But that assumes that the one you got was trustworthy to begin with: what happens if you're <i>already</i> a target or in a surveillance state and, having not previously visited the domain before, cannot guarantee that the pinned certificate you're getting is trustworthy?
> transmitted in plaintext over a normal TLS connection<p>I think we have differing views on what "plaintext" means.<p>Also, like it or not, it really looks like the calls are actually end-to-end encrypted, as in the server never sees or processes the cleartext content. Being possibly poorly designed and open to attacks does not change the fundamental underlying model.
What should happen is either<p>- A shared key should be passed over the e2e text channel and used as part of the DTLS setup. I'm unclear if this actually a possibility in WebRTC.<p>- Each side can send a fingerprint of the peers public key to each other over the text channel and the software can authenticate there is no MITM