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:

When you were young a day seemed like a day…

September 30th, 2013 Comments off
When you were very young a day seemed to last a year. 
When you were a teenager a day lasted a week.
When you reached middle age a day was over in an hour.
Now last christmas seems like yesterday.

On the grounds that you only have about two weeks left to
live what are you going to do with them?

– By my ex-colleague John (“not sure exactly as it was in a time management course about 20 years ago (seems like yesterday!)”)

Dedicated to John, my friend and former car mechanic.

Categories: Misc Tags:

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

February 28th, 2013 Comments off

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 Comments off

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:

A Raspberry Pi behind a 22″ TV

February 16th, 2013 Comments off

imageI had an old 22″ monitor standing around, where the integrated CD/DVD player was broken – but lucky me it still had a HDMI input, so… *g

So I stuck the Pi with doublesided super strong mounting tape at the back of it, put some more “sticky points” to hold the wireing in place and that there is no strain on the cables and the Pi – and here you go.

I orginally had it mounted so that the power leads and the SD card are easily accessible from the top,but then realized it would be better when they are on the right side (so that all the cables come out on the left, right and buttom). That super strong mounting tape actually removed some of the original TV’s labels…

Right now I labelled my SD cards, as I am trying different things right now. These are

  1. XBMC viewing station with OpenElec
  2. Plain Raspbian for testing software on a plain Linux installation, like Minecraft.

It is great and I am enjoying it – my son as well, as he likes Minecraft and really would like to have this hooked up to his TV… but not yet, not gonna give my toy out of my hands yet.

Categories: Ideas Tags: