preissler.co.uk

I came about that my SSH setup was only able to transfer ~12MBytes/s. After some digging I found out that SSHv2 is by default using “3des” as the cipher.

When I set it specifically with “-c blowfish” to a another secure, but much faster block cipher, I got ~24MBytes/s. If you want you can configure this as the default in your ~/.ssh/ssh_config as

cipher_spec blowfish

If you want to have your car for a long(er) time, you usually do your servicing, or in other words, you look after it.

This is the same what you should be doing with your servers/services/applications what you are responsible for. You look after them, you do a regular oil-change (ie. “updates and/or patches”), you do your regular MoT (here in UK), ie. your regular yearly review.

You are also obliged by law that it is roadworthy, or you loose your insurance. So when there is “something sticking” out of it, ie. when it is a security hazard, you go and fix it. Same for your server, you fix it, ie. you configure it correctly or you remove it altogether.

And last but not least, there are also “zero-days” on cars. Year, right. Like manufacturers faults or a design/construction problem. There is nothing what you can for yourself. When you don’t know about it, you can’t fix it. For the most cases, it comes down that the manufacturer lets you know and – here you go, patch your system.

If your manufacturer doesn’t know, or doesn’t want to let you know (that’s unfortunately quite common in the software industry), that’s it. If you are lucky, you can turn that particular feature off, if not, you have to live with it.

Just some thoughts, heading off now.

I just came across  Symantec SSL certificates feature cryptography 10k times harder to break than RSA-bit key and Symantec/VeriSign Expands Encryption Options For SSL Digital Certificates.

I must say, I am stunned. AFAIK no certificate has been “broken” yet, and those few ones what have, were implementation errors or via MD5 collision attacks. And then there are plain hack-into-their-system and steal the private keys attacks, like DigiCert. There are a few others most likely.

The problem is not the encryption of the SSL certificate, present SSL encryptions are strong – again, most of them, MD5-based SSL certificate hashes are considered broken (or anything MD5 based in general), and also the recent “Lucky 13” when using a specific cipher.

There are still enough ciphers out there to make existing SSL certs good enough. Deploying a new cipher takes time and is new code, what has not been (security)tested yet.

Attackers will always attack the weakest link, and this is not by bruteforcing the cipher, in most cases they go after the human.

Two factor authentication with OTP – as provided by YubiKey – makes you sleep well at night again.

I recently figured that these substantially increase your password security – with what you know and what you have. They are very easy integrated into PAM – and the good news is most services on Linux can be configured to use PAM as an authentication source.

SSH, Dovecot, Apache… no problems.

The good thing is, these tokens are not expensive at all – 25 USD and they are yours or for 10 USD more you can even get one with RFID integrated. What more do you want?

Unfortunately still, there are only a few websites what are supporting these tokens, there are certainly plugins for some web applications like WordPress or SqurirrelMail. These are what I know of, there a certainly more.

I wrote a short article about these nearly 2 years ago – you can find it here.

I have to add a correction to my previous article “Enabling HSTS on nginx“:

You can and should enable it on http as well, so that visitors of your website offer from this additional security benefit as well – when they come back.