docker-jitsi-meet
docker-jitsi-meet copied to clipboard
SSL/TLS error between JVB and Prosody after upgrade to latest
Hi there!
I'm having issues after upgrading from 6433 to 8252.
JVB is throwing the following error:
[hostname=jitsi-prosody id=shard0] MucClient.lambda$getConnectAndLoginCallable$9#640: Error connecting:
org.jivesoftware.smack.SmackException$SecurityRequiredByClientException: SSL/TLS required by client but not supported by server
at org.jivesoftware.smack.AbstractXMPPConnection.connect(AbstractXMPPConnection.java:532)
at org.jitsi.xmpp.mucclient.MucClient.lambda$getConnectAndLoginCallable$9(MucClient.java:635)
at org.jitsi.retry.RetryStrategy$TaskRunner.run(RetryStrategy.java:167)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
I've noticed that ALLOW_NON_SECURE is no longer available since sip-communicator.properties have been deprecated, and there is no other way to pass this as an Env variable.
I had a quick glance at the MucClient.java class in Jicoco and there is another property called SECURITY_MODE but I'm not sure if that can disable TLS. Anyway, in the current docker image there is no way to pass that value either.
Any suggestions? Maybe ALLOW_NON_SECURE should be brought back to life?
Are you running the stock compose setup?
I had a quick glance at the MucClient.java class in Jicoco and there is another property called SECURITY_MODE but I'm not sure if that can disable TLS
That's exactly what the property is for. You can set it to disabled
, required
or ifpossible
in jvb.conf
(e.g. videobridge.apis.xmpp-client.configs.shard0.SECURITY_MODE = "required"
) . It defaults to ifpossible
when connecting to localhost and required
otherwise, so I expect you're connecting to a different host. Make sure disabling TLS really is what you're looking for.
The cross container traffic goes through the user defined network, so it was always disabled before.
Now, when I released the current stable I didn't change anything in this regard and it did work.
@diegomoreira001 Did you re-create the containers?
@saghul , just answering your first question: I'm not using docker-compose, im using K8s to support 3000 concurrent calls and same amount of recordings.
JVB and Prosody are deployed in different pods, so they dont share localhost. However, they are inside the same VPC, meaning that there is no need for TLS.
I have ddded SECURITY_MODE to jvb.conf as suggested by @bgrozev and that solved the issue. :)
The fix here is to simply expose the property so that its value can be passed thru Env.
I changed jvb.conf in rootfs/defaults and added the paremter declaration
{{ $SECURITY_MODE := .Env.SECURITY_MODE | default "" -}}
And used it here:
{{ $SERVER := splitn ":" 2 $element }}
shard{{ $index }} {
HOSTNAME = "{{ $SERVER._0 }}"
PORT = "{{ $SERVER._1 | default $XMPP_PORT }}"
DOMAIN = "{{ $XMPP_AUTH_DOMAIN }}"
USERNAME = "{{ $JVB_AUTH_USER }}"
PASSWORD = "{{ $ENV.JVB_AUTH_PASSWORD }}"
MUC_JIDS = "{{ $JVB_BREWERY_MUC }}@{{ $XMPP_INTERNAL_MUC_DOMAIN }}"
MUC_NICKNAME = "{{ $JVB_MUC_NICKNAME }}"
SECURITY_MODE = "{{ $SECURITY_MODE }}"
DISABLE_CERTIFICATE_VERIFICATION = true
}
{{ end -}}
Id love to create a pull-request but actually this fix is lacking null-safety and is not compatible with the Code in Jicoco's MucClient and I'm not well versed in this scripting syntax, sorry about that.
The correct way to do it would be:
- Default value for this property should be null.
- SECURITY_MODE shouldn't be set if $SECURITY_MODE is null. That way Jicoco will apply its default.
Im guessing the correct code should be:
{{ $SECURITY_MODE := .Env.SECURITY_MODE | default "" -}}
And:
{{ $SERVER := splitn ":" 2 $element }}
shard{{ $index }} {
HOSTNAME = "{{ $SERVER._0 }}"
PORT = "{{ $SERVER._1 | default $XMPP_PORT }}"
DOMAIN = "{{ $XMPP_AUTH_DOMAIN }}"
USERNAME = "{{ $JVB_AUTH_USER }}"
PASSWORD = "{{ $ENV.JVB_AUTH_PASSWORD }}"
MUC_JIDS = "{{ $JVB_BREWERY_MUC }}@{{ $XMPP_INTERNAL_MUC_DOMAIN }}"
MUC_NICKNAME = "{{ $JVB_MUC_NICKNAME }}"
{{ if neq $SECURITY_MODE "" }} // I have no idea if neq actually exists hahah
SECURITY_MODE = "{{ $SECURITY_MODE }}"
{{ end }}
DISABLE_CERTIFICATE_VERIFICATION = true
}
{{ end -}}
Thanks for the confirmation @bgrozev on that property
Cheers!
Hum, interesting. Even if your setup is different then the current compose would also be broken since they don't communicate via localhost.
@saghul yup, and just adding a bit more info, the same applies to Jibri.
Had to add an overlay on jibri.conf with the following: security-mode = "{{ $SECURITY_MODE }}"
I cannot replicate that on the Compose based setup. We already set DISABLE_CERTIFICATE_VERIFICATION
which should be enough.
Did you make any changes to the images?