HTTPs for duplicati

aryliin
(en français)
July 12th 2021

Spoiler: Even if duplicati does not allow authentication per se on its interface, it is still possible to protect access with a password. But since it is accessed through http, in absolute terms, anyone who listens on the network could know it. To pass the interface to HTTPS, we will go through a reverse proxy. To do this, we will first have to deploy our certificate and our key. Then install apache and use it for HTTPS access.

When installing a service with a web interface, the reflex to have is as follows:

Install certificates signed by a CA to secure the HTTPS connection.

Arsouyes reflex

It may be too much in our case since we only have 4 users in our IS, two of whom know the password and two are too young to sniff the network… But as in all situations, things change … Without seeing the time pass, the eldest will be 16 years old and will have fun (maybe) with the network (unless she has already done it well before).

We have a problem

To use SSL with duplicati, according to the official documentation, you must start the server with the --webservice-sslcertificatefile = option, followed by the path to a certificate in PKCS12 format.

In the idea, it is therefore very easy to switch your interface to HTTPs. Except things are never that simple. If you try on Linux, it won’t work.

Investigating the problem, we realize that duplicati is coded in .NET. And that under Linux, .Net is managed by Mono which is an OpenSource implementation of the .NET virtual machine. Mono has problems with the management of certificates in PKCS12 format (see here or there).

We therefore cannot use this configuration option, and we must work around the problem by installing Apache in front of duplicati.

Prepare duplicate

If you followed our article about the installation of duplicati, you have probably changed the port number to access it and opened access to all IPs. If not, check the following points in the /etc/default/duplicati file anyway, to be sure that it is configured as follows:

--webservice-interface=127.0.0.1: restricts access to the interface to 127.0.0.1.
--webservice-port=8200 : allows access to the interface using port 8200.

Restart duplicati.

sudo service duplicati restart

You will not be able to access it for the moment, except from the machine itself.

Apache

We are now going to use apache as a reverse proxy so that it gets betweenduplicati and us, the administrators. It is apache which will then manage the HTTPs part before transferring our requests toduplicati (in clear, but locally on the machine).

Deployment of the certificate and the key

Let’s assume that you already have your PKI and that you already have your certificate and your key. You therefore have the following files:

duplicati.crt for the certificate,
duplicati.key for the key.

We upload these files to the server. Usually, the following directories are used:

/etc/ssl/certs/ for the certificate,
/etc/ssl/private/ for the key.

We then put the right rights on the files, history that the files belong to root, and that the key file has only write rights.

sudo chown root:root /etc/ssl/certs/duplicati.crt
sudo chown root:root /etc/ssl/private/duplicati.key
sudo chmod 400 /etc/ssl/private/duplicati.key

If, like us, you have installed duplicati as a service, these rights will be sufficient.

Installation and activation of modules

We will then install apache on the command line.

sudo apt-get install apache2

Then we activate all the modules that will be necessary:

proxy: provides the basic functions of a proxy,
proxy_http: support for proxy HTTP and HTTPS requests,
headers: allows you to control the HTTP headers,
proxy_wsttunnel: provides tunneling support for websockets,
ssl: provides SSL v3 and TLS v1 support,
rewrite: allows you to rewrite request URLs on the fly.

sudo a2enmod proxy proxy_http headers proxy_wstunnel ssl rewrite

HTTPs

To configure a virtual host, which will just act as a pass between the rest of the world and duplicati by adding HTTPs along the way, we create a new file, in/etc/apache2/sites-available/, namedduplicati.conf, with the directives for managing SSL on one side, and those for the reverse proxy on the other.

<VirtualHost *:443>
    ServerName lynx.arsouyes.org

    # Guidelines for SSL with Administrators
    SSLEngine on
    SSLCertificateFile    "/etc/ssl/certs/duplicati.crt"
    SSLCertificateKeyFile "/etc/ssl/private/duplicati.key"

    # Reverse proxy guidelines
    ProxyPreserveHost On
    ProxyRequests off
    ProxyPass / http://127.0.0.1:8200/
    ProxyPassReverse / http://127.0.0.1:8200/

    AllowEncodedSlashes On

</VirtualHost>

Slashes encoded in URLs are refused by Apache. But duplicate uses them when recovering files. The Apache server therefore prevents the correct transmission of the request to duplicate. In order to force Apache to forward the request as requested, it is necessary to set AllowEncodedSlashes toOn.

Now that the configuration file is created, we will activate the site:

sudo a2ensite duplicati.conf

Then restart apache with its new configuration.

sudo systemctl reload apache2

Redirection from HTTP to HTTPs

Basically, apache installs a test site in /etc/apache2/site-available/000-default.conf. We will delete everything that is configured for this host, and be satisfied with a redirection.

<VirtualHost *:80>
    ServerName lynx.arsouyes.org
    Redirect permanent / https://lynx.arsouyes.org
</VirtualHost>

We restart the configuration one last time.

sudo systemctl reload apache2

And after

You can now access the interface in HTTPs. Thanks to Apache cutting between duplicati (locally) and the rest of the IS, it is no longer possible to sniff the network and recover the password.

There are many other useful modules of apache that we could now consider restricting access, no longer with a simple password, but to users of an LDAP directory or of a domain, via the module authnz_ldap.