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?

[zebardy]

Unfortunately it's challenging for or me to provide you with a test account on my setup at the moment. I can provide information and help for setting up your own test setup. All that is needed is an nginx reverse proxy handling the TLS infront of a nextcloud instance. The tricky bit is creating/setting up the CA and signing the server and client carts. I have some openssl commands that should allow you to generate just enough of the pki for testing.

[tobiasKaminsky]

This would be enough, I guess :-)

[zebardy]

Hi,

sorry this took a while. Got back from leave and COVID-19 hit. This information should be enough to generate all of the keys & certs and configure an nginx proxy with mutual TLS auth. This is laid out for a the reverse proxy listening on 443 and forwarding to a nextcloud instance listening on port 80 on the same machine. Shouldn't be too hard to create a sidecar container from this to similar for nextcloud running containerised.

Hope this helps. Let me know if there is anything else that could help!

Dependencies

These instructions are based upon running the commands on a Debian based linux (in my case Debian stretch). The dependencies can be installed using the command bellow:-

sudo apt update
sudo apt install -y nginx openssl

Cert generation

CA cert

Generate the CA signing key and CA cert:-

export DOMAIN=example.com
openssl req -new -x509 -sha256 -days 730 -subj "/C=UK/ST=London/L=London/O=${DOMAIN}/CN=${DOMAIN}" -extensions "ca_ext" -config <(cat /etc/ssl/openssl.cnf | sed "s/\[ ca \]/[ ca ]\ndomain_suffix = ${DOMAIN}/"; echo -e "[ca_ext]\nsubjectAltName='DNS.1:*.${DOMAIN}'\nnameConstraints=@name_constraints\nbasicConstraints=CA:true\n[name_constraints]\npermitted;DNS.0=*.${DOMAIN}\npermitted;DNS.1=${DOMAIN}\n") -key ca/ca.key -out ca/ca.crt

Server cert

First generate a server key:-

openssl genrsa -out server/server.key 2048
chmod 400 server/server.key

Generate a certificate signing request (CSR) for your server. Replace example.com with the main domain of your server. This will be create a CSR for a cert valid for all subdomains of that domain:-

export DOMAIN=example.com
openssl req -new -key server/server.key -subj "/C=UK/ST=London/L=London/O=${DOMAIN}/CN=${DOMAIN}" -reqexts SAN -extensions SAN -config <( cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName='DNS.1:*.${DOMAIN}'")) -out server/server.csr

Next use the CSR to generate a cert signed by the ca key:-

export DOMAIN=example.com
openssl x509 -req -days 365 -sha256 -extfile <(printf "subjectAltName=DNS.1:*.${DOMAIN}") -in server/\*.${DOMAIN}.csr -CA ca/ca.crt -CAkey ca/ca.key -CAcreateserial -out server/server.crt

client cert

You can now generate as many TLS client certs as you need. Replace [client name] with a name for each client cert you issue:-

export CLIENT_NAME=[client name]
export DOMAIN=example.com

openssl genrsa -out client/${CLIENT_NAME}.key 2048

openssl req -new -key client/${CLIENT_NAME}.key -subj "/C=UK/ST=London/L=London/O=${DOMAIN}/CN=${DOMAIN}/emailAddress=${CLIENT_NAME}@${DOMAIN}" -out client/${CLIENT_NAME}.csr

openssl x509 -req -days 365 -sha256 -in client/${CLIENT_NAME}.csr -CA ca/ca.crt -CAkey ca/ca.key -set_serial 2 -out client/${CLIENT_NAME}.crt

openssl pkcs12 -export -clcerts -in client/${CLIENT_NAME}.crt -inkey client/${client_name}.key -out client/${CLIENT_NAME}.p12

Nginx config

First copy the ca certificate, server certificate and server key to a location for use with nginx

sudo cp ca/ca.crt /etc/nginx/certs/ca/ca.crt
sudo cp server/server.key /etc/nginx/certs/server/server.key
sudo cp server/server.crt /etc/nginx/certs/server/server.crt

The following nginx config will setup a reverse proxy listening on port 443 and requiring a client cert to connect to. You can replace the main nginx confing in /etc/nginx/nginx.conf with this if you like. It will proxy all validated requests to localhost:80 :-

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
        worker_connections 768;
}

http {

        ##
        # Basic Settings
        ##

        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;
        keepalive_timeout 65;
        types_hash_max_size 2048;
        proxy_connect_timeout  60s;

        include /etc/nginx/mime.types;
        default_type application/octet-stream;

        ##
        # SSL Settings
        ##

        ssl_protocols TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
        ssl_prefer_server_ciphers on;
        ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
        ssl_ecdh_curve secp384r1; # see here and here (pg. 485)
        ssl_client_certificate /etc/nginx/certs/ca/ca.crt;
        ssl_certificate_key /etc/nginx/certs/server/server.key;
        ssl_certificate /etc/nginx/certs/server/server.crt;
        ssl_verify_client on;
        ssl_session_cache shared:SSL:1m;
        ssl_session_timeout 1h;
        ssl_session_tickets off;
        ssl_buffer_size 4k;

        ##
        # Logging Settings
        ##

        access_log /var/log/nginx/access.log combined buffer=8k flush=5m;
        error_log /var/log/nginx/error.log info;

        ##
        # Virtual Host Configs
        ##

        include /etc/nginx/conf.d/*.conf;
        include /etc/nginx/sites-enabled/*;

          proxy_temp_path /var/www/cache/tmp;

        map $http_upgrade $connection_upgrade {
            default upgrade;
            '' close;
        }

        upstream backend {
            keepalive 16;
            least_conn;
            server localhost:80 fail_timeout=1s;
        }

        server {
                listen 443 ssl http2;
                ssl on;
                location / {
                        proxy_pass http://backend;
                        client_max_body_size 0;
                        proxy_set_header Host            $host;
                        proxy_set_header HTTPS           on;
                        proxy_http_version 1.1;
                        proxy_set_header Upgrade $http_upgrade;
                        proxy_set_header Connection "Upgrade";
                }
        }
}

[zebardy]

Hi,

is there any update or suggestions for helping to progress this? Happy to do some more work here, but think it needs an opinion and possibly some guidance for general desired direction of implementation.

Thanks

[tobiasKaminsky]

I unfortunately do not have much time for this right now.
If you can create a PR out of your already working proof of concept, I can help you to get it in 👍

[zebardy]

Hi,

3 years later and I finally have the time and headspace to pick this back up again. I've been looking through everything and have some ideas of how to implement this better.

However looking at the repository README.md, the suggested approach to take is to discuss your issue/feature request with developers until it is approved before devolving (label "approved").

What would you like for me to share on this for the issue to be approved?

Many thanks

[Daniel-dev22]

Hi,

3 years later and I finally have the time and headspace to pick this back up again. I've been looking through everything and have some ideas of how to implement this better.

However looking at the repository README.md, the suggested approach to take is to discuss your issue/feature request with developers until it is approved before devolving (label "approved").

What would you like for me to share on this for the issue to be approved?

Many thanks

Is this being actively worked on? It would be a great addition.

[KjellWolf]

Hi,

Is an update to be expected here? For several projects we have, a better integration for the use of certificates would be helpful.

Maybe also simply design a plugin where you can not only simplify the setup in general, but also easily connect CA outside?

[joshtrichards]

I believe this is done per #1308