New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 11 users

Issue metadata

Status: Started
Owner:
Cc:
Components:
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

Encrypt RFC 6464 RTP header extension

Reported by kape...@gmail.com, May 28 2014

Issue description

Chrome enables the "ssrc-audio-level" RTP header extension (RFC 6464) by default.

This extension adds an audio level expressed in dBov to each and every SRTP packet. RTP header extensions are NOT encrypted. That means Chrome is leaking information wether an endpoint is silent/speaking/muted to anybody who has access to the SRTP packets.
This kind of meta data about an encrypted conversation is the subject of wet dreams for anybody who is recording the whole internet.

To fix this please implement SRTP header extension encryption (RFC 6904).
And until then it would be nice to not enable RFC 6464 by default

Thanks a lot!
 
Project Member

Comment 1 by braveyao@webrtc.org, May 29 2014

Cc: braveyao@webrtc.org vikasmarwaha@webrtc.org
Owner: juberti@webrtc.org
@justin, please help to comment!
Project Member

Comment 2 by juberti@webrtc.org, May 29 2014

Labels: Area-PeerConnection
Status: Available
Summary: Encrypt RFC 6464 RTP header extension (was: Leaking sensitive information (audio levels) by not encrypting RTP header extensions)
While I understand the concern, RFC 6464 isn't really providing significant additional information to an eavesdropper - you can tell who is speaking from the RTP marker bit, as well as variations in the codec bitrate and/or silence suppression. 

And at the moment, this functionality is useful for many apps (e.g. MCUs), and the WG hasn’t agreed on a mechanism to turn it on or off. But the final state will be that we will support RFC 6904 (with optional disabling for apps that need it unencrypted), as well as padding of the codec stream to prevent similar information leakage from the codec bitrate when this header info is being encrypted. In the meantime, apps that are concerned about this can use the workaround of stripping the header extension from the received SDP before calling setRemoteDescription.

Regarding why we wouldn't always encrypt the audio levels by default, there is value in supporting unencrypted energy levels; there are important use cases where having them unencrypted is actually beneficial for security (e.g. a MCU that can’t decode the media, but needs to know the energy for switching). Several MCU vendors are investigating this concept.

Comment 3 by kape...@gmail.com, May 29 2014

