Movie of the Week: The Martian

After reading Andy Weir‘s novel The Martian I wondered how long it would take until somebody tries to turn it into a movie and more importantly if that movie would be any good. When I learned that no other than Sir Ridley Scott would direct the film adaption I was sure that it would be either epic or absolutely awful.

In The Martin NASA’s third manned Mars mission has to be aborted because a powerful sandstorm is threatening to destroy the space ship that the crew needs to leave Mars. During the emergency evacuation astronaut Mark Watney is presumed dead and left behind. Stranded on an uninhabitable planet with limited resources he needs to figure how to survive for four years until a rescue mission from Earth can reach him. But as NASA doesn’t even know that Mark is alive that rescue mission might never come.

The film adaption of The Martian is very close to the original book. It doesn’t change the excellent plot much and features all the important characters. The second half of the original story is however strongly compressed, most likely to keep the run time of the movie under 2.5 hours. The only letdown is the Iron Man Sequence towards the end of the movie. While the science in the rest of the film seems plausible (even if it isn’t always correct) this scene features the usual unrealistic and over the top Hollywood action. It is even more annoying because one of the characters points out that the plan cannot work in the first place. But it is carried out nevertheless and succeeds in complete ignorance of the laws of physics. The spectacular but unobtrusive special effects, the breathtaking Mars scenery (in particular in 3D) and Matt Damon‘s excellent portrayal of the main character fortunately make up for that. The latter aspect is very important considering that most of the movie features Mark Watney by himself .

Film adaptions of books often butcher the original. This is fortunately not the case for The Martian. The movie is instead an excellent visualisation of the source material. I greatly enjoyed watching it even though I had very high expectations. But I’m now wondering whether we will get a Director’s cut on Blu-ray which features more of the plot from the second half of the book. That would make an already good movie even better.

SSL Certificate Agility with Postfix

RFC 4492 and RFC 6460 introduced a number of TLS ciphers based on elliptic curve cryptography (ECC). While some of them are designed to work with RSA keys (which is what most encrypted website on the Internet are using at this point of time) others are designed to be used with a new type of keys which use the ECDSA algorithm. The advantage of using ECDSA keys instead of RSA keys is the superior performance and hopefully superior security.

But as with all new standards it takes a while before ECDSA got widely adopted. Almost 10 years later most modern browsers support this crypto algorithm. But there are still browsers (often running under outdated operating systems) and even web search engine crawlers in use that only support RSA. It is therefore still desirable to support both ECDSA and RSA keys in parallel. This approach is called certificate agility because the server is configured with multiple key/certificate pairs and automatically chooses one depending on the capabilities of the client.

Inspired by this blog article I recently created an ECDSA key (using the secp384r1 curve for compatibility with Google’s browser Chrome) for my Apache web server, got it signed by a certificate authority and enabled certificate agility. If you use Firefox or Chrome you can click on the pad lock next to the URL bar to check which of my two keys your browsers used during the key exchange. Encouraged by this quick win I wanted to enable certificate agility for more services. The obvious next target was Postfix, the mail server software that handles all the e-mail from and to my domains.

Modern versions of Postfix feature full support for certificate agility. They can be configured to use any combination of RSA, DSA and ECDSA keys. If you want to use an RSA and an ECDSA key you only need four configuration statements similar to these:

# RSA key and certificate chain
smtpd_tls_key_file = /etc/ssl/private/smtpd-key.pem
smtpd_tls_cert_file = /etc/ssl/certs/smtpd-cert.pem
# ECDSA key and certificate chain
smtpd_tls_eckey_file = /etc/ssl/private/smtpd-key-ecdsa.pem
smtpd_tls_eccert_file = /etc/ssl/certs/smtpd-cert-ecdsa.pem

The devil is however in the detail, at least if your system uses OpenSSL 1.0.1 and not 1.0.2. While OpenSSL 1.0.1 supports multiple keys for a TLS server endpoint it only supports a single intermediate certificate chain. And without the correct intermediate certificates SMTP clients won’t be able to verify the validity of your servers certificate. To work around this limitation you need to create the certificate files from the above configuration example like this:

  1. /etc/ssl/certs/smtpd-cert.pem contains the certificate for the RSA key stored in /etc/ssl/private/smtpd-key.pem followed by the intermediate certificate for both keys.
  2. /etc/ssl/certs/smtpd-cert-ecdsa.pem contains the certificate for the ECDSA key stored in /etc/ssl/private/smtpd-key-ecdsa.pem again followed by the intermediate certificate for both keys.

With this configuration SMTP clients will always receive all the necessary certificates to validate your server certificate. The only downside is that they will also receive two certificate that they don’t need. That should however not have any noticeable consequences. You can now test certificate agility using the OpenSSL command line client:

openssl s_client -cipher ECDHE-RSA-AES128-SHA -connect <your server>:25 -starttls smtp
openssl s_client -cipher ECDHE-ECDSA-AES128-SHA -connect <your server>:25 -starttls smtp

Both commands should result in a successful connection. Certificate validation should also work but you might have to supply an extra command line argument like -CApath /etc/ssl/certs to specify the location of the certificate authority catalog.

There is however still one problem with such a setup: although Postfix now supports certificate agility it is still going to use the RSA key most if not all the time. The reason is that OpenSSL still prefers RSA over ECDSA by default. And as (almost?) all SMTP clients support RSA it is always going to be used in preference of ECDSA. To change this behaviour you need to modify the cipher lists used by Postfix. This is however a change which is usually discouraged. So please consider it carefully. On my setup I’ve configured Postfix’s TLS settings as follows:

tls_high_cipherlist = ECDSA+AESGCM:ECDSA+AES:ECDH+AESGCM:DH+AESGCM:ECDH+AES:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
smtpd_tls_ciphers = high
smtpd_tls_exclude_ciphers = aNULL, RC4
smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3

The cipher exclusion list is probably not necessary anymore. But I leave it in there just to be hundred percent sure. After this change certificate agility finally works as desired:

Jul 24 19:31:37 colwyn postfix/smtpd[22130]: Anonymous TLS connection established from mail-la0-x244.google.com[2a00:1450:4010:c03::244]: TLSv1.2 with cipher ECDHE-ECDSA-AES128-GCM-SHA256 (128/128 bits)

I haven’t noticed any problems with such a setup since I deployed it on my mail server two weeks ago.

DNSSEC for UK domains

I finally got around to enable DNSSEC (Domain Name System Security Extensions) for my primary domain zhadum.org.uk. This extra layer of protection makes it much harder to forge DNS entries for my domain.

Following the steps in this tutorial the whole process was not very difficult. Although I had to make a few adjustments because Nominet, the UK domain registry, mandates the use of different key algorithms for DNSSEC.

Here are the appropriate commands for UK domains:

dnssec-keygen -a RSASHA256 -b 1024 -n ZONE example.uk
dnssec-keygen -f KSK -a RSASHA256 -b 2048 -n ZONE example.uk

If the OpenSSL command client is available on your system you can also generate the salt for the zone signing with a single command:

openssl rand -hex 8

After you have completed the configuration of your name server you can use VeriSign’s DNSSEC Analyzer to test your setup. If everything is working correctly the DNSSEC Analyzer should only complain about the missing DS records in the parent zone. To rectify this you need to submit the DS records to your domain registrar who in turn will submit them to Nominet. Once this has been done you should have complete DNSSEC protection for your domain.

I hope these tips help other people to get their UK domains protected with DNSSEC as well.

Taking comfort in the Unfairness of the Universe