jitsi
Content-Security-Policy tightening
As discussed here with @saghul I'm opening this new issue to track the Content-Security-Policy which is needed for JME 2.1.x to work with nginx.
I'm using jitsi-meet on my own server with nginx and all stable packages up-to-date. We use the macOS version of JME as clients.
I found out trying that when completely deleting
frame-ancestors
default-src
script-src
from the CSP then the new version 2.1.x starts working again. But I guess that is not a very safe setup. The current one working is this one:
add_header Content-Security-Policy "img-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; font-src 'self'; object-src 'none'; base-uri 'self'; form-action 'none';";
add_header Feature-Policy "geolocation 'none'; camera 'self'; microphone 'self'; autoplay 'none'; accelerometer 'none'; autoplay 'none'; payment 'none';";
I tried a few combinations, but even
default-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline'
did not work.
I don't know about all Content-Security-Policys and their values that have to be added to work without removing all of the above.
It would be nice if anyone could help out finding the safest working setup for this and afterwards the documentation could be updated to help others out.
Thanks a lot
We found the following CSP to work fine (with JME 2.1.x, Mac and Linux, as well as browser clients):
Content-Security-Policy: default-src 'none'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; base-uri 'self'; connect-src 'self'; font-src 'self'; frame-src 'self'; img-src 'self' data:; manifest-src 'self'; media-src 'self'; form-action 'self'; worker-src 'self' blob:
Thanks for sharing! Doesn't that prevent the loading of remote avatars for example?
True. I consider that a "feature", because it's difficult to disable remote avatars otherwise. However, it shouldn't be difficult to add an avatar source to the img-src policy.
Not difficult at all: https://github.com/jitsi/jitsi-meet/blob/974ef4a3827d9ff690b51f2e38e14643299d05ae/config.js#L354
Oh, all right. I had read somewhere that this setting would disable more than just the remote avatars (usage of STUN/TURN servers, I believe), but that may have been wrong. In that case, ignore my last comment :-)
Thanks for the updated CSPs and the updated JME versions. They work for us, too.
But what can be done with JME (or jitsi-meet) to make the setup safer? Using
default-src 'none'
or even more
script-src 'self' 'unsafe-inline' 'unsafe-eval'
are pretty insecure.
If there is nothing that can be done in JME or jitsi-meet how can only the URLs be specified that need the insecure config and the rest could go with 'self' only? For another webapp as an example on our server the solution was to specify
script-src 'self' https://code.jquery.com/ 'unsafe-inline'
but I don't know which URLs would have to be used here.
Thanks
Quick update. We rely on some WASM libraries, which as of now require unsafe-eval. This is unfortunate but there is nothing we can do until browsers implement WASM specific CSP policies.
There are news on this: PR #617 will help, because you can at least replace the unsafe-eval of script-src with the wasm-equivalent.
script-src 'self' 'unsafe-inline' 'unsafe-eval'
with
script-src 'self' 'unsafe-inline' 'wasm-eval'
Obviously this only works in the electron app for now as wasm-eval is not yet available in Chrome.
L: The CSPs and permission policies (replaces feature policy) that work for us are these (jitsi.artemislena.eu being our domain, Safari needs that because apparently, if the scheme changes from https: to wss:, it's not 'self' anymore, though for other browsers it is):
Permissions-Policy "accelerometer=(), ambient-light-sensor=(), autoplay=(), battery=(), camera=(self), cross-origin-isolated=(), display-capture=(self), document-domain=(), encrypted-media=(), execution-while-not-rendered=(), execution-while-out-of-viewport=(), fullscreen=(self), geolocation=(), gyroscope=(), keyboard-map=(), magnetometer=(), microphone=(self), midi=(), navigation-override=(), payment=(), picture-in-picture=(), publickey-credentials-get=(), screen-wake-lock=(), sync-xhr=(), usb=(), web-share=(), xr-spatial-tracking=()"
Content-Security-Policy "default-src 'none'; img-src https: data:; media-src 'self' data:; connect-src 'self' wss://jitsi.artemislena.eu; manifest-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; worker-src 'self' blob:; style-src 'self' 'unsafe-inline'; base-uri 'self'; form-action 'none';"
Note: This won't allow loading remote avatars, probably (guess that uh, needs https: in img-src? Don't even know how to test that), also, I'm not quite sure if we need data: in media-src, because only FF complained about it, and it didn't seem broken either way (well, it was a bit broken, but uh, we didn't test on vanilla FF, but Tor Browser, which apparently doesn't support mic and webcam).
Edit: Apparently the Element embed uses remote avatars, and yeah, simply replace 'self' with https: in img-src. Fixed the CSP above. Also, possibly unrelated, but you may want Access-Control-Allow-Origin "*" on the Jitsi domain for embeds in Matrix clients to work.
Just wondering if there is any further advice concerning this topic, especially to avoid the potential security hole "unsafe-online". Is this more or less "dangerous" for a videoconference application than another different web application. I appreciate that Javascript is the common denominator. Regards, Martin
I have never heard of unsafe-online. What is dangerous about it? Any resources you can share to learn more?
Ah, I don't think it would be possible to disable since we run inline scripts on index and also inline styles.
I have been reading up about CSP where inline-unsfe options are considered "bad" . Work-a rounds have been suggested (in general) but I won't go into detail as my understanding is poor.-Perhaps others in the community have ideas. Many thanks for your respons. Martin