You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The reason this is required is that in libp2p we have a connection protocol executed over WebRTC that skips the SDP handshake by deriving most of the information from the initial STUN packet and the incoming connection host/port details.
The only thing it doesn't know in advance is the certificate fingerprint of the remote, but this is not required since we do a noise handshake over a datachannel on the newly opened connection and supply the fingerprint as part of the connection prologue. More details on that here.
The text was updated successfully, but these errors were encountered:
Disabling fingerprint validation would be possible and I'd be happy to add an option for it. However, it's not sufficient to achieve what is described in the WebRTC Direct spec. You would also need to modify the ICE ufrag and password generation and validation process, and you'd need a specific ICE hook to create peer connections triggered by incoming STUN probes to implement "peer B".
Note even to implement "peer A", you can't rely on the SDP munging hack with libdatachannel (the library has no mechanism to set a modified local description by design to make the implementation way simpler):
Note that this process, oftentimes referred to as "SDP munging" is disallowed by the specification, but not enforced across the major browsers (Safari, Firefox, Chrome) due to use-cases in the wild. See also https://bugs.chromium.org/p/chromium/issues/detail?id=823036
Would it be possible to add an option to libdatachannel to disable fingerprint validation when establishing PeerConnections?
This would be analogous to the option in pion to do the same.
The reason this is required is that in libp2p we have a connection protocol executed over WebRTC that skips the SDP handshake by deriving most of the information from the initial STUN packet and the incoming connection host/port details.
The only thing it doesn't know in advance is the certificate fingerprint of the remote, but this is not required since we do a noise handshake over a datachannel on the newly opened connection and supply the fingerprint as part of the connection prologue. More details on that here.
The text was updated successfully, but these errors were encountered: