Closed mstyura closed 3 years ago
I am facing same problem, did you find the resolution ?
@nileshzarkar yes, it looks like I've just found a solution. I'll create corresponding pull request and ask maintainers for review in few days.
Thanks @mstyura .. I will be watching this issue , please keep me posted .. So where exactly is the compatibility issue in libjitsi or the bouncycastle.
So where exactly is the compatibility issue in libjitsi or the bouncycastle.
DTLS 1.2
is just not implemented in libjitsi
, yet.
Simple attempt to add support was blocked due to bug
in bc-java
.
Now bug is fixed, but no version with fix is published on maven yet.
Also, one of the maintainers of bc-java
stated, that package currently used by libjitsi
(org.bouncycastle.crypto.tls
) is in bug fix only state, which sounds like currently used package is deprecated and new package (org.bouncycastle.tls
) is recommend to use (it already does not have this bug).
So, the following steps could be done to add DTLS 1.2
support to libjitsi
.
org.bouncycastle.tls
, without adding new functionality. Will require code fixes, as well as fixes in pom.xml
across different repositories.DTLS 1.2
using API of new package org.bouncycastle.tls
.@lyubomir you are the author of initial implementation of DTLS
support in lijbjitsi
, does above steps sounds good to you or you see some problems?
Linking with #444.
@bbaldino from your comment I see that you've already done some work in that area, just letting you know there was some experiments in that area from my side - simple version increase (as well as adding certificate requests as required by TLS 1.2
) did not work due to bug in old API.
@mstyura good to know, thanks. If we/I get to that before anyone else, we'll know to focus on using the new APIs instead of trying to make 1.2 work with the current ones.
@mstyura @bbaldino
Can you please let me know by when can i expect this fix ? Since my current webRTC client development is completely stuck.
@nileshzarkar currently I'm working on ice4j
fixes which will reduce number of created/used threads, because now I have performance issues, probably due to number of threads Jitsi
and unrelenting libs create. Absence of DTLS 1.2
is not block me from deployment, but I hope to work on adding it on upcoming weekend. Of course I'll let you know here when anything is done.
Hi @mstyura
Any update on the fix for libjitsi ?
@mstyura When you say we have replace the org.bouncycastle.crypto.tls package to org.bouncycastle.tls package. Does it mean all classes belonging to org.bouncycastle.crypto.tls package ?
@nileshzarkar the original comment was by one of the authors of org.bouncycastle
, so as I understand it - yes, all classes from org.bouncycastle.crypto.tls
were deprecated in favor to org.bouncycastle.tls
. I apologize for not answering your previous comment, I don't have time to work on this issue and I'm not one of the maintainers of jitsi
project. Now I have hard time pushing other enhancements related to reducing threads usage into ice4j
.
This one might be relevant: https://webrtc-review.googlesource.com/c/src/+/125141
IIRC @bbaldino is tracking this with the M74 timeline in mind.
Hi @mstyura, @bbaldino Any update on the fix for libjitsi?
Putting more pressure on the developers is not going to help. This is being worked on.
We're definitely still keeping the M74 timeline in mind here. I looked at this again last week and we identified some complications with upgrading the BC version due to the way our maven poms were set up. That's (hopefully) fixed now and I'll be looking at this again today/next week, but the implementation itself will take more time.
My test shows that packages org.bouncycastle.crypto.tls.* works with DTLS1.2 - have to be updated to 1.61 (in maven already) Changes in libjitsi is just increase protocol version
protected ProtocolVersion getMaximumVersion()
{
return ProtocolVersion.DTLSv12;
Such changes fixes this https://github.com/jitsi/jitsi-videobridge/issues/798
@Kidav I think that If you want to use DTLS 1.2 with bc1.61, you need to make more some changes. Specifically, it is to add supportedSignatureAlgorithms to CertificateRequest and to change the export timing of keyingMaterial. (The PR above possibly be helpful, but it is so dirty code :pray:)
However, Chromium is likely to revert the changes(Drop DTLS1.0/1.1) on M74, and the Jitsi team is developing that using the new boucycastle API, so I think it would be better to wait for them. (https://bugs.chromium.org/p/webrtc/issues/detail?id=10261#c34)
https://bugzilla.mozilla.org/show_bug.cgi?id=1623258 Firefox 75 disabled DTLS 1.0 (currently Beta), Chrome wants, too.
https://blog.mozilla.org/security/2018/10/15/removing-old-versions-of-tls/ https://security.googleblog.com/2018/10/modernizing-transport-security.html
if this is about the jvb, jvb2 supports dtls 1.2 and the intention is to switch to that for the debian stable package. I believe there's consensus to release jvb2 as debian stable, it's just a matter of the right people finding the time to do it /cc @damencho
chrome is postponing such changes for now because everyone is busy. https://bugs.chromium.org/p/webrtc/issues/detail?id=11437
Sent a poke to nils Ohlmeier wrt firefox
@gpolitis do you have any idea how many instances are still using jvb1?
We have little time left to revert the removal of DTLS 1.0 in Firefox Beta 75 which is going to ship on 2020-04-07 https://wiki.mozilla.org/Release_Management/Calendar
We don’t collect installation data so we don’t know. JVB 2 hasn’t made it to our stable repository yet, but that should happen very soon.
Pushing back the DTLS removal from Firefox would be helpful. The JVB 2 may be almost ready to be marked as stable but it is not a drop in replacement for JVB 1. There are a number of feature differences and it has been primarily tested for the jitsi-meet use case. It also hasn't really been optimized for large meetings yet. We've run into a number of functional and performance issues in testing JVB 2 so we feel its not quite ready for production for our use cases (we support larger meetings and also run small conferences through the JVB). You can see more details here and here if you are curious
Is there a workaround for this? Or is it just broken for Safari and Chrome entirely?
is there a time frame for this to be part of a stable channel release ? Android Client and current firefox beta will not work without DTLS 1.2
libjitsi is not used anymore in jvb2. And jvb2 supports DTLS 1.2. We are working on updating the stable channel with the latest from unstable.
Can you give an estimate on when this would happen. Thank you 🙇
We are aiming this week ... as soon as possible, currently working on that.
FYI DTLS 1.0 has been re-enabled in Firefox Beta 75 https://bugzilla.mozilla.org/show_bug.cgi?id=1623511
We leave it off in Nightly as a reminder that when the world reaches a new normal we still plan to remove it eventually. This also allows for easier testing :-)
So currently jitsi supports DTLS 1.2? or its still using DTLS 1.0? What are the security pitfalls for using DTLS 1.0?
So currently jitsi supports DTLS 1.2? or its still using DTLS 1.0? What are the security pitfalls for using DTLS 1.0?
The JVB supports DTLS 1.2 (as of version 2.x), but we no longer use libjitsi there and don't plan to update libjitsi to support DTLS 1.2. Stable builds moved over to JVB 2 a couple weeks ago, so if you're up-to-date on stable you should be running DTLS 1.2.
JVB2 is out, and libjitsi now supports DTLS1.2 too.
WebRTC
does supportDTLS 1.2
, butlibjitsi
is only supportDTLS 1.0
. There is some old comment in code regardingDTLS 1.2
support which might be irrelevant anymore andDTLS 1.2
support could be added tolibjitsi
.