December 2015

There were 2 posts published in December 2015 (this is page 1 of 1).

Publish certificate fingerprints in DNS (TLSA/DANE)

Ever had second thoughts on paying a certificate authority (CA) a lot of money to sign your web servers public encryption key to get a trusted certificate? With the birth of DNSSEC the need for this could fade away, at least partly. It is now possible to create a self signed certificate and post the signatures securely in DNS. This way there is a secure out of band method to check the validity of a certificate. There is a special record type for this called TLSA and you can read more about it in RFC 6698

The support for these records in todays browsers are very limited, but there is a plugin available for the most popular browsers called DNSSEC validator. With this plugin it is possible to get a green light, even with a self signed certificate.

If you run your own mail server it could be interesting to know that Postfix have support for TLSA records since a few versions back.

A TLSA record could look like this:

_443._tcp TLSA (3 0 2 4FB72400493E364A499B24CDC5E5715F
                      97543262CBCB90C8483C5AB3E8A37C9E
                      CC4E021C8C12B3E485CFF3A082348FE6
                      ED39EBBF2F812B3BA8857DBB1C96AFF0)

_443._tcp tells us that a certificate with this sha-512 hash should be handed to us if we connect to tcp port 443.

There are three options before the hash. The first option defines “certificate usage”, the second “TLSA selector” and the third is basically hash type. The fourth field is the actual hash of the certificate. In the above example we have a sha-512 of the full certificate of a “Domain-issued certificate”. Please read more about this in the RFC (section 7).

Using the *nix command host the fetch this record looks like this

> host -t tlsa _443._tcp.framkant.org.
_443._tcp.framkant.org has TLSA record 3 0 2 4FB72400493E364A499B24CDC5E5715F97543262CBCB90C8483C5AB3 E8A37C9ECC4E021C8C12B3E485CFF3A082348FE6ED39EBBF2F812B3B A8857DBB1C96AFF0

It is pretty easy to find out the hash of a certificate using openssl. The following command gives us the sha512 hash of a certificate from file.

> openssl x509 -noout -fingerprint -sha512 -in framkant.crt | tr -d :

Remember that for this to have any effect on your security or your ability to have self signed certificates you need to have DNSSEC up and running for your domain. Please have a look at my article about OpenDNSSEC if you run your own authoritative dns server.

Protect your private SSH-key with KDF (key derivation function)

Ever heard someone saying that using ssh-keys is a perfect way to have “passwordless” logins to servers? Probably you have. There is a big problem with this approach (I will ignore ssh-agents and stuff like this in this article). If you really want a completley passwordless login, you will need to store the private key unencrypted. The key can be stolen without you knowing it and the attacker could use it “as is”.

The first countermeasure is to encrypt the key and protect it with a passphrase. But since the key is just a file without any brute force protection it could (if the passphrase is weak or semiweak) be very easy to crack the key open. The encryption key used is just a md5 hash of your passphrase and md5 is… fast. Since OpenSSH 6.5 there is a bettery way to protect your ssh-keys. A new private key format is used where you can apply KDF (key deviation function) to slow down the decryption of your private key.

To create a key in the new format with KDF applied you use -o for the new key format and -a specify how many rounds of KDF to use. (more rounds is slower to decrypt)

> ssh-keygen -a 256 -o -t rsa -b 4096 -f test
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in test.
Your public key has been saved in test.pub.
The key fingerprint is:
45:20:9e:50:d2:6e:c9:11:bb:3a:fe:1c:a3:c6:93:48 peter
The key's randomart image is:
+--[ RSA 4096]----+
|    oo+....      |
|     +o+ .       |
|     o+o  .      |
|      =. .       |
|     .. S        |
|  E  .           |
| . oo.o          |
|  ..=+ o         |
|   .ooo          |
+-----------------+

How many rounds to use depends on your environment and how concerned you are about losing your private keys. 256 rounds on a reasonable modern computer takes me ~4s to decrypt. This is a infinite amount of time compared md5 brute force.