WebDAV: TLS Session Caching - Migration to NSURLSession Required

[CookieCrumb23]

I have two KeePass databases added via WebDAV (both are on the same Nextcloud Instance but under different users - if that matters).

If I open one of the databases and then try to switch to the otherI get an error:

There was a problem opening the database.

The operation couldn't be completed.
(com.MattRajca.DAVKit.error error 404.)

The workaround I have found is restarting the app. That will let me switch the database without a problem (and while it's a bit annoying I can make do with it).

If I can add any more info that would help you, I'll gladly oblige.

[mmcguill]

Thanks @CookieCrumb23, I'll take a look into this for you shortly.

[mmcguill]

Hi @CookieCrumb23 I can't reproduce this. I'm using a demo instance of Nextcloud with 2 different users pointing at the same or different databases. Both work fine. Is it self hosted nextcloud? Are you using a SNAP to install? Any other details helpful. If you feel comfortable with it, you could create a couple of demo accounts, test the same issue occurs and then provide me with access so that I could debug? Cheers, -Mark

[CookieCrumb23]

It's self hosted and I'm using a docker-compose setup. It's basically the one supplied by the nextcloud team as an example here. I'm running it with a lets encrypt certificate and it's only accessible via https. If that makes any difference.

And since I've apparently didn't mention it up to now, I'm using the iOS app on my newly bought ipad.

If you give me an email or something I can send you the credentials tothe two demo users I've set up and was able to recreate the issue.

[mmcguill]

For sure, could you send them to support@strongboxsafe.com

[mmcguill]

I've taken a look into this, was able to reproduce the issue with @CookieCrumb23 help. The problem appears to be due to Apple's TLS Session Caching and the use of NSURLConnection in the DavKit library.

TLS Session caching is based on the URL, in this case the URL will be the same and so both connections (despite having different credentials) will end up using the same underlying TLS Session. This in turn means that the Nextcloud WebDAV server does not know that the credentials have changed, it is the same session to it.

Even more unfortunately, there is no way to clear the TLS Session Cache outside of a 10 minute wait or killing the process (which as you've noticed works for you).

NSURLConnection is a deprecated method of connecting and the replacement NSURLSession allows you to isolate this TLS Session cache, and thereby would not have this issue. NSURLSession comes with other benefits too, so the right solution here is to migrate the DavKit code to use that instead of NSURLConnection... This isn't a super trivial task unfortunately, but let's use this issue as the tracker for that task... I'll modify the topic here accordingly.

Some handy links/info: https://stackoverflow.com/questions/13369386/how-to-cancel-a-persistent-connection-using-nsurlconnection/13373392 https://developer.apple.com/library/archive/qa/qa1727/_index.html

[mmcguill]

@CookieCrumb23 I've thought of another option/workaround that might work for you. Basically the TLS session cache uses the host name as the key for its cache. If you could setup another hostname/sub domain, for your second account that should work to eliminate this session caching issue... not sure if that's an option?

[hermelin44]

Is there any progress on this issue? We have multiple keepass databases on a single webdav server and setting up a hostname for every database is not really an option. In my opinion webdav is the best option for sharing keepass databases with multiple users so I'm wondering why this issue has such a low priority. Thank you in advance!

[strongbox-mark]

Hi @hermelin44 - No progress. It's still on the list, but it is low priority and a big change so it's hard to schedule. Why not use a single login for WebDAV but different locations for each user? Could you do that?

[hermelin44]

Hi @strongbox-mark , currently every user has its own login, as there are also other private files on this webdav server. Of course, it would technically be possible to use an additional account for all the keepass databases, but it’s not really a clean solution, as everyone would have access to all the keepass databases not belonging to him.

[strongbox-mark]

I see, understood. I'm afraid we don't have to resources to look into this for at least the next few months unfortunately.

[Hiltiprant]

I also experienced this issue when recently configuring Strongbox. Are there any updates on this?

@strongbox-mark I tried your suggestion using another subdomain to access the nextcloud instance (e. g. sb.server.com instead of nc.server.com) but this throws an error that the certificate is not valid. After enabling the option for non trustable certificates the same error (404) appears again, also after restarting the app.

[strongbox-mark]

Hi @Hiltiprant - no updates here just yet. A 404 error would indicate something other than a certificate error. I'd triple check my configuration, you may actually be successfully hitting the server/subdomain but be getting something else wrong like the full URL/path etc. The 404 is coming from your server subdomain so you have established comms successfully.