Chrome Removing Support for DTLS 1.0 (LSC)

Recently the Google Chrome team took a swift step forward towards deprecation of support for DTLS 1.0 - a secure communications protocol designed to allow applications to securely pass data between each other without possibility of 3rd party access to the data.

In February 2020, Chrome 80 was released which decisively announces this breaking change with a new log warning to the console if Chrome offers a connection to LiveSwitch clients.

• An SFU or MCU connection is opened from Chrome to a LiveSwitch Media Server.
• A LiveSwitch or IceLink P2P connection is opened between Chrome and either of our .NET, Cocoa, or Java SDKs if and only if Chrome is in the offering role (which depends on application code).

We've been monitoring this situation closely, and at the time of this writing, Chrome Canary 82 (82.0.4056.0) still logs the warning and does not abort the connection.  Anecdotally, based on Chrome's typical update cadence, it is likely that M82 will release the last week of April 2020.

So, it's only a matter of time before DTLS 1.0 is gone from Chrome and some handshakes start to break while others become more secure with DTLS 1.2.   While the team at LiveSwitch readily releases timely patches for all of its client SDKs, server-side products, and cloud media server, where does that leave the legions of developers that built on top one of the open source WebRTC projects or libraries out there?  They had better be on their toes - so to speak.  Without a team dedicated to continuously monitoring the browser landscape for breaking changes like this, their customers will inevitably face unplanned downtime and losses.      

If you would like to dive deeper into the details of the DTLS 1.0 deprecation and learn more about specific measures your development team is strongly recommended to make prior to this action, go ahead and read the LiveSwitch community announcements outlining the potential impacts and solutions.