Deprecating TLS 1.0, TLS 1.1 and DTLS 1.0 in M81

[Benjamin Wright]

Chrome is planning to deprecate TLS 1.0 and TLS 1.1 in Chrome 81. To keep in line with this WebRTC will also be deprecating TLS 1.0, TLS 1.1 and DTLS 1.0 (based on TLS 1.1) in Chrome 81. This will impact users in the release channel in January 2020. You can keep up to date with the latest Chrome release timelines here.

We initially wanted to push this forward to Chrome 74, since by default WebRTC already uses (D)TLS 1.2. However, based on the feedback it is clear that some in the community need more time to update their systems, and so we have reverted this change from Chrome 74. You can track the WebRTC specific bug here.

Why are we doing this?
Modernizing Transport Security - TLS 1.2 was published ten years ago to address weaknesses in TLS 1.0 and 1.1 and has enjoyed wide adoption since then. Today only 0.5% of HTTPS connections made by Chrome use TLS 1.0 or 1.1. These old versions of TLS rely on MD5 and SHA-1, both now broken, and contain other flaws. TLS 1.0 is no longer PCI-DSS compliant and the TLS working group has adopted a document to deprecate TLS 1.0 and TLS 1.1”

In relation to DTLS 1.0, given that it is based on TLS 1.1, it makes sense to deprecate this at the same time. In addition, this article explains in greater detail the Lucky13 attack on CBC-mode encryption for TLS.  Removing DTLS 1.0 is also compliant with the ietf-rtcweb-security-arch RFC.

How will you be affected?
WebRTC in Chrome 81 will not allow downgrading to DTLS 1.0, TLS 1.0 or TLS 1.1. This means that a connection will not be able to be established and the connection will fail. Browser to browser communication will not be impacted, as all browsers are already using DTLS 1.2 by default. However, if you are using a MCU, SFU or any other media gateway, please validate that you support DTLS 1.2. If you are using BoringSSL/OpenSSL see SSL_CTX_set_max_proto_version and SSL_CTX_set_min_proto_version for more information.

How can you check if you are impacted?
This may vary based on how you implement your service but a good way to check is to verify that DTLS 1.2 shows up when you query for dtls in Wireshark. Lookout for a deprecation warning in a future release of Chrome.

[Philipp Hancke]

is it still possible to force DTLS 1.2 through field trial command line flags? Thinking of Chrome instances running automated tests... where test failures would be good today.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAJbOT%3DkYBzEkSCTuejX_Hs2PakTztpdapHD5xbgyLidvUOQohQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Benjamin Wright]

Hi Philipp, we can add in a WebRTC field trial that if present would specifically disable the soon to be deprecated cipher suites for testing purposes. I have filed a bug here:
https://bugs.chromium.org/p/webrtc/issues/detail?id=10539

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CADxkKiKn6ogqJRk0AXOeVEpZJw_1yMkKJns%2BfmW%2BNCo38Y4KEQ%40mail.gmail.com.

[Lennart Grahl]

Perhaps you also want to deprecate the 3DES cipher suite offered by Chrome in the list of DTLS cipher suites?

[Benjamin Wright]

Hi Lennart. This is definitely on the radar but thanks for bringing it up.

I have added a comment directly to the master bug specifically regarding DTLS 1.2 cipher suites: https://bugs.chromium.org/p/webrtc/issues/detail?id=10261#c40 
I have filed a separate issue here to directly track the issue: https://bugs.chromium.org/p/webrtc/issues/detail?id=10540. Feel free to comment or cc yourself on that bug.

The webrtc-security-arch document is pretty specific about what support is required here:
"All Implementations MUST implement DTLS 1.2 with the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite and the P-256 curve [FIPS186]." So we will see what we can do.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/4015ede0-1c4a-43b7-a8d0-66a1f961dd85%40googlegroups.com.

[Alexander Abagian]

Aren't you also going to remove SRTP/crypto support ?

[Nils Ohlmeier]

On Tuesday, April 9, 2019 at 5:10:10 PM UTC-7, Benjamin Wright wrote:

How can you check if you are impacted?
This may vary based on how you implement your service but a good way to check is to verify that DTLS 1.2 shows up when you query for dtls in Wireshark. Lookout for a deprecation warning in a future release of Chrome.

Just as a warning as I spend some time to discover this: Wireshark will still show client hello with DTLS 1.0 in it. It's my current understanding that the client hello looks identical if a client only offers DTLS 1.2 (compared to an offer for DTLS 1.0 or 1.2). It's only when the server responds back with DTLS 1.0 only that the client side will bail.

[Dubois, Sean]

It is annoying, I ran into this in the record layer as well (incorrectly set it to 1.2 and broke some things).

 

However in the handshake itself you can trust the Version field! Servers ‘should’ assert that it == 0xfefd

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/fe3fd5bd-ff45-4094-9b13-1d167079288a%40googlegroups.com.

[Harald Alvestrand]

I believe the story of the weird handshake is that SSL had the client propose a version, and the server would respond with that version or any lower version.

When the need was seen to stop using some versions, the client hello was extended to include a list of acceptable versions - but since the installed base didn't understand the new extension, the client had to send a single fixed value in the client hello - and that version is DTLS 1.0 (or TLS 1.0 for the TCP-based case).

A lot of protocols have weird stuff that can only be explained (or excused, or begged forgiveness for) by looking at the protocol's history.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/C2FEF599-3CB6-4BE4-8333-7F1E90AE3ECE%40pion.ly.

[Philipp Hancke]

Is M81 still the target? There was a note on blink-dev about doing so for TLS 1.0

Discord hadn't updated but since Mozilla knows how to talk to people that got fixed easily:

  https://bugzilla.mozilla.org/show_bug.cgi?id=1608898

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAOqqYVFUTVo%2BsO6SXZqdMwJXNvmNBeaW0F8cErsQ02bNC%2BCz4w%40mail.gmail.com.

[Philipp Hancke]

Reminder: while this hasn't happened yet, you can (and should) simulate this using

  "--force-fieldtrials="WebRTC-LegacyTlsProtocols/Disabled/"

See https://bugs.chromium.org/p/webrtc/issues/detail?id=10539#c6

[gui...@webrtc.org]

Update: This is happening in M88.

Starting from M88, legacy TLS/DTLS versions will be disabled by default for WebRTC.

To enable these legacy protocols in Chrome 88 there are two choices:

1. Use   "--force-fieldtrials="WebRTC-LegacyTlsProtocols/Enabled/" from the command line.

2. Use the new WebRtcAllowLegacyTLSProtocols enterprise policy. Note that the policy is available since Chrome 87, but the legacy protocols will be disabled by default in Chrome 88.