WebRTC provides several features to avoid the security problems.
1. WebRTC implements user of secure protocols such as DTLS and SRTP.
2. Encryption is mandatory for all WebRTC components including signalling mechanisms
3. WebRTC is not a plugin, its components run in the browser sandbox and not as a separate process.
4. Camera and microphone access must be granted explicitly and when the camera and microphone are running, this is clearly shown to the user.
In the WebRTC trust model,
1. Browser acts as Trusted Computing Base (TCB)
- This means that this is the only system that user can really trust
- The Job of TCB is to enforce user's desired security policies
2. Authenticated entities
- Entity is checked by browser
3. Unauthenticated Entities
- These are other network elements who send and receive traffic
Examples of Authenticated Entities
- Calling Services (Known Origin)
- Identity providers
- Other users (when cryptographically verified)
- Sometimes network elements with right topology (e.g. behind our firewall)
Authenticated is not equal to trusted:
Evil is still evil even if I know it is him.
- But authentication is the basis of trust decision
- And may be I want to call Dr. Evil after all
The basic design principle is that
- It is always safe to use the web
- Even to malicious site
Calls are encrypted where possible
- At minimum between WebRTC clients unless the site takes direct action
When available, directly verify the far side
- Minimize the required trust in calling site
- Be compatible with as many trust identity providers as possible.
Overall Topology is like below
References:
No comments:
Post a Comment