avformat/whip: require remote DTLS fingerprint in SDP answer#78
Open
JackLau1222 wants to merge 1 commit into
Open
avformat/whip: require remote DTLS fingerprint in SDP answer#78JackLau1222 wants to merge 1 commit into
JackLau1222 wants to merge 1 commit into
Conversation
WHIP relies on the SDP a=fingerprint to bind the peer identity to
the SRTP keying material (RFC 8842 §§ 5.1, 5.3). parse_answer()
walks the SDP body looking for `a=ice-lite`, `a=ice-ufrag:`,
`a=ice-pwd:`, and `a=candidate:` lines and ignores everything else,
including `a=fingerprint`. WHIP intentionally runs the OpenSSL DTLS
backend with s->verify=0 (DTLS-SRTP uses self-signed certs by
design, so a CA chain check would be meaningless); the peer cert is
accepted regardless of identity. The spec's compensating identity
control — verifying the DTLS peer cert against the SDP a=fingerprint
hash — is missing, so the SRTP keys are derived from a session
whose peer identity was never authenticated. Any on-path attacker,
or a malicious WHIP server URL, can substitute their own DTLS
material and the publisher's RTP stream will be encrypted to them.
The full fix is a two-step process:
(a) Require a=fingerprint to be present in the SDP answer
(RFC 8842 § 5.3 MUST).
(b) After DTLS handshake, compute the peer-cert hash and compare
against the stored fingerprint (RFC 8842 § 5.1 MUST); tear
down the session on mismatch.
This patch implements step (a) only; step (b) requires plumbing
the cert hash out of dtls_start() through the openssl TLS context
and is left as a follow-up.
Add a remote_fingerprint field to WHIPContext, extract the
a=fingerprint value from the SDP answer in parse_answer(), and
return AVERROR(EINVAL) when it is absent. This raises the bar from
"no fingerprint required" to "any fingerprint required"; the
follow-up patch will raise it again to "fingerprint MUST hash-match
the DTLS peer cert."
Found-by: Claude (Anthropic). Human-verified and reported by
Omkhar Arasaratnam <omkhar@linkedin.com>.
Signed-off-by: Omkhar Arasaratnam <omkhar@linkedin.com>
github-actions
Bot
force-pushed
the
workflows
branch
7 times, most recently
from
June 3, 2026 00:54
f7516d1 to
7079d5b
Compare
github-actions
Bot
force-pushed
the
workflows
branch
8 times, most recently
from
June 11, 2026 00:48
3a21f63 to
78e6b5b
Compare
github-actions
Bot
force-pushed
the
workflows
branch
7 times, most recently
from
June 18, 2026 00:51
f3a2fa0 to
0a5ee51
Compare
github-actions
Bot
force-pushed
the
workflows
branch
7 times, most recently
from
June 25, 2026 00:45
df9a9de to
3eeac0d
Compare
github-actions
Bot
force-pushed
the
workflows
branch
7 times, most recently
from
July 2, 2026 00:44
4ac1629 to
e0056c5
Compare
github-actions
Bot
force-pushed
the
workflows
branch
7 times, most recently
from
July 9, 2026 02:36
79431fe to
842e45a
Compare
github-actions
Bot
force-pushed
the
workflows
branch
8 times, most recently
from
July 17, 2026 02:20
9fc4947 to
6e3be90
Compare
github-actions
Bot
force-pushed
the
workflows
branch
6 times, most recently
from
July 24, 2026 02:22
cf51801 to
f17ab0c
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
WHIP relies on the SDP a=fingerprint to bind the peer identity to the SRTP keying material (RFC 8842 §§ 5.1, 5.3). parse_answer() walks the SDP body looking for
a=ice-lite,a=ice-ufrag:,a=ice-pwd:, anda=candidate:lines and ignores everything else, includinga=fingerprint. WHIP intentionally runs the OpenSSL DTLS backend with s->verify=0 (DTLS-SRTP uses self-signed certs by design, so a CA chain check would be meaningless); the peer cert is accepted regardless of identity. The spec's compensating identity control — verifying the DTLS peer cert against the SDP a=fingerprint hash — is missing, so the SRTP keys are derived from a session whose peer identity was never authenticated. Any on-path attacker, or a malicious WHIP server URL, can substitute their own DTLS material and the publisher's RTP stream will be encrypted to them.The full fix is a two-step process:
(a) Require a=fingerprint to be present in the SDP answer
(RFC 8842 § 5.3 MUST).
(b) After DTLS handshake, compute the peer-cert hash and compare
against the stored fingerprint (RFC 8842 § 5.1 MUST); tear
down the session on mismatch.
This patch implements step (a) only; step (b) requires plumbing the cert hash out of dtls_start() through the openssl TLS context and is left as a follow-up.
Add a remote_fingerprint field to WHIPContext, extract the a=fingerprint value from the SDP answer in parse_answer(), and return AVERROR(EINVAL) when it is absent. This raises the bar from "no fingerprint required" to "any fingerprint required"; the follow-up patch will raise it again to "fingerprint MUST hash-match the DTLS peer cert."
Found-by: Claude (Anthropic). Human-verified and reported by Omkhar Arasaratnam omkhar@linkedin.com.