How to really treat security between peers in WebRTC

Question

Recently I've been implementing WebRTC in my project and would like to add security and privacy to the couple. I then decided to search on and found something

if it is really necessary to impose security, it should be done at the application level.

I do not remember if I read this in the API or security sites ..

All right, I encrypt traffic (answer, offer, candidate..) with AES and RSA.

I noticed that the work of my system greatly reduced efficiency, it slowed the time to connect, which is kind of obvious because so many processes at once.

My questions taking into account all these are:

• Am I doing right?

• Is it really necessary encrypt all ?, may not just be the answer and offer?

• Is there anything else I should know?

Answer 1

Encryption in webRTC is madatory so you do not have to implement it yourself. See WebRTC P2P SSL - Where are the keys generated? for more information on how the keys are exchanged.

The peers will exchange their public keys during the signaling process. Then they will encrypt their communication over the P2P channel. This is mandatory so you have no choice over it.

What is left up to you is the signaling server.

So 1st if the signaling server is not yours and you do not trust it then it can Man-In-the-Middle the communication and you have no security guarantee at all.

Then if it is a server you trust (for eg you're running your own signaling server), you want to make sure that the communication between the peers and the server is secured. There is no obligation on how to perform signaling. It can be done over HTTP or Websocket(WS), but whatever you use, you should use their respective encrypted version HTTPS and Secure Web Socket (WSS).

In summary don't encrypt yourself, WebRTC is encrypted by default, just make sure to use SSL between the peers and the signaling server (and make sure you trust the signaling server itself).

Answer 2

Technically, encryption always have a performance impact, in todays machines it's negligible. For best outcome, you could perform the following:

• Get the RSA public key of the server side.
• Create a symmetric AES key, encrypt it with the RSA public key and send it to the server; the server decrypts it and you have a 'pre shared secret' then.
• Encrypt your data with the symmetric key, and decrypt it on the server.

Not to re-invent the wheel, but if you have browsers such as Opera, Chrome or FF, you could use Datagram Transport Layer Security or ZRTP.

In essence, WebRTC creates a new communication channel, and encryption is up to you. What you encrypt (offer, answer, ...) is basically based on how sensitive the information is, but once a channel is setup (i.e: the AES key is shared), you may as well encrypt everything; again - you'll have a minimal performance impact on modern systems.