Confirmed users
632
edits
Loop/Architecture/Fingerprint Validation: Difference between revisions
Jump to navigation
Jump to search
Loop/Architecture/Fingerprint Validation (view source)
Revision as of 22:05, 23 September 2015
, 23 September 2015no edit summary
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
WebRTC's [https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-11#section-5.5 communications security model] works by way of a three-pronged model: | |||
# All media is encrypted with SRTP-DLTS, which uses a DH exchange to establish media security. The negotiated DH keys are not exposed to content. | |||
# To prevent active on-path attacks, DTLS fingerprint validation is performed by using a third-party signature, rooted in the web PKI, to authenticate the fingerprint. See [http://w3c.github.io/webrtc-pc/#sec.identity-proxy the WebRTC 1.0 Identity mechanism] for details. | |||
# To prevent in-content attacks, any streams for which fingerprint validation has been performed are "isolated" such that the content cannot be extracted by the webpage. | |||
The first mechanism prevents passive interception; the second, active on-path interception; and the third, attacks by the content itself. | |||
Currently, Hello makes use of only the first of these mechanisms, and relies on the security of the underlying network infrastructure (specifically, the OpenTok servers) to prevent on-path attacks. Because the nature of Hello does not require the use of any identity, making use of the second and third levels of protection can't be employed as specified. | |||
It is worth noting that additional trust gained by adding the Identity mechanism is only as good as the trust provided by the party that is vouching for a user's identity. For example, if the corresponding service cannot be trusted to provide such certificates only to authenticated users (or cannot be trusted to properly validate certificates when asked to), then its role is largely defeated. | |||
This basically sets up a system in which the Identity provider is serving as a third-party check against attacks on the infrastructure used to exchange SDP (and therefore DTLS fingerprints). | |||
The design below provides additional protection by using Mozilla's servers to provide a third-party check against attacks on the OpenTok infrastructure, without requiring the use of verifiable user identities. Note that this isn't as strong as the protection provided by the WebRTC Identity mechanism; however, it is a significant improvement over the existing situation, as it would require attacks on both the OpenTok infrastructure and Mozilla's infrastructure to launch an active interception of content. | |||
== API Changes == | == API Changes == | ||