Loop/Architecture/Fingerprint Validation: Difference between revisions

Line 115: Line 115:


== Client Behavior ==
== Client Behavior ==
Roughly:
* Monkeypatch setLocalDescription. When called:
** POST new fingerprint to the room using "newpc" action
* Monkeypatch setRemoteDescription. When called:
*# Check list of fingerprints published by other person in the room
*# If no match, perform a room GET to refresh information, and compare again
*# If still no match, set a timer for 1 second; on expiry, try one more fetch and compare
*# If still no match, error out the session and log an error to the server


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.
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=newpc, as described in [#Uploading PeerConnection Fingerprints]
When the setRemoteDescription shim is called, it enqueues a function with a relatively short timeout (e.g., 1 to 5 seconds) that performs the following steps:
# Check the list of fingerprints published by other person in the room.
#* If the user's information doesn't contain a fingerprint array, then it doesn't support fingerprint validation. Initially, this will result in simply skipping the rest of this procedure. In the future, we will want to treat this as a client that is to out-of-date to interoperate with current clients. The timeframe for doing so is for future study.
# If no matching fingerprint is found, perform a "GET /rooms/{token}" to refresh the room information information
# When the response to that GET is received, tries again to find the fingerprint in the user's information
# If no match is still found, the client will:
#* Log an error to the Loop server indicating a fingerprint validation error
#* Alert the user that the session is being terminated because its security cannot be verified, and
#* Terminate the session


== Proof-of-Concept Monkeypatch Shim ==
== Proof-of-Concept Monkeypatch Shim ==
Confirmed users
632

edits