You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Add database → Connect to Server → WebDAV
Add a database stored by user alice, e.g. https://example.com/dav/alice/alice.kdbx
Add a database stored by user bob, e.g. https://example.com/dav/bob/bob.kdbx
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".
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.
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).
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:
alice
, e.g.https://example.com/dav/alice/alice.kdbx
bob
, e.g.https://example.com/dav/bob/bob.kdbx
Expected behavior
Databases of both users should be fetched independently and refreshed correctly.
Environment:
Additional context:
Caused by TLS session caching.
[Thanks, William and Marco]
The text was updated successfully, but these errors were encountered: