Support mutual TLS auth

[zebardy]

Hi,

I have a deployment of next cloud behind a reverse proxy which secures the connection via mutual TLS with client certs. Supporting this would require extending com.owncloud.android.lib.common.OwnCloudClient to support mutual TLS authentication and loading a keystore containing the cert to use.

[tobiasKaminsky]

On Android Files app we do support accepting self-signed certs.
As this information needs to be stored somewhere, I think it is the responsibility of the app using this library to handle it correctly.
Or do I misunderstand something?

[tobiasKaminsky]

@zebardy can you reply please?

[zebardy]

I think what I was looking at was extending the com.owncloud.android.lib.common.OwnCloudClient similar to this https://callistaenterprise.se/blogg/teknik/2011/11/24/android-tlsssl-mutual-authentication/ and then allowing applications consuming the library to pas in their own keystore. However I'm trying to look at other ways around this. Is there an approach you would recommend? My time has been shorter than I had anticipated of late. Thanks for looking at this and taking the time to respond.

[tobiasKaminsky]

Ah, now I get it.
I see two ways:

• implement it in your app directly by extending the client
• provide an extension to this library

As we currently do not need this, there is no plan to include it.
However this might be a nice feature for other apps using our library.

[zebardy]

If the approach sounds sensible, then it may be something to work on in a fork and submit as a PR. I was ultimately looking to support mutual TLS in the nextcloud app, and starting from the client library upwards. Supporting this in the client library would also allow for other apps or tools to make use of this.

[zebardy]

I've finally had some time over Christmas to work on this. I'm looking at making use of the android keystore (https://android-developers.googleblog.com/2012/03/unifying-key-store-access-in-ics.html) to prompt the user to select a key stored in the system key store (no need for the app to handle storing keys or for new UI elements). This would mean that users would have a similar experience to using chrome etc when a client cert is required.

Further references:-

• https://medium.com/@_kbremner/android-and-client-authentication-fd416af19a04
• https://github.com/aosp-mirror/platform_packages_apps_email/blob/master/emailcommon/src/com/android/emailcommon/utility/SSLUtils.java
• https://github.com/aosp-mirror/platform_packages_apps_email/blob/c28e36dbaaff7d2b4641ab0d86f1309a418437e7/emailcommon/src/com/android/emailcommon/utility/EmailClientConnectionManager.java#L107
• https://github.com/aosp-mirror/platform_packages_apps_email/blob/c28e36dbaaff7d2b4641ab0d86f1309a418437e7/emailcommon/src/com/android/emailcommon/utility/SSLSocketFactoryWrapper.java#L37

[zebardy]

Hi, so I have a proof of concept working ( zebardy/nextcloud-android-library@zebardy:05edb6f6357d00a5fe1d17bed816690a8c83b741...zebardy:3325819c1de6c2b9b7105638296ef8b12cb6a0e2 ). It's not a pull request yet. It's got some hacky parts & lots of debug comments. However it works. I had to make some changes to the way that the nextcloudclient kotlin code works. OkHttpClient is not really designed to be subclassed. Doing this made things really challenging due to the private or package level classes in the OkHttp package. This made it impossible to access or set the variable I needed. So I ended up moving it away from subclassing.

The associated changes to the android app are ( https://github.com/zebardy/nextcloud-android/compare/zebardy:9c83e0cea3d7d318a9a11de56bec49c1ccbb520c...zebardy:858f2ccd06d1defdc9f8bc5981c99710f96ff911?diff=unified#diff-587dc61f19cacc80fdba456dee2cfeea ).

In both cases please ignore my changes to the gradle and build scripts, these are all associated with getting things running on my setup and need cleaning up.

[AndyScherzinger]

@tobiasKaminsky is AFK right now but can hopefully reply later today/this week. ❤️

[zebardy]

Hi,

Any thoughts regarding this? I think i've found a bug where the kotlin code using okhttp looses the client cert after a while. Need to figure out how to capture the exception as it happens after a period of use on my phone.

Would be grateful for feedback and/or suggestions.

Thanks

[tobiasKaminsky]

Cert usage should be now back in, even with newest v2/okhttp.

[zebardy]

Appologies, can you expand on your reply. I'm not quite sure what you mean, so I'm probably missing some context.

[tobiasKaminsky]

Ah. Sorry. I was misreading this.
I was talking about a problem in okhttp which did not checked/used self-signed certs.
But this is about client certs.

Can you provide me with a test account?