Confirmed users
632
edits
Loop/Architecture/Fingerprint Validation: Difference between revisions
Loop/Architecture/Fingerprint Validation (view source)
Revision as of 14:47, 25 September 2015
, 25 September 2015→Proof-of-Concept Monkeypatch Shim: Remove mention of setTimeout() since the example shows an event emitter instead. Removed success/failure callbacks from emitter, since these can't legally be called more than once.
(→Proof-of-Concept Monkeypatch Shim: Remove mention of setTimeout() since the example shows an event emitter instead. Removed success/failure callbacks from emitter, since these can't legally be called more than once.) |
|||
| (8 intermediate revisions by 2 users not shown) | |||
| 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: | 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- | # All media is encrypted with SRTP-DTLS, 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 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. | # 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. | ||
| Line 43: | Line 43: | ||
=== User Identification in a Room === | === User Identification in a Room === | ||
This design expands the information defined by [[Loop/Architecture/Rooms#User Identification in a Room]] to include an array of PeerConnection fingerprints. Note that this array | This design expands the information defined by [[Loop/Architecture/Rooms#User Identification in a Room]] to include an array of PeerConnection fingerprints. Note that this array MUST be present (even when empty) if the client indicated a "fingerprint" feature when joining the room. It MUST NOT be present if the client didn't indicate support for "fingerprint". | ||
{ | { | ||
"displayName": "-", | "displayName": "-", | ||
| Line 55: | Line 55: | ||
=== Uploading PeerConnection Fingerprints === | === Uploading PeerConnection Fingerprints === | ||
This design adds a new action to the [[Loop/Architecture/Rooms#POST_.2Frooms.2F.7Btoken.7D|POST /rooms/{token}]] endpoint; this action is called " | This design adds a new action to the [[Loop/Architecture/Rooms#POST_.2Frooms.2F.7Btoken.7D|POST /rooms/{token}]] endpoint; this action is called "add-fingerprint". Clients supporting fingerprint validation will send this information whenever a new PeerConnection begins media negotiation. | ||
POST /rooms/QzBbvGmIZWU HTTP/1.1 | POST /rooms/QzBbvGmIZWU HTTP/1.1 | ||
| Line 65: | Line 65: | ||
{ | { | ||
"action": " | "action": "add-fingerprint", | ||
"fingerprint": "sha-256 15:E2:AF:50:91:87:FD:54:4C:82:F5:65:46:7A:84:D8:6C:53:00:99:C6:97:4E:64:2A:32:AA:A5:3C:91:E9:51" | "fingerprint": "sha-256 15:E2:AF:50:91:87:FD:54:4C:82:F5:65:46:7A:84:D8:6C:53:00:99:C6:97:4E:64:2A:32:AA:A5:3C:91:E9:51" | ||
} | } | ||
* '''action''' - For sending a new PeerConnection fingerprint, this will be " | * '''action''' - For sending a new PeerConnection fingerprint, this will be "add-fingerprint". | ||
* '''fingerprint''' - The new PeerConnection fingerprint. The server will store this fingerprint as part of the user's identity in the room, and return it as an element in its "fingerprints" array. Fingerprint values should be de-duplicated by the server, and uploading the same fingerprint multiple times shall not be an error. | * '''fingerprint''' - The new PeerConnection fingerprint. The server will store this fingerprint as part of the user's identity in the room, and return it as an element in its "fingerprints" array. Fingerprint values should be de-duplicated by the server, and uploading the same fingerprint multiple times shall not be an error. | ||
| Line 118: | Line 118: | ||
Much of the required client behavior is implied by the network API; however, to be explicit, this section describes the expected client behavior. | Much of the required client behavior is implied by the network API; however, to be explicit, this section describes the expected client behavior. | ||
Prior to loading the OpenTok SDK, the client will override window.RTCPeerConnection (or the appropriate prefixed variant, if present). The overridden function will call the original constructor, override the setLocalDescription and setRemoteDescription methods on the newly created object, and return the modified PeerConnection. The overrides of setLocalDescription and setRemoteDescription will perform exfiltration and comparison of fingerprints, respectively. See [#Proof-of-Concept Monkeypatch Shim] for an example of how this might look. | Prior to loading the OpenTok SDK, the client will override window.RTCPeerConnection (or the appropriate prefixed variant, if present). The overridden function will call the original constructor, override the setLocalDescription and setRemoteDescription methods on the newly created object, and return the modified PeerConnection. The overrides of setLocalDescription and setRemoteDescription will perform exfiltration and comparison of fingerprints, respectively. See [[#Proof-of-Concept Monkeypatch Shim]] for an example of how this might look. | ||
In more detail: when the setLocalDescription shim is called, it extracts the fingerprint attribute from the SDP that was passed to that function, and enqueues it to be sent to the Loop server (e.g., using <tt>setTimeout(...,0)</tt>). The fingerprint is sent using a "POST /rooms/{token}" request, with action= | In more detail: when the setLocalDescription shim is called, it extracts the fingerprint attribute from the SDP that was passed to that function, and enqueues it to be sent to the Loop server (e.g., using <tt>setTimeout(...,0)</tt>). The fingerprint is sent using a "POST /rooms/{token}" request, with action="add-fingerprint", as described in [#Uploading PeerConnection Fingerprints] | ||
When the setRemoteDescription shim is called, it enqueues a function with a relatively short timeout ( | When the setRemoteDescription shim is called, it enqueues a function with a relatively short timeout (I propose 5 seconds) that performs the following steps: | ||
# Check the list of fingerprints published by other person in the room. | # Check the list of fingerprints published by other person in the room. | ||
| Line 135: | Line 135: | ||
== Proof-of-Concept Monkeypatch Shim == | == Proof-of-Concept Monkeypatch Shim == | ||
This is a very simple example that shows how to override the setLocalDescription and setRemoteDescription methods as required to implement this design. It has been verified not to interfere with the OpenTok SDK's proper functioning. This version is Firefox-specific; however, it can presumably be modified to work in Chrome by simply checking for and using the "webkit" prefix as necessary. | |||
window._originalRTCPeerConnection = window.mozRTCPeerConnection; | window._originalRTCPeerConnection = window.mozRTCPeerConnection; | ||
| Line 142: | Line 142: | ||
var setDescriptionShim = function(sdp, success, failure, pc, localRemote) { | var setDescriptionShim = function(sdp, success, failure, pc, localRemote) { | ||
var fingerprint = /a=fingerprint:([^\r\n]*)/.exec(sdp.sdp)[1]; | var fingerprint = /a=fingerprint:([^\r\n]*)/.exec(sdp.sdp)[1]; | ||
console.log(localRemote + " fingerprint = " + fingerprint); | console.log(localRemote + " fingerprint = " + fingerprint); | ||
// Use any available event-emitter to decouple this code from the application. | |||
eventEmitter.emit("set" + localRemote + "Description", sdp); | |||
pc["_originalSet" + localRemote + "Description"](sdp, success, failure); | pc["_originalSet" + localRemote + "Description"](sdp, success, failure); | ||
} | } | ||