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 14:42, 25 September 2015
, 25 September 2015Change "newpc" to "add-fingerprint"
Mikedeboer (talk | contribs) m (code block) |
(Change "newpc" to "add-fingerprint") |
||
| 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 120: | Line 120: | ||
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 (I propose 5 seconds) that performs the following steps: | When the setRemoteDescription shim is called, it enqueues a function with a relatively short timeout (I propose 5 seconds) that performs the following steps: | ||