Skip to main content

Managing Chrome's DTLS 1.0 Removal

Tim Steeves

Summary

Once Chrome removes support for DTLS 1.0, P2P connections from .NET, Cocoa, and Java prior to 3.7.5 will fail when negotiating with Chrome.

Updating the .NET, Java, and Cocoa SDKs to 3.7.5 is required to maintain 
P2P compatibility with Chrome.

We recommend updating as soon as possible to allow sufficient time for your application to propagate to your clients.

Go to our downloads page, to get IceLink 3.7.5.

Background

DTLS

DTLS is a variant of TLS for UDP streams instead of TCP streams. TLS is widely known and used for HTTP and WebSocket traffic, which use TCP. DTLS is less common, but useful for streaming data, which typically uses UDP.

In the context of WebRTC, DTLS is used to secure audio, video, and data connections. As soon as a connection has been established, before any data has been transferred, a short 4-way DTLS handshake takes place to establish a unique security context between the two endpoints.

At the time of this writing, DTLS has two protocol versions - 1.0 and 1.2.

  • DTLS 1.0 is based on TLS 1.1.
  • DTLS 1.2 is based on TLS 1.2.

TLS 1.1 is being slowly phased out of most Internet-connected systems in favour of the newer TLS 1.2 and 1.3 and their enhanced security features.

In a TLS/DTLS handshake, one side assumes the "client" role while the other assumes the "server" role. Which side assumes which role is managed by the use case. However the roles are assigned, the "client" sends the first handshake message and thus dictates the protocol version. The "server" can choose to accept or reject the handshake request based on the protocol version chosen by the "client".

Role Negotiation

In the context of WebRTC, the DTLS role is determined by the SDP offer/answer exchange. Each active media stream supporting DTLS includes a "setup" attribute in the SDP media description that has one of the following values:

  • active (indicates the DTLS client role)
  • passive (indicates the DTLS server role)
  • actpass (indicates either the DTLS client or server role, can only be included in SDP offers)

Typically, offerers use "setup:actpass" so the answerer can choose the role.

Chrome

In February 2020, Chrome 80 was released, which logs a warning to the console if Chrome offers a connection to IceLink or LiveSwitch, which still default to DTLS 1.0 in the DTLS client role:

  • This happens when an SFU or MCU connection is opened from Chrome to a LiveSwitch Media Server.
  • This happens when a LiveSwitch or IceLink P2P connection is opened between Chrome and either .NET, Cocoa, or Java if and only if Chrome is in the offering role (which depends on application code).
    • For example, the IceLink demo application puts Chrome in the offering role if it joins first.
    • For example, the LiveSwitch demo application in P2P mode puts Chrome in the answering role if it joins second.

The warning looks like this:

In case the image doesn't load, the text reads:

[Deprecation] Your partner is negotiating an obsolete (D)TLS version. Support for this will be removed in M81, around March 2020. Please check with your partner to have this fixed.

At the time of this writing, Chrome Canary 82 (82.0.4056.0) still logs the warning and does not abort the connection.

IceLink

IceLink connections can take on either the DTLS client or DTLS server role.

As of 3.7.4, in the .NET, Java, and Cocoa SDKs:

  • The default DTLS client protocol version is 1.0.
  • The default DTLS server minimum protocol version is 1.0.
  • The default DTLS server maximum protocol version is 1.2.
  • Answers to offers with "setup:actpass" use "setup:active" (DTLS client role).

Solution

It's only a matter of time before DTLS 1.0 is gone from Chrome, which means:

  1. When it is in the DTLS client role, it will only offer DTLS 1.2.
  2. When it is in the DTLS server role, it will only accept DTLS 1.2.

Since the DTLS role taken by IceLink connections is unpredictable, it can no longer offer DTLS 1.0 in the DTLS client role if it is to guarantee connections with clients that only support DTLS 1.2.

Starting with 3.7.5, in the .NET, Java, and Cocoa SDKs:

  • The default client protocol version is 1.2.

To regress to 3.7.4 behaviour:

  • Set Connection.DtlsClientVersion to DtlsProtocolVersion.Dtls10.

To progress to full DTLS 1.0 removal:

  • Set Connection.DtlsServerMinVersion to DtlsProtocolVersion.Dtls12.

Once Chrome removes support for DTLS 1.0, P2P connections from .NET, Cocoa, and Java prior to 3.7.5 will fail when negotiating with Chrome.

Updating the .NET, Java, and Cocoa SDKs to 3.7.5 is required to maintain P2P compatibility with Chrome.

We recommend updating as soon as possible to allow sufficient time for your application to propagate to your clients.

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request
Return to top

Articles in this section