Turn DTLS 1.0 back on to prevent sites breaking during Covid-19 traffic increase
Categories
(Core :: WebRTC: Networking, task, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox74 | --- | unaffected |
firefox75 | blocking | fixed |
firefox76 | --- | fixed |
People
(Reporter: drno, Assigned: drno)
References
Details
(Keywords: site-compat)
Attachments
(1 file)
47 bytes,
text/x-phabricator-request
|
jcristau
:
approval-mozilla-beta+
|
Details | Review |
In bug 1615445 we removed DTLS 1.0 and thus increased the minimum version of DTLS required by Firefox WebRTC to 1.2 to establish connections.
As seen here https://github.com/jitsi/libjitsi/issues/441 there are older versions of video conferencing services out there which still don't support DTLS 1.2. Unfortunately it is unknown how many installations are affected by this.
Given the huge spikes in WebRTC traffic thanks through the Covid-19 pandemic Chrome folks have decided to not continue with their removal of DTLS 1.0 on their end:
https://bugs.chromium.org/p/webrtc/issues/detail?id=11437
https://bugs.chromium.org/p/webrtc/issues/detail?id=10261
Given the temporary circumstance with Covid-19 resulting in huge spikes for WebRTC services around the world we should consider turning DTLS 1.0 back on again, to prevent services from breaking (even though they don't deserve to be supported any longer).
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 1•6 years ago
|
||
Assignee | ||
Comment 2•6 years ago
|
||
Comment 3•6 years ago
|
||
[Tracking Requested - why for this release]: The change has to be uplifted to 75 Beta.
Comment 4•6 years ago
•
|
||
I would like to raise the desperate question whether it's legal and ethical to (re-) introduce a severe security and privacy violation. Today it matters more than ever that sensitive business information is safe. If voice chats are about personal employee or customer affairs, DTLS 1.0 is a violation of Articles 25 and 32 GDPR. What is Mozilla's legal responsibility in case of merging and releasing an obvious security regression and privacy violation.
Comment 5•6 years ago
|
||
An unsatisfying and somewhat flip answer is that Firefox works in many jurisdictions that don't need to honor GDPR, and that since Firefox has the capability to do DTLS 1.2 if there's any GDPR violation it's on the part of the website that specified the use of the obsolete protocol. Since you're linking to a Chrome bug, are you aware that Google announced that they will also be delaying the release of the version (82) that will contain their fix?
Obviously we want to get there (see "don't deserve to be supported" opinion in comment 0) and are in fact active participants in the standards process that is demanding this change, but maybe the midst of a global pandemic isn't a good time to break compatibility? Balance.
Updated•6 years ago
|
Comment 6•6 years ago
|
||
This bug is tracked by a release manager but with a small severity so change it to major.
For more information, please visit auto_nag documentation.
Comment 7•6 years ago
|
||
TLS 1.0 will be re-enabled on Stable (bug 1623534) and Beta (bug 1623536). Nightly seems to keep the blue activate button.
DTLS 1.0 could be left disabled on Nightly or be disabled again after Jitsi has released their update. Please go ahead.
Assignee | ||
Comment 8•6 years ago
|
||
(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #7)
TLS 1.0 will be re-enabled on Stable (bug 1623534) and Beta (bug 1623536). Nightly seems to keep the blue activate button.
DTLS 1.0 could be left disabled on Nightly or be disabled again after Jitsi has released their update. Please go ahead.
Makes sense. I had considered that for my initial patch, but decided to first go with the easiest approach (not differentiating between release channels).
Assignee | ||
Comment 9•6 years ago
|
||
Try run for the updated patch https://treeherder.mozilla.org/#/jobs?repo=try&revision=843f6ea991b448281cf9a5f2d0dbb2a5a9d89ef7
Comment 10•6 years ago
|
||
Assignee | ||
Comment 11•6 years ago
|
||
Comment on attachment 9134276 [details]
Bug 1623511: turn DTLS 1.0 for WebRTC back on. r=ng
Beta/Release Uplift Approval Request
- User impact if declined: In Fx 75 we have DTLS 1.0 deactivated. But it turns out that there are still some services out there which don't support DTLS 1.2 yet. During the COVID-19 outbreak we should avoid breaking these working (while outdated) video conferencing service.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: No
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Different combination of the DTLS prefs have been activate over the last couple of weeks. No issues were found (except with DTLS 1.3 which this patch doesn't touch).
- String changes made/needed: N/A
Comment 12•6 years ago
|
||
bugherder |
Comment 13•6 years ago
|
||
Comment on attachment 9134276 [details]
Bug 1623511: turn DTLS 1.0 for WebRTC back on. r=ng
approved for 75.0b7
Comment 14•6 years ago
|
||
bugherder uplift |
Description
•