[Bug]: TLS MITM-compromise UX-response needs URGENT fix

[cluck]

⚠️ Before submitting, please verify the following: ⚠️

• This is a bug, not a question or a configuration issue.
• This issue is not already reported on Github (I've searched it).
• Nextcloud Server and Desktop Client are up to date. See Server Maintenance and Release Schedule and Desktop Releases for supported versions.
• I agree to follow Nextcloud's Code of Conduct

Bug description

The Nextcloud desktop client keeps popping up a "Untrusted Certificate" dialog with an option to "Trust this certificate anyway" on MITM attacks on the TLS connection, usually when the user expects it the least (that is, the user is not actively configuring a connection). A fix needs to be implemented in a timely manner (which is the "new" aspect of this report).

The bugtracker keeps accumulating complaints about this situation (with good analysis, e.g. #5396). Surprisingly, these issues remain stuck in "needs triage", while none of them mention any roadblock or pending clarification.

The current UX is very detrimental to security as these popups are frequently triggered on Public WiFi and visited corporate networks where untrusted MITM-Proxies hijack all sorts of connections. People tend to click the Nextcloud warning away, just to see it re-appear shortly after (e.g. when they roamed to a different hotspot). Being annoyed by the interruption (and from not being able to "solve" the issue anyway), a preferred reaction is to tick the "trust this certificate anyway". At this point the client will happily leak the authentication credentials to whatever MITM-proxy is presenting itself; possibly revealing cleartext credentials, Kerberos tickets or client tokens.

As an Admin, I can't even contain the risk by moving the Nextcloud server into a VPN, as this would just create more popups on the client while the VPN is unavailable.

The current UX is just insecure by design. This is in stark contrast with anything mentioned at https://nextcloud.com/secure/. I can not emphasize enough how this needs urgent development.

#6896 from Jul 9, 2024 (when behind a captive portal with no internet access dozens of popups appear (untrusted certificates))
#6517 from Mar 7, 2024 (Connection error notifications keep popping up when offline)
#6388 from Jan 28, 2024 (Client repeatedly nags about unreliable certificate)
#5967 from Aug 13, 2023 (When remote certificate is invalid, client refuses to cancel attempts for connection)
#5396 from Feb 5, 2023 (Invalid SSL cert pops warning every minute, encouraging unsafe choice)
#3347 from May 21, 2021 (Many popups asking whether to trust a server certificate)
#2702 from Dec 13, 2020 (Option (in client) to automatically reject self signed certificates?)

Steps to reproduce

See linked issues.

Expected behavior

We have a necessity to gain two configuration options in nextcloud.cfg to:

• disable the possibility to "trust this certificate anyway"
• silence these popups completely: just have the client silently retry the connection until the certificate turns valid/trusted again

Which files are affected by this bug

src/

Operating system

any

Which version of the operating system you are running.

any

Package

Distro package manager

Nextcloud Server version

29.0.6

Nextcloud Desktop Client version

3.13.3

Is this bug present after an update or on a fresh install?

Updated from a minor version (ex. 3.4.2 to 3.4.4)

Are you using the Nextcloud Server Encryption module?

Encryption is Enabled

Are you using an external user-backend?

• Default internal user-backend
• LDAP/ Active Directory
• SSO - SAML
• Other

Nextcloud Server logs

No response

Additional info

No response

[cluck]

What is the progress here?

(Related #7191)

[cluck]

Has this security nightmare any priority at all.
Maybe @camilasan can forward this to who needs to know.

[kubrickfr]

I wonder how this is going to be affected by this new commitment of theirs #7778

[Anuril]

It sure looks like security is not a concern of this company...

[Rello]

Hello,
we do care about security, thats why we have this warning which is absolutely correct at the beginning.
What we will look into is to add e.g. a "skip for this connection" option.
Storing the invalid certificate in memory and not show the warning again for the same one.

If the user would roam to a different wifi with a different cert, it would of course show up again because its a changed connection.

What is your opinion on this proposal?

[kubrickfr]

What is your opinion on this proposal?

The world in which this warning and dialog were a good option is long gone.

Nobody in their right mind would use self-signed certificates nowadays, browsers go out of their way to make it difficult for users to accept insecure certificates, which they very much are.

Today, everyone can get free TLS certificates that offer better security than any self signed certificate could offer without a lot of efforts and opportunities for critical errors: CRLs, transparency reports, auto renewal, key rotation, etc.

If someone or some organisation want to go down the path of managing their own certificate authorities, they very much can, and the right way of doing it is to add the authority to the users certificates stores, but never ever should we temp the user to click Accept to make the problem go away.

This warning is just an open door to MITM attacks. It means that when my users go on a WiFi with a captive portal, if they click on accept, they will send to the whoever controls the network their cookies and session id, potentially even passwords.

So, with all due respect, there is no making this better, it needs to be removed whole, and certificate errors need to be treated as errors, nothing else.

[kubrickfr]

Also, this error is transient most of the time, there is really no more reason to warn the user about it with a big dialog than there is when the connection is down for any order reason.

The app just needs to be in a disconnected state, and if the user opens the app, we can show an error message saying: impossible to connect to the server: invalid TLS certificate.

[72Zn]

This is neither a bug nor a security issue. It could be a feature request. But this here should just be closed and any discussion I see here is pointless. You can't protect every user from their own stupidity. If someone clicks on a phishing link in a phishing mail you don't complain to the authors of the mail client do you?

Self-signed certificates especially in backend and private networks is pretty much still a very big thing and has it's valid use cases. Most home routers usually come with self-signed certs e.g., but that's just one example.

The way it's done here is exactly the same as for example in ssh, where you get a similar notification if the server key has changed. I don't see anybody crying about that and accusing the ssh authors of not caring for security. This is just ridiculous.

If your users blindly click on every "do you accept" message with prior proper warning, the problem is not the software, the problem is you and your users. Maybe do some educating.

The only improvement I could see here would be to make the warning more "threatening" and add something like "only click accept if you are absolutely sure ...". But if I want the client to connect, I want it to connect, don't tell me what I can and cannot do. There must never be "I'm sorry Dave. I'm afraid I can't do that".

This is open source. If you feel it doesn't comply with your "standards", fork it, implement a "better" solution, and make a pull request. Don't insult and harass the developers.

Devs, just close this.

[Rello]

Hello,

we will evaluate and confirm some parts of this discussion

• if the server submits a HSTS header, there should be now way to accept => client pauses
• without the HSTS, the user can decide
  • the decision of the user will be remembered for this connection to avoid the mentioned repeated questions

[kubrickfr]

@72Zn The examples you mention are extremely valid and strengthen my point:

Self-signed certificates especially in backend and private networks is pretty much still a very big thing and has it's valid use cases. Most home routers usually come with self-signed certs e.g., but that's just one example.
The way it's done here is exactly the same as for example in ssh, where you get a similar notification if the server key has changed. I don't see anybody crying about that and accusing the ssh authors of not caring for security. This is just ridiculous.

These use-cases are intended for expert users. Nextcloud desktop client users are not expected to even know what a certificate is.

[kubrickfr]

* if the server submits a HSTS header, there should be now way to accept => client pauses
* without the HSTS, the user can decide
  * the decision of the user will be remembered for this connection to avoid the mentioned repeated questions

I had not thought of that, that is a brilliant idea! It would definitely make me very happy ❤

[72Zn]

For corporate setups I could imagine a client configuration setting like "allowSelfSignedCertificates=true||false" that prohibits or allows clients to connect to servers with invalid or self-signed certificates. That could be enrolled using client management systems.

[cluck]

The HSTS idea is good, it solves the pressing issue by offering control from the server.

I think the various comments, which I appreciated greatly, touch two different areas worth mentioning.

Domain validated (DV) certificates

DV policy is what modern Browsers enforce and is what all TLS/SSL libraries implement by default.

It basically boils down to

• the issuing CA should be in a almost-static CA trust list on the client,
• the CA should issue certificates only to holders of the DNS names reported in the subjectAltName of the issued certificates,
• the certificate should contain a matching subjectAltName for the DNS name that is being connected to.

Let's Encrypt, Zero SSL etc offer DV certificates.

On the NextCloud Desktop we can't enforce domain validated level of connections, because the default is to allow users to easily accept any certificate that gets interjected, especially those that clearly fail DV validation. Not only are users allowed to accept them (like Browsers allow you to click through to temporarily accept certificates after big fat red warnings), the users are actually encouraged to accept them, which is very counter-productive. And unlike browsers, the Desktop Client resurfaces from the background to interrupt the user pro-actively, while a Browser tab would just stop working while unattended by the user.

Self-signed certificates

From a TLS/SSL library perspective, all CAs in a CA trust list represent the same policy. To enforce a different policy, the library can be pointed at a different CA trust list. A self-signed certificate represents a valid CA trust list.

For the standard DV policy, self-signed certificates are "just" additional CAs that (ideally, but please read on) should be added to the computers or users CA trust store. An in-house enterprise CA is working the same: their root certificate must be installed to the computers for their certificates to be recognized as valid.

If you want to depart from the DV policy, NextCloud would need to offer a per-connection CA trust list that (a) supplements or (b) replaces the computers/users CA trust lists. This would allow for using a CA with NextCloud without touching the computer/user CA trust list (case a) or implement a custom policy (case b). In parts we already have this, as it is possible to define a certificate with the connection. But, similarly to the difficulty to sticking to a DV policy, the unfortunate UX easily compromises the trust list.

So, having zero pro-active user-interruptions under DV policy should always be an option, not only with HSTS. The necessary UI to temporarily accept an invalid certificate should be available, if at all, in the settings, for users to find it if they're looking for it.

The same option is also necessary for other policies I can think of (TPM-bound, in-house CA, certificate/CA/vendor pinning), thus making it gererally available would be a step in the right direction.