currently using a Nextcloud AIO installation on x386 64-Bit hardware and nginx reverse proxy.
Due to security reasons, I would like to use mTLS authentication for all Nextcloud services/apps besides the talk app which should be open for anyone provided with a link.
Unfortunately I did not find any GUI-config or config file to set the base URL for the talk app, as it has only a relative path added to the base-URL of the Nextcloud installation.
Talk chat URLs always follow a scheme http://mydomain.tld/call/abcd123f - you could try to exclude the path from mTLS enforcement. I don’t have high expectations as Talk is not a stand-alone product but loads scripts and data from “core” Nextcloud - this would likely fail in such setup… latest if one shares a document (which is basically a regular share) it will brake. Maybe running another chat/conferencing tool like Mattermost without mTLS and using a Talk bridge is easier…
I don’t think there is a way to allow only Talk using another domain. As far I understand you are trying to allow anonymous access to Talk while enforcing mTLS for the rest of the instance. In general I think mTLS is much more complex to operate (think about mobiles and device replacement) and doesn’t significant improve security when you already follow best practices like frequent patching and MFA. If you really have to use mTLS you likely don’t want anybody else to access this instance.
thanks for your input - yes you got me right and what you say about going for another solution might be easier as I read a lot about Talk’s app integration and would not expect it to work with the mTLS exclusion, too.
Sad, though as I would disagree with you on use of an additional layer of security, but that’s not the point.
I was running a jitsi installation for some years now, where a guest-url was implemented really early on the project (for bypassing authentication in the first place), but I really would like to focus on one product and the AIO solution of Nextcloud.
I will keep this thread open for now in case anybody still has an idea and will give the mTLS exclusion a try. But I share your expectation for a broken talk app…
I can understand your approach. But I wouldn’t hold out much hope overall. Most Nextcloud users use either username/password or 2FA for normal authentication from web-based access to Nextcloud. Client-side certificates tend not to be used, so your approach of separating the Nextcloud and Nextcloud Talk domains is rather irrelevant.
I would be happy if you could deactivate 2FA for certain IP ranges such as internal IP ranges and otherwise activate it. But that doesn’t seem to be possible either. Although neither 2FA nor client-side certificates help against malwar
I think most users with your security requirements would rather use 2FA such as TOTP for normal users. This is sufficiently secure and also far easier to implement than client-side certificates.
Nextcloud in fact doesn’t provide conditional MFA but you can easily add a single-sign-on system like Keycloak, Authentik, Zitadel or other which a more flexible and provide more sophisticated login control e.g. conditional MFA based on geo-location. Definitely this add complexity but depending on you config especially if you run multiple applications this could even improve user experience.