WebRTC requires Perfect Forward Secrecy (PFS) starting in Firefox 38

Today, we are announcing that Firefox 38 will take further measures to secure users’ communications by removing support in WebRTC for all DTLS cipher suites that do not support forward secrecy. For developers: if you have a WebRTC application or server that doesn’t support PFS ciphers, you will need to update your code.

Forward secrecy, also known as Perfect Forward Secrecy (PFS), is a feature of a cryptographic protocol that limits the damage of a key compromise: “This means that the compromise of one [session] cannot lead to the compromise of others, and also that there is not a single secret value which can lead to the compromise of multiple [sessions]”.

The PFS suites in TLS and DTLS use an ephemeral Diffie-Hellman key exchange (DHE) or elliptic-curve Diffie-Hellman (ECDHE) to create a different shared secret key for each session. The WebRTC security architecture recommends that PFS suites be preferred for WebRTC.

Due to bug 102794, Firefox is unable to act as a server for DHE cipher suites. We plan to add complete DHE support, but until then we recommend the use of the ECDHE cipher suites.

Existing users of the webrtc.org codebase who are using OpenSSL and derivatives such as BoringSSL need to update to enable ECDHE ciphers. This bug contains more details.

If you have a WebRTC application or server that doesn’t support PFS ciphers, you should be working on getting that resolved ASAP. Firefox 38 is scheduled for Beta the week of March 30th, and a general release is planned for Tuesday, May 12th.

About Maire Reavy

Maire is the engineering manager for Mozilla’s WebRTC team.

More articles by Maire Reavy…


2 comments

  1. Ruslan

    What about that security issue: https://diafygi.github.io/webrtc-ips/
    When we will be asked before anybody in web can access our IPs from javascript?

    February 25th, 2015 at 07:45

    1. Ralph Giles

      You won’t be asked by default. Basically, the maintainers agree with the RTCWEB concensus that having peer-to-peer, end-to-end encrypted, open source audio, video, and data exchange broadly available between browsers is more important than the local ip address disclosure issue. See the spec at https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch#section-5.4 for documentation, or the rtcweb mailing lists and mozilla bug 959893 for extensive discussion.

      Disclosure is unfortunate, but that’s how the tradeoff was selected. If you have a practical mitigation suggestion that still addresses the supported use cases, please implement it and bring it up on the mailing list.

      March 13th, 2015 at 12:08

Comments are closed for this article.