The Node

Posts Tagged ‘encryption’

A lot of information passes over the web via HTTP. The problem with regular HTTP is that somebody can snoop on the traffic and see what you’re doing as the Firesheep Firefox plugin demonstrated a few years ago. So depending on what you use your web server for, you might want to encrypt the traffic between your browser and your web server. If you’re doing e-commerce stuff, you’ll definitely want to use encryption. This encrypted HTTP connection is called HTTPS and uses the OpenSSL library to provide quality encryption.

Here’s how it works.

- The client (that’s the web browser) requests a SSL connection with the server via HTTPS instead of HTTP.
- The server sends an SSL certificate to the client.
- The client validates the certificate, creates a session key and encrypts the certificate with the key.
- The server decrypts the session key and establishes the encrypted HTTPS connection.

The certificate that the server sends out is what makes this whole process work. A certificate is obtained from a Certificate Authority (CA), which is sort of like a trusted authority that verifies the certificate’s authenticity. The certificate contains the common name of the server making it impossible to use on other servers. It also uses keys – a public and private key – to create and verify a secure connection.

So the first step is to create this certificate. For this, we’re going to use self-signed certificates. This negates the need for a certificate authority and doesn’t cost any money. However, when using these self-signed certificates which is essentially you saying “trust me” to anybody who connects, your browser will display a warning. This is because it hasn’t been signed by a CA. If you’re just wanting to set up encryption for your own use, this doesn’t matter. If you’re thinking about setting up a website shop or handling credit cards you’ll need to use a CA and pay some money. The connection will be encrypted either way, but with a self-signed certificate, you’re asking users to trust you rather than a more reputable source :-)
For the purposes of this article, we’ll assume this is just for your own use so you don’t mind a warning message. Perhaps you’ve got a section of your website that you want to keep hidden from prying eyes like a web-admin screen or something of that nature.

First, make sure you have the OpenSSL libraries installed (and Apache obviously!). Under Red Hat-based systems you can install everything with: -

yum install openssh openssh-devel openssl openssl-devel

and Debian-based systems with: -

sudo apt-get install openssh openssh-dev openssl openssl-dev

Now that you have the required libraries, you can create your certificates via the command line. Your first step should be to create a local private/public key from which you can generate certificate requests. These can then be used for self-signed certificates or when purchasing a certificate from a CA.

openssl genrsa -des3 -out myserver.com.key 1024

This will create a private key using TripleDES encryption, 1024 being the number of bits generated in the key. This is your private key and should really only be accessible by the root user of the system. Next, you’ll need to create the actual self-signed certificate using this private key:-

openssl req -new -key myserver.com.key -x509 -out mycert.crt

If you want to have a “real” certificate that does not generate a warning, you’ll need to get an official CA to sign it, which will cost a bit of money. If you want to do this, you’ll need to generate a Certificate Signing Request (CSR) which you’ll need to send to a signing authority like this:-

openssl req -new -key myserver.com.key -out mycert.com.csr

They will then either mail you back your signed myserver.com.crt file or mail you a link to download it.

Assuming we’re using a self-signed certificate, at this point you should have two files, your private key file and your self-signed crt certificate. Don’t open or modify the certificate file with anything but a pure ASCII text editor as rich text editors can corrupt the file. If you use “cat” to display the certificate, it should look something like this: -


-----BEGIN CERTIFICATE-----
MIIC8DCCAlmgAwIBAgIBEDANBgkqhkiG9w0BAQQFADCBxDELMAkGA1UEBhMCWkEx
FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMR0wGwYD
VQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UECxMfQ2VydGlmaWNhdGlv
biBTZXJ2aWNlcyBEaXZpc2lvbjEZMBcGA1UEAxMQVGhhd3RlIFNlcnZlciBDQTEm
MCQGCSqGSIb3DQEJARYXc2VydmVyLWNlcnRzQHRoYXd0ZS5jb20wHhcNOTkwNTI1
MDMwMDAwWhcNMDIwNjEwMDMwMDAwWjBTMQswCQYDVQQGEwJVUzEbMBkGA1UEChMS
RXF1aWZheCBTZWN1cmUgSW5jMScwJQYDVQQDEx5FcXVpZmF4IFNlY3VyZSBFLUJ1
c2luZXNzIENBLTIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMYna8GjS9mG
q4Cb8L0VwDBMZ+ztPI05urQb8F0t1Dp4I3gOFUs2WZJJv9Y1zCFwQbQbfJuBuXmZ
QKIZJOw3jwPbfcvoTyqQhM0Yyb1YzgM2ghuv8Zz/+LYrjBo2yrmf86zvMhDVOD7z
dhDzyTxCh5F6+K6Mcmmar+ncFMmIum2bAgMBAAGjYjBgMBIGA1UdEwEB/wQIMAYB
Af8CAQAwSgYDVR0lBEMwQQYIKwYBBQUHAwEGCCsGAQUFBwMDBgorBgEEAYI3CgMD
BglghkgBhvhCBAEGCCsGAQUFBwMIBgorBgEEAYI3CgMCMA0GCSqGSIb3DQEBBAUA
A4GBALIfbC0RQ9g4Zxf/Y8IA2jWm8Tt+jvFWPt5wT3n5k0orRAvbmTROVPHGSLw7
oMNeapH1eRG5yn+erwqYazcoFXJ6AsIC5WUjAnClsSrHBCAnEn6rDU080F38xIQ3
j1FBvwMOxAq/JR5eZZcBHlSpJad88Twfd7E+0fQcqgk+nnjH
-----END CERTIFICATE-----


Move your files to somewhere outside your web server document root – the regular place on Red Hat-based systems that used Yum or RPM to install your Apache web server is “/etc/httpd/conf” but you can create a “keys” subdirectory anywhere and put your crt and key files in there.
Once this is done, you’re ready to configure Apache to use SSL and your certificates to server HTTPS.

For this scenario, lets say that I have a domain called “www.example.com”. This has a subdirectory called “admin” whose URL would appear as “http://www.example.com/admin/”. If I want to log in to my admin section of my site, I want to use HTTPS. If I am just hitting “www.example.com”, I just want to use regular HTTP. So let’s configure Apache for this.

A lot of installations of Apache have a main configuration file called “httpd.conf” which on most package manager-installed Apache installations is under “/etc/httpd/conf/httpd.conf”. However, this configuration file often includes separate configuration files for different functionality. For example on my system, configuration details for SSL is held under “/etc/httpd/conf.d/ssl.conf”. This file will have most of what you need, but a bare-bones SSL configuration should include the following: -

# This loads the SSL Apache module.
LoadModule ssl_module modules/mod_ssl.so
# The HTTPS port to listen on (default is 443).
Listen 443
# The virtual host we've set up to handle SSL connections to your domain.
# Change the file paths to your website and certificate files as appropriate.
<virtualhost _default_:443>
     ServerName www.example.com:443
     DocumentRoot /var/www/html/
     SSLEngine on
     ErrorLog /var/log/ssl_engine_log
     SSLCertificateFile /etc/httpd/conf/keys/myserver.crt
     SSLCertificateKeyFile /etc/httpd/conf/keys/myserver.key
</virtualhost>

Next, in the “httpd.conf” file, we want to define which parts of the site will use HTTPS and which will use regular HTTP.

# Load the Apache Rewrite Engine module as we're going to use it 
# to automatically flip betweeen HTTP and HTTPS.
LoadModule rewrite_module modules/mod_rewrite.so

# Secured encrypted admin page - use HTTPS.
<directory "/var/www/html/admin/">
     RewriteEngine on
     RewriteCond %{HTTPS} off
     RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</directory>

# Unsecured main page - turn off HTTPS.
<directory "/var/www/html">
     RewriteEngine on
     RewriteCond %{HTTPS} on
     RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI}
</directory>

Save this file and restart Apache with: -

service httpd restart

or if you’ve got Apache installed some different way or not defined as a service, run: -

/usr/local/apache2/bin/apachectl -k restart

…or wherever your Apache installation is :-)

HTTPS does not use the same port as regular HTTP which is defaulted to port 80. HTTPS uses port 443 as you can probably tell from the above. So you’ll need to make sure that HTTPS port 443 is open on your firewall. Using iptables, this can be done with: -


iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT


You can confirm that Apache is now listening on both ports 80 and 443 using netstat: -

netstat -l

…which should give you back some output that includes the following lines: -


tcp 0 0 *:http *:* LISTEN
tcp 0 0 *:https *:* LISTEN


Congratulations! If you now browse to “http://www.example.com” (or whatever domain you have) you’ll get regular HTTP denoted by the “http://”. If you browse to “http://www.example.com/admin/” you’ll notice that Apache rewrites the URL to become “https://www.example.com/admin/” and you’ll get the warning about your certificate (this is fine for your own use). If you browse back to “https://www.example.com” the rewrite engine will flip back to “http://”. Useful.
If you want your entire site to be forced to use HTTPS, you can modify your “Directory” tag directives to include the following instead: -


RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}


…which will force the use of HTTPS for all URLs matching the Directory directive. Be aware that using HTTPS has a couple of caveats – namely, that performance is generally slower than HTTP due to the need to encrypt the connection. So only use HTTPS if you want that section of your site’s traffic encrypted or don’t mind the slight performance hit.

As anybody who has used Canonical’s wildly popular Linux distribution, Ubuntu, you know that you automatically get 5GB of complementary cloud space on Ubuntu One, Canonical’s cloud service. If you want more than that, you obviously have to pay, but 5GB of cloud data can be very useful, especially now that the Windows Ubuntu One client is out. Perhaps I’ve just got used to using Google’s Chrome so much with it’s marvellous bookmark sync that I’ve been seeing the benefits of having a little data everywhere. Love it or hate it, having a Windows client makes Ubuntu One even more useful. There’s even an Android client available.

So, a dash of data in cloud. Nice. However, I’m still not trusting enough to keep important information in the cloud without a little encryption. Ironic I know, since I have a Google account and GMail tied to my Android phone and all that. But I’ve got Gmail backed up to my server and so, while I now feel I own my Google data (or at least have it backed up safely), there’s really not much you can to to protect yourself from Google itself :-)

Anyway, I digress. As I said, Ubuntu One is pretty useful now it’s multi-platform but if I’m going to store things on there, it’s nice to throw in a little encryption just to be safe. This is different to using something like LUKS encryption, because this works on a partition level, much lower than just dealing with files that you want to transfer. Even a useful encryption tool like TrueCrypt works by preparing a volume container for files, which while very good with a bunch of nice features, is not very handy for storing files on Ubuntu One.

Luckily, Ubuntu (and every other Linux out there) has a portable, standardised method for file encryption, OpenSSL. Here’s how to use it to encrypt your files before launching them off to Ubuntu One.

openssl aes-256-cbc -a -salt -in [UNENCRYPTED_INPUT_FILE_NAME] -out [ENCRYPTED_OUTPUT_FILE_NAME]

This will provide you with a standard AES 256-bit encryption scheme for your file. OpenSSL will prompt you for a pass-phrase, so be as creative as you are paranoid :-) The “aes-256-cbc” parameter specifies the use of 256-bit AES as the cipher and the “-salt” parameter adds a salt to the encryption setup for added security which helps foil dictionary attacks.

As long as somebody knows the pass-phrase (hopefully just you!), they can decrypt the file by using:-

openssl aes-256-cbc -d -a -in [ENCRYPTED_INPUT_FILE_NAME] -out [DECRYPTED_OUTPUT_FILE_NAME]

If you want to do this on the Windows side of things, you can use the Windows OpenSSL software as well. There you go – encryption for everybody :-)

If you want to encrypt a large number of files at once, you can always tar or zip then up first with (under Linux at least):-

tar -cf [TAR_FILE_NAME].tar [DIRECTORY_WITH_FILES_TO_TAR]

…and then use gzip to make the files a bit smaller before encrypting them. I don’t encrypt everything of course but it’s nice to have the option.

UPDATE 05/01/2012: There is now also an iOS Ubuntu One client available for Apple fans. I think Ubuntu One now has a client for pretty much every platform. Good going Canonical :D

Linux Unified Key Setup-on-disk-format (or LUKS) allows you to encrypt partitions on your Linux machine. This is particularly useful when it comes to mobile computers and other mobile media such as netbooks and tablets. LUKS allows multiple user keys to decrypt a master key which is used for the bulk encryption of the partition. Here the process of configuring LUKS is outlined using Fedora an an example system, although you can do this on any Linux box.

LUKS is implemented in all versions of Fedora 9 and above and is used for system encryption. By default, the option to encrypt the file-system during the installation process is unchecked. Also it rather lacks flexibility. So if you suddenly decide to implement LUKS later on, or want to configure something a little more suited to your needs, here is how to do it.

First of all you need to create an empty partition if you haven’t already done so. Obviously you can make it any size you want as long as the physical disk has enough unallocated space. If you’re not comfortable creating a partition, read over my LVM management post which discusses how to create a basic partition using fdisk. Remember, you just need the default partition code of ’83′. The process I’m going to describe will work equally well with logical volumes as well as disk partitions.

It goes without saying that you should start with an empty and unmounted partition as this process will destroy any data currently residing on it. If you want to encrypt data already residing on a partition, back it up to a different partition or external storage first.

We first need to enter runlevel 1 or single-user mode, as it’s also known. Linux runlevels was discussed in the previous post relating to root password recovery. Unless otherwise stated all commands require the user to be root. To enter runlevel 1, type: -

init 1

Next, make sure the partition you want to use for encryption is unmounted.

umount /mnt/luks

As you can see, I’ve got my partition (which happens to be /dev/sda6) mapped to /mnt/luks in my /etc/fstab file. Verify that the partition is unmounted with: -

cat /proc/mounts | grep /mnt/luks

The next thing to do is to “seed” your selected partition or volume with randomly generated data. This makes the encryption more secure but will destroy any data presently on the partition.

dd if=/dev/urandom of=/dev/sda6

Depending on the size of your partition and the speed of your system, this process could take several minutes to 6 hours or more. Be patient :-)

Next, you need to initialise the new partition.

cryptsetup --verbose --verify-passphrase luksFormat /dev/sda6

You will be prompted for a pass phrase. It cannot include spaces. This will be the pass phrase you use to unlock the partition.

Next, you need to open the newly created device. Remember, everything in Linux is described as a file.

cryptsetup luksOpen /dev/sda6 luks

Much like a logical volume, this maps the new device to /dev/mapper/luks. You can verify that it’s present with: -

ls -l /dev/mapper | grep luks

This simply does a detailed directory list of the /dev/mapper directory structure, looking for the entry luks. If it’s present, it will be listed.

If all is well, you still need to format the partition to make it ready for data. Since we’re using Fedora 14 which uses the ext4 file-system, we’ll use: -

mkfs.ext4 /dev/mapper/luks

If you prefer, you can also use: -

mkfs -t ext4 /dev/mapper/luks

Once the partition is formatted you need to mount it.

mount /dev/mapper/luks /mnt/luks

If you now do a “df -h | grep luks”, you should see it mounted and ready to go.

However, you probably want access to this encrypted partition when you boot up your server and as you’ve just seen, this volume can only be accessed with a pass phrase. In order to allow Linux to ask you for the pass phrase on boot, you need to add an entry to the /etc/crypttab file. Yes, it is pretty similar to /etc/fstab which handles regular mount points :-)

vi /etc/crypttab

Add the following:-

luks /dev/sda6 none

Speaking of the /etc/fstab file, you’ll also need to modify or add the entry for /dev/sda6 as this partition has now been mapped to /dev/mapper/luks: -

vi /etc/fstab

/dev/mapper/luks /mnt/luks ext4 defaults 1 2

Verify your /etc/fstab entry with the command: -

mount /mnt/luks

…as this form of the mount command takes the device to mount from from the /etc/fstab file with the entry /mnt/luks. If all is well, you should now be able to write to that directory. If you’re also using SELinux, you need to restore the security contexts for that location also: -

restorecon -v -R /mnt/luks

On reboot now, Fedora will ask you for the pass phrase you configured to open the volume on boot. Obviously, if you don’t want the partition or volume open the entire time the machine is on, you can remove the /etc/fstab entry and mount it manually. However, all the time the machine is switched off, that volume and the data within is safely encrypted.