- From: Tim Panton via GitHub <noreply@w3.org>
- Date: Wed, 18 Jun 2025 11:59:30 +0000
- To: public-webrtc@w3.org
steely-glint has just created a new issue for https://github.com/w3c/webrtc-pc: == getRemoteFingerprints() needed. == ### Summary [getFingerprints()](https://w3c.github.io/webrtc-pc/#dom-rtccertificate-getfingerprints) is available on local certificates, but there is no matching way to access the remotePeer's certificate fingerprints. We should add an API point for this. ### Why is this useful? If you have an untrusted (federated?) signalling system, (eg web torrent trackers, DNS, SMS, Telegram or other) it is still possible to have a degree of MiTM protection for 2 peers if peers reuse 'known good' (e.g verified out of band, or trusted on first use) certificates from a previous session and can test in subsequent sessions that the peer is re-using the previously verified/trusted certificate. So we need to be able to: - store and reuse local certificates (at both ends). - access (and compare) both the local and remote Certificate fingerprints. ### Local The webRTC-pc api allows for the creation, storage and use of a _local_ certificate and provides an API point to access it: [rtccertificate](https://w3c.github.io/webrtc-pc/#rtccertificate-interface ) ### Remote Access to the remote certificate is available through: [getRemoteCertificates](https://w3c.github.io/webrtc-pc/#dom-rtcdtlstransport-getremotecertificates) ### Problems 1. `getRemoteCertificates` returns an array buffer, not a list of `rtccertificate`, so the application is left to parse the ASN1 and generate the fingerprint in javascript, which seems undesirable. 2. It is too late. By the time this method is valid, the DTLS handshake has competed and you have already exchanged DTLS (and probably SCTP and SRTP) packets with the putative MiTM - which, as project zero has shown, is good to avoid if you can. ### Note The fingerprints are available in the SDP - for both local and remote - but we want to deprecate sdp inspection. ### Current best practice If an app knows the remote fingerprint it is expecting from the 'known' peer it can munge the RemoteDescription.sdp and replace the sent `a=fingerprint` with the expected value before calling setRemoteDescription(). If the remote peer does use the expected certificate in the DTLS handshake then the connection will come up. If the remote isn't using the expected then the transport will fire a [fingerprint-failure] https://w3c.github.io/webrtc-pc/#dom-rtcerrordetailtype-fingerprint-failure error and abort the connection. Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/3055 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 18 June 2025 11:59:31 UTC