Regarding the MCUs are you talking about DTLS-SRTP key transport (http://tools.ietf.org/html/draft-wing-avt-dtls-srtp-key-transport-03)?
Project Member

Comment 4 by juberti@webrtc.org, May 29 2014

There are various techniques being discussed. That document seems to be obsolete.

Comment 5 by kape...@gmail.com, May 29 2014

Any hints, especially what webrtc in Chrome is supporting?

Comment 6 by vrk@webrtc.org, Oct 16 2014

Labels: IceBox EngTriaged
Project Member

Comment 7 by tnakamura@webrtc.org, Nov 4 2015

Cc: -vikasmarwaha@webrtc.org
This bug hasn't been modified for more than a year. Is this still a valid open issue?
Project Member

Comment 8 by juberti@webrtc.org, Nov 5 2015

Cc: pthatcher@webrtc.org
yes
Project Member

Comment 9 by jbauch@webrtc.org, Dec 14 2015

Cc: juberti@webrtc.org
Owner: jbauch@webrtc.org
Status: Assigned
I implemented support for this in libsrtp where it just got merged (master branch, i.e. upcoming 2.0.x release):
https://github.com/cisco/libsrtp/commit/ce37ef61444400370f699c44985949ba44557d00

As WebRTC is using the 1.5.x tree of libsrtp and I'm not sure about already upgrading to 2.0.x, I will backport this for our version, so this can be used by WebRTC.
Project Member

Comment 10 by juberti@webrtc.org, Dec 17 2015

Would it make sense to migrate webrtc to 2.0?
Project Member

Comment 11 by jbauch@webrtc.org, Dec 17 2015

I would rather wait until there is an official release of libsrtp 2.0 (their "master" branch is still in development).

The changes to support header extensions encryption are straightforward and should be easy to backport.
Project Member

Comment 12 by jbauch@webrtc.org, Dec 18 2015

Status: Started
Project Member

Comment 13 by jbauch@webrtc.org, Dec 19 2015

See https://codereview.chromium.org/1533013002/ for the backport.
Project Member

Comment 14 by bugdroid1@chromium.org, May 3 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f59757356519c61442bb99bad5c9a13b47cc5882

commit f59757356519c61442bb99bad5c9a13b47cc5882
Author: jbauch <jbauch@webrtc.org>
Date: Tue May 03 17:55:47 2016

Roll src/third_party/libsrtp/ ea4ed36c8..720780acf (1 commit).

https://chromium.googlesource.com/chromium/deps/libsrtp.git/+log/ea4ed36c8fbe..720780acf8fa

$ git log ea4ed36c8..720780acf --date=short --no-merges --format='%ad %ae %s'
2016-05-03 jiayl Support header extensions encryption (RFC 6904).

BUG=webrtc:3411

Review-Url: https://codereview.chromium.org/1945723002
Cr-Commit-Position: refs/heads/master@{#391289}

[modify] https://crrev.com/f59757356519c61442bb99bad5c9a13b47cc5882/DEPS

Project Member

Comment 15 by tommi@webrtc.org, Jan 30 2017

Cc: mflodman@webrtc.org tommi@webrtc.org
Project Member

Comment 16 by bugdroid1@chromium.org, Apr 4 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/12506cca0cb8afe1598f5f2f363fc5f2db7aca50

commit 12506cca0cb8afe1598f5f2f363fc5f2db7aca50
Author: jbauch <jbauch@webrtc.org>
Date: Tue Apr 04 15:13:46 2017

Roll src/third_party/libsrtp/ d15364a80..ccf84786f (1 commit)

$ git log d15364a80..ccf84786f --date=short --no-merges --format='%ad %ae %s'
2017-04-04 kjellander Fix OOB read in key generation for encrypted headers with GCM ciphers.

Created with:
  roll-dep src/third_party/libsrtp

BUG=webrtc:3411
R=kjellander@chromium.org

Review-Url: https://codereview.chromium.org/2789373002
Cr-Commit-Position: refs/heads/master@{#461720}

[modify] https://crrev.com/12506cca0cb8afe1598f5f2f363fc5f2db7aca50/DEPS

Project Member

Comment 17 by bugdroid1@chromium.org, Jun 29 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/5869f50f7a7079055fde7320a3babc5f26134f1c

commit 5869f50f7a7079055fde7320a3babc5f26134f1c
Author: jbauch <jbauch@webrtc.org>
Date: Thu Jun 29 19:31:36 2017

Support encrypted RTP extensions (RFC 6904)

Can be enabled by setting "enable_encrypted_rtp_header_extensions" in
"crypto_options" of "PeerConnectionFactoryInterface::Options" and will
only be used if both peers support it.

BUG=webrtc:3411

Review-Url: https://codereview.webrtc.org/2761143002
Cr-Commit-Position: refs/heads/master@{#18842}

[modify] https://crrev.com/5869f50f7a7079055fde7320a3babc5f26134f1c/webrtc/BUILD.gn
[modify] https://crrev.com/5869f50f7a7079055fde7320a3babc5f26134f1c/webrtc/config.cc
[modify] https://crrev.com/5869f50f7a7079055fde7320a3babc5f26134f1c/webrtc/config.h
[add] https://crrev.com/5869f50f7a7079055fde7320a3babc5f26134f1c/webrtc/config_unittest.cc
[modify] https://crrev.com/5869f50f7a7079055fde7320a3babc5f26134f1c/webrtc/media/BUILD.gn
[add] https://crrev.com/5869f50f7a7079055fde7320a3babc5f26134f1c/webrtc/media/base/fakertp.cc
[modify] https://crrev.com/5869f50f7a7079055fde7320a3babc5f26134f1c/webrtc/media/base/fakertp.h
[modify] https://crrev.com/5869f50f7a7079055fde7320a3babc5f26134f1c/webrtc/media/engine/webrtcmediaengine.cc
[modify] https://crrev.com/5869f50f7a7079055fde7320a3babc5f26134f1c/webrtc/media/engine/webrtcmediaengine_unittest.cc
[modify] https://crrev.com/5869f50f7a7079055fde7320a3babc5f26134f1c/webrtc/p2p/base/dtlstransportchannel.cc
[modify] https://crrev.com/5869f50f7a7079055fde7320a3babc5f26134f1c/webrtc/p2p/base/dtlstransportchannel.h
[modify] https://crrev.com/5869f50f7a7079055fde7320a3babc5f26134f1c/webrtc/p2p/base/dtlstransportinternal.h
[modify] https://crrev.com/5869f50f7a7079055fde7320a3babc5f26134f1c/webrtc/p2p/base/fakedtlstransport.h
[modify] https://crrev.com/5869f50f7a7079055fde7320a3babc5f26134f1c/webrtc/pc/channel.cc
[modify] https://crrev.com/5869f50f7a7079055fde7320a3babc5f26134f1c/webrtc/pc/channel.h
[modify] https://crrev.com/5869f50f7a7079055fde7320a3babc5f26134f1c/webrtc/pc/channel_unittest.cc
[modify] https://crrev.com/5869f50f7a7079055fde7320a3babc5f26134f1c/webrtc/pc/mediasession.cc
[modify] https://crrev.com/5869f50f7a7079055fde7320a3babc5f26134f1c/webrtc/pc/mediasession.h
[modify] https://crrev.com/5869f50f7a7079055fde7320a3babc5f26134f1c/webrtc/pc/mediasession_unittest.cc
[modify] https://crrev.com/5869f50f7a7079055fde7320a3babc5f26134f1c/webrtc/pc/srtpfilter.cc
[modify] https://crrev.com/5869f50f7a7079055fde7320a3babc5f26134f1c/webrtc/pc/srtpfilter.h
[modify] https://crrev.com/5869f50f7a7079055fde7320a3babc5f26134f1c/webrtc/pc/srtpfilter_unittest.cc
[modify] https://crrev.com/5869f50f7a7079055fde7320a3babc5f26134f1c/webrtc/pc/webrtcsdp.cc
[modify] https://crrev.com/5869f50f7a7079055fde7320a3babc5f26134f1c/webrtc/pc/webrtcsdp_unittest.cc
[modify] https://crrev.com/5869f50f7a7079055fde7320a3babc5f26134f1c/webrtc/pc/webrtcsession.cc
[modify] https://crrev.com/5869f50f7a7079055fde7320a3babc5f26134f1c/webrtc/pc/webrtcsessiondescriptionfactory.h
[modify] https://crrev.com/5869f50f7a7079055fde7320a3babc5f26134f1c/webrtc/rtc_base/sslstreamadapter.h

Project Member

Comment 18 by anatolid@webrtc.org, Aug 14 2017

What's the status here? More work planned?
Project Member

Comment 19 by jbauch@webrtc.org, Aug 14 2017

I have another CL pending to wire this up in Chromium: https://chromium-review.googlesource.com/c/563622
Project Member

Comment 20 by bugdroid1@chromium.org, Aug 14 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/060188292b7bcb5a3ddddba157b63b4fe52a0ea9

commit 060188292b7bcb5a3ddddba157b63b4fe52a0ea9
Author: Joachim Bauch <jbauch@webrtc.org>
Date: Mon Aug 14 20:55:03 2017

Improve libsrtp fuzzer.

- Also check AES-256-GCM which is used by WebRTC.
- Also check AES-128 with 32 bit auth tag which is used by WebRTC.
- Update AES-128-GCM to use 16 octets tag as used by WebRTC.
- Enable encrypted header extensions depending on fuzzing input. This
  tests new functionality of WebRTC.

BUG=webrtc:3411

Change-Id: I076c4ae5be71dd09bfec4928e6b5b12be8fc428c
Reviewed-on: https://chromium-review.googlesource.com/612076
Commit-Queue: Joachim Bauch <jbauch@webrtc.org>
Reviewed-by: Max Moroz <mmoroz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#494182}
[modify] https://crrev.com/060188292b7bcb5a3ddddba157b63b4fe52a0ea9/testing/libfuzzer/fuzzers/libsrtp_fuzzer.cc

Project Member

Comment 21 by bugdroid1@chromium.org, Aug 23 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4a41d7510b9679987fdf9ac0bad7baa2c1bc3909

commit 4a41d7510b9679987fdf9ac0bad7baa2c1bc3909
Author: Joachim Bauch <jbauch@webrtc.org>
Date: Wed Aug 23 14:24:23 2017

Add commandline flag to enable encrypted header extensions for SRTP in WebRTC.

This CL adds a new commandline flag and chrome://flags option to enable
negotiation of encrypted header extensions for SRTP in WebRTC as defined
in RFC 6904.

BUG=webrtc:3411

Change-Id: Iaa2f21a337be79a6dc052020344427183b427bbc
Reviewed-on: https://chromium-review.googlesource.com/563622
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Taylor Brandstetter <deadbeef@chromium.org>
Commit-Queue: Joachim Bauch <jbauch@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#496680}
[modify] https://crrev.com/4a41d7510b9679987fdf9ac0bad7baa2c1bc3909/chrome/browser/about_flags.cc
[modify] https://crrev.com/4a41d7510b9679987fdf9ac0bad7baa2c1bc3909/chrome/browser/flag_descriptions.cc
[modify] https://crrev.com/4a41d7510b9679987fdf9ac0bad7baa2c1bc3909/chrome/browser/flag_descriptions.h
[modify] https://crrev.com/4a41d7510b9679987fdf9ac0bad7baa2c1bc3909/content/browser/renderer_host/render_process_host_impl.cc
[modify] https://crrev.com/4a41d7510b9679987fdf9ac0bad7baa2c1bc3909/content/public/common/content_switches.cc
[modify] https://crrev.com/4a41d7510b9679987fdf9ac0bad7baa2c1bc3909/content/public/common/content_switches.h
[modify] https://crrev.com/4a41d7510b9679987fdf9ac0bad7baa2c1bc3909/content/renderer/media/webrtc/peer_connection_dependency_factory.cc
[modify] https://crrev.com/4a41d7510b9679987fdf9ac0bad7baa2c1bc3909/tools/metrics/histograms/enums.xml

Sign in to add a comment