Archive for the ‘Security’ Category

Re: Heartbleed Bug: Public urged to reset all passwords

April 10th, 2014 No comments

A friend of mine asked me on that article on BBC whether you should change all your password due to that Heartbleed bug within SSL.

It seems there are a few things floating around, a few misconceptions and misunderstanding about the problem. First of all, when you access – a banking site for example, you usually use TLS (“Transport Layer Security”) or the older version SSL (“Secure Socket Layer”). This means that your data from and to your bank is encrypted in transit. The server where your banking site sits on is decrypting your data first, processes your request, but before the data is sent back out, it is encrypted again. Your browser is doing something similar. Received data gets decrypted first, displayed and when your requests are sent off, before they leave your computer, they are encrypted. This is called transport encryption – there is another way of encryption, but we come back to that later.

This encryption method works that each side has two types of digital keys – one is publicly known, the other is secret, and only the endpoints (ie. the “browser” and the “banking server”) know it, this key does not leave the system. With specifically crafted mathematical algorithms it is possible that one side can encrypt data with the public key of the other side, but only the secret key of the other side can decrypt it again – and vice versa. This is also called “Assymetric Cryptography” or also “Public-Key Cryptography”. If you are interested in this, you can find more on that here.

OpenSSL is providing functions to encrypt and decrypt data and is used mostly on the Linux/Unix side. So this Heartbleed Bug is a particular feature of this protocol, what has been added in the last two years. Unfortuntaly they discovered, that it has a major weakness, in that when you craft a specific request, it gives you back that secret key we spoke about before, so its “heart is bleeding”.

What does this mean?

If a server is vulnerable to this, an adversary can use this to get the secret key. That secret key your data in transit is encrypted with. This is the official statement, but there is a little but more to that, and it is a bit tricky to do anything with those secret keys as well.

That somebody can seriously misuse that hey would need to sit between your browser and your banking site, so that they can gather all the traffic. As they have the secret key of the server and all the encrypted traffic they are in a position to decrypt your data what you sent to the banking site. But the internet was not build in one day, neither encryption and there is a feature within SSL which generates a session-key for each session which encrypts the data even further. The design of this is built on the assumption, that you have an adversary on the wire/you have somebody listening in or generally it doesn’t trust the means of transport (ie. copper or fibre). This feature is called Forward-Secrecy. So to summarize, when the server has implemented and enabled this particular feature within its SSL stack and an adversary having the secret key, they still cannot decrypt your data. Unfortunately we do not live in an ideal world. And also unfortunately this feature Forward-Secrecy is not enabled on all the servers on the internet.

So what needs doing are

  1. All websites/servers need to fix this weakness by patching their systems, applying software upgrades.
  2. They also need to generate a new set of secret and public keys on their server.

What about my password now? Do I need to change it?

Everytime you login to a site, your password travels across this encrypted tunnel. The server receives it, has it in “plain text”, ie. the way you typed it, it should ideally hash it and check it with your stored credentials, which are also hashed. A “hash” is a different representation of your password, what cannot be undone, ie. “converted back”, ie. it is a “one-way function”. Encryption on the other side is both-ways, it can be decrypted again. There is only “brute-force” for converting a hash back to its original form. So a fairly common password hash is unfortunately “286755fad04869ca523320acce0dc6a4″ – please use the search engine of your choice and you can find out which plain-text password that would be. SSL is not involved in storing your password or generally when “data are at rest”.

To bring this to an end, changing your passwords is pointless unless your website has not done due diligency yet, ie. patched the weakness and regenerated a new set of keys.If they also have done their due diligence and used Forward-Secrecy, but are vulnerable there is no need to panic still.

Yes, you should do change your password, but don’t use the same password everywhere. Better to be safe than sorry. Use a local password manager like KeePass or Password Safe, do not use your browser to store passwords and/or websites like LastPass (if you use this, all your passwords could be out there, that’s why it is important to have a local password manager, and not on the internet as a website).

Categories: Security Tags:

GBit connection but only ~12MBytes/s transferrate over SSH?

February 28th, 2013 No comments

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


Categories: Security Tags:

Take care of your servers/services/(web)apps as you (hopefully) do with your car

February 27th, 2013 No comments

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.

Categories: Security Tags:

Comment on “Symantec SSL certificates feature cryptography 10k times harder to break than RSA-bit key”

February 15th, 2013 No comments

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.

Categories: Security Tags:

Two factor authentication with YubiKey

June 24th, 2012 No comments

Yubikey with penguinTwo 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.

Categories: Security Tags: