Security Discussion

Signaling

Connections to the signaling server are done via WSS (WebSockets + SSL) or HTTPS. The signaling server is written using Node.js and just advertises other peers in the a same room. It is possible to directly send unencrypted messages to those other peers, usually for exchanging SDP data needed to establish the WebRTC session. All other data should be send directly via the WebRTC layer. Read more here: Signaling

WebRTC

Each WebRTC session is encrypted. To avoid a man-in-the-middle attack (MitM) you can verify if the connection has been established directly between you and any other participant, by comparing a checksum in the lower right corner of each video. It will expand to full length if you move the mouse pointer above the video element. This checksum is calculated from the room name plus the fingerprints of the SDPs (session descriptions). For manipulated fingerprints WebRTC refuses to connect thus this checksum is a proof that the connection is end to end.

Encryption

To enable encrypted communication a common secret or cryptographic keys would be required. This is currently not supported. Once you have verified the connection as described before, you can expect all data being encrypted end-to-end (E2EE). Since one goal of Briefing is not to require user accounts and to collect as least user related data as possible, the option of using personal keys seems not appropriate.

Anonymity

Although Briefing is not collecting specific user information, you need to take care yourself to hide your location. With each communication your IP is sent as well. To hide it you might be able to use some VPN or Tor network. To explain or build support for this is out of scope of this project.

Discussions

• Hacker News (June 2020)
• False promises: end-to-end encryption is not effective (June 2020)
• A Study of WebRTC Security