Introduction
As mobile devices proliferate, so does our need to share data between them: calendars, contacts, music, photographs, documents. Many companies are competing to offer “cloud services” to allow us to access our data anytime, from anywhere. However, there is a big drawback: once the data is on their servers you are no longer in control of it. Concerns include:
- Privacy: the provider may “share” your data with third parties or attempt to “mine” it to find out more about you from it.
- Jurisdiction: the laws of where your data are stored, not where you live, are applicable. Some jurisdictions offer less protection of your privacy and intellectual property than others.
- Intellectual property issues: the cloud provider’s user agreement might give them some rights to use what you upload. You did check the fine print, didn’t you? Even if you did, they can still…
- Bait and switch: Companies can change their terms of service at any time. When they do so, you might already be so invested in their services that migration will be a major hassle.
- Security: A lot of data concentrated in one place makes a juicy target for criminals.
- Continuity: Companies can discontinue services with little or no notice, leaving you in the lurch.
So what can you do about it? Many of these issues can be avoided altogether (or at least mitigated) by hosting your own cloud service. ownCloud is an open source “private cloud” package that can provide file synchronisation, calendar and contacts management. The server supports multiple operating systems and clients are available for common mobile platforms and desktops. Service interfaces are standard rather than proprietary (WebDAV, CalDAV and CardDAV for file management, calendar and contacts respectively), increasing interoperability.
To use ownCloud, you need to:
- Install the ownCloud server package on a server which is always connected to the internet.
- Install ownCloud clients on your devices that you wish to share files between.
- Configure your calendar and contacts applications to synchronise with your ownCloud server using the CalDAV/CardDAV protocols.
This blog post covers the first part.
One great thing about the ownCloud server is that, being written in PHP, it will run on nearly all common web servers and platforms more or less out of the box. That said there are a few shortcomings. There is no client-side encryption and files are stored unencrypted on the server by default. WebDAV/CalDAV/CardDAV are layered on top of HTTP, so an HTTPS connection (i.e. use of SSL/TLS transport layer security) is required to secure communications between the client and server. SSL/TLS needs a bit of knowledge to configure and deploy securely; it has several old protocols and ciphers which are insecure and deprecated but are still used to support antediluvian browsers. Since we control all the clients we can avoid the need to use insecure features but we still have to know how to configure SSL/TLS properly if we want the best security.
Virtual Private Server
The server requires a reliable machine that is “always on” and always connected to the Internet, and has a public IP address. This kind of infrastructure could be hard to set up at home, so an alternative is to use a Virtual Private Server (VPS); basically a virtual machine running on someone else’s hardware. VPS offerings range from the cheap and cheerful, aimed at personal web sites and blogs, to enterprise-grade solutions with prices to match. You can choose services that provide given amounts of CPU, memory and disk, different levels of redundancy and backups, and levels of support. There is often a choice of operating system, typically between Microsoft Windows and variants of Linux.
Installing ownCloud on Linux (Debian)
1. Prepare the server
Once you sign up for a VPS, you will often get a server within a few minutes of submitting your credit card details. The first thing to do is to make the server reasonably secure. Changing the root password is the first priority, especially if it was sent to you by email. See My First 5 minutes on a server for further ideas.
2. Install ownCloud
You then need to get an Owncloud server installation. ownCloud is written in PHP so doesn’t require compilation, but has a number of dependencies. The easiest option is to use a Linux package installer, since that way dependencies and updates can be installed automatically. Packages are hosted by OpenSUSE here. Select your operating system and follow the instructions.
3. Create an encrypted data directory (Optional)
ownCloud lives in /var/www/owncloud by default, but allows you to select another directory to store data. To (marginally) increase security, I used encfs to create an encrypted directory. This will be inaccessible if the machine is rebooted, requiring manual remounting with a password. An advantage of encfs is that it doesn’t require you to create a fixed-size file or partition. Here, we store encrypted files in a directory /srv/encrypted-owncloud and mount the decrypted directory on /srv/decrypted-owncloud. The procedure below is cribbed from here with some modifications and corrections.
# apt-get install encfs
# mkdir -p /srv/encrypted-owncloud /srv/decrypted-owncloud
# chgrp www-data /srv/decrypted-owncloud
# chmod -R g+rw /srv/decrypted-owncloud
# gpasswd -a www-data fuse
# chgrp fuse /dev/fuse
# chmod g+rw /dev/fuse
# encfs --public /srv/encrypted-owncloud /srv/decrypted-owncloud
Select the ‘paranoia’ configuration (p) when prompted. Make sure you use a strong password, and don’t lose it! The /srv/decrypted-owncloud directory can be unmounted with unmount as usual, and mounted using the enfcs command again.
4. Update PHP
Operating systems such as Debian and CentOS are designed for server use and prioritise stability than being “bleeding edge”. The downside is that some packages are a little old. In particular, ownCloud 6 recommends PHP 5.3.8 or later, which is later than the version that ships with Debian 6. Fortunately, the dotdeb group maintains a repository of more up-to-date packages including PHP. Follow the instructions there.
5. Configure HTTPS
HTTPS is critical to the security of the ownCloud installation. Do NOT deploy ownCloud without it! Basically, you need to create an X.509 certificate and a private key, and configure Apache with their locations. A few points of note:
- The Common Name (CN) of the X.509 certificate must match the name of the site (i.e. the virtual host name). If you have multiple web host names you will need multiple certificates.
- Since this is a private-use server we can use a self-signed certificate. This will cause web browsers and other clients to issue a warning when we first attempt to connect, but this can be ignored. (For https services you want to offer to the general public, it’s advisable to obtain a certificate signed by a Certification Authority.)
- Since we control the web browsers that will connect to the server, we don’t need to support antique browsers and so can disable the use of older, insecure protocols and ciphers.
Unfortunately some guides are out of date. mod-ssl is now provided in the apache2-common package. Documentation (including on certificate setup) is in /usr/share/doc/apache2.2-common/README.Debian.gz. This guide provides details for debian 7. The following borrows from it.
(1) Enable apache2 ssl
SSL is already provided in the default apache2 distribution.
$ sudo a2ensite default-ssl
$ sudo a2enmod ssl
$ sudo service apache2 restart
(2) Generate an SSL key and self-signed certificate
As mentioned the SSL certificate’s Common Name (CN) must match the domain name being served.
An X.509 certificate was created automatically by the ssl-cert package using the fully qualified domain name (hostname) at that time as the Common Name. The certificate saved in /etc/ssl/certs/ssl-cert-snakeoil.pem and the key in in /etc/ssl/private/ssl-cert-snakeoil.key (readable only by root). If the hostname has changed, these can be regenerated by
# make-ssl-cert generate-default-snakeoil --force-overwrite
Alternatively, use openssl to generate a self-signed certificate, giving finer control, e.g.:
$ sudo openssl req -x509 -nodes -days 365 \
-newkey rsa:2048 -keyout /etc/ssl/private/hostname.key \
-out /etc/ssl/hostname.crt
creates a certificate and a 2048-bit RSA key valid for 356 days. You will be prompted for various inputs including the CN. Remember to set the access restrictions for the private key. (In debian, the group should be ssl-cert, the owner should be root and the permissions 640.)
You can view the details of the certificate with the incantation
openssl x509 -in /etc/ssl/certs/ssl-cert-snakeoil.pem -noout -text
Note: openssl is a kitchen-sink command that has multiple functions. See https://www.sslshopper.com/article-most-common-openssl-commands.html for a useful overview.
(4) Configure Apache to use the certificate/key and test
You can use the file /etc/apache2/sites-available/default-ssl as an starting point. Test by enabling the site file (if not already enabled: see whether a symbolic link exists in /etc/apache2/sites-enabled) and restarting the server.
$ sudo a2ensite default-ssl
$ sudo service restart apache2
then connect using a web browser.
As a quick and dirty hack for better security, have the following directives outside any
SSLRandomSeed startup file:/dev/urandom 1024
SSLRandomSeed connect file:/dev/urandom 1024
Then inside the
SSLEngine on
SSLProtocol -all +TLSv1 +SSLv3
SSLCipherSuite HIGH:MEDIUM
SSLCertificateFile /etc/apache2/ssl/mycert.crt
SSLCertificateKeyFile /etc/apache2/ssl/mykey.key
obviously substituting the appropriate paths to your certificate and key files. This disables all except the TLS 1.0 and SSL 3.0 protocols and uses whatever of OpenSSL regards as good cipher suites. However, these change with time as attacks and vulnerabilties are discovered.
More advanced stuff:
The version of openssl provided by Debian 6 does not support the TLS 1.2 protocol or the ciphers necessary for forward secrecy. To solve this issue, you will need to compile recent versions of OpenSSL and Apache2, preferably without touching the default OS packages: see here. Regarding SSL configuration for forward secrecy, see here.
6. ownCloud configuration
You need to enable rewrites
$ sudo a2enmod rewrite
$ sudo service apache2 restart
Now to create an ownCloud configuration file as per the ownCloud installation guide. You can create one from scratch or copy the default /etc/apache2/sites-available/default-ssl to something like /etc/apache2/sites-available/owncloud-ssl and edit that. Disable the default SSL configuration and enable ownCloud configuration file:
$ sudo a2dissite default-ssl
$ sudo a2ensite owncloud-ssl
$ sudo service reload apache2
The point your browser at it, and you should be rewarded with a screen that invites you to create an administrative user. Do this now (and use a strong password), obviously, because at this point anyone can do this. You’ll also have the option of setting up a data directory other than the default /var/www/data. Point it at /srv/decrypted-owncloud directory you created earlier (if you did so).
Assuming you’re successful, ownCloud will then run through some diagnostics, then you’ll be in.
Troubleshooting
What could go wrong? Quite a lot actually, but most issues are probably due to misconfiguration rather than breakage. Fortunately, ownCloud does produce some mostly helpful diagnostics that are only occasionally misleading.
- If the apache2 server fails to start then the server configuration file is probably broken. A good starting point for troubleshooting is examining web server logs (by default in
/var/log/apache2).
- Check permissions. ownCloud expects the
/var/www/owncloud directory (and data directory) to have the owner and group www-data. The web server also has to run as the user www-data to access these files. Although this is the default, some installations can differ.
- If ownCloud issues some diagnostics as a result of its self-test, you can see details in the log accessible from the Admin link.
Conclusion
That’s basically it. You should now have a working ownCloud server. In Part 2 I’ll explain how to configure various devices to use it.
