Cannot use different WebDAV credentials for the same host

[keepassium]

Description If the user adds several DBs that are stored on the same WebDAV server, but under different user accounts, only one of these accounts will be used for all the connections.

How to reproduce Steps to reproduce the behavior:

1. Add database → Connect to Server → WebDAV
2. Add a database stored by user alice, e.g. https://example.com/dav/alice/alice.kdbx
3. Add a database stored by user bob, e.g. https://example.com/dav/bob/bob.kdbx
4. Adding the second database fails with "404: not found" error.
   • If it does not fail immediately, after adding the second database open its "File info".
5. Bonus: Refresh the Databases list, observe that server logs state the only user trying to connect is Alice.

Expected behavior Databases of both users should be fetched independently and refreshed correctly.

Environment:

• Device: any iPhone
• OS: 17.4.1
• App Version: 1.51.147, 1.52.148

Additional context: Caused by TLS session caching.

[Thanks, William and Marco]

[keepassium]

Huh, this is a reincarnation of #295…

[keepassium]

As mentioned above, the issue is caused by TLS (transport layer security) session caching in system's code. All the TLS stuff is abstracted away deep in the system code and there is no way for an app to flush or disable that cache.

As a solution, Apple suggests to create a separate URLSession instance for each connection. Considering that each URLSession maintains its own TLS session cache, independent sessions would avoid caching problem.

Unfortunately, this solution does not seem to work. Even when KeePassium uses a different URLSession for each URL, it receives correct responses for both files only the first time. After that, one of the responses returns status 404.

Interestingly, the behavior differs among the tested WebDAV services. Synology WebDAV server and koofr.eu work normally, returning different files for different users, even if using the same shared URLSession for all connections. In contrast, woelkli.com ends up with the error even if using separate connections. Apparently, server-side caching is also involved in some cases.

The only sure-fire solution I see would be to replace URLSession with some custom OpenSSL-based implementation. This is complicated and can be justified only for networking-focused apps like file managers and browsers. For a password manager, however, this is way too much trouble for solving such a narrow-niche issue.

This leaves us with the following workarounds offered by Apple in the linked article:

• Consider configuring your server to listen on different ports. Then use a different port number for each connection. (Port number is part of the TLS caching key.)
• If you have control over server's DNS, configure different connections to go to different subdomains, e.g. alice.example.com and bob.example.com.
• Append a dot (.) to the host name of the second connection, e.g. example.com/file and example.com./file. This ends up as a different caching key, too. This is the only method that does not require control over server configuration, but it is limited to two connections only (we cannot add a chain of dots).

See also:

• Why is a HTTPS NSURLSession connection only challenged once per domain?