A secure blanket

You shouldn’t trust the Internet. It is dangerous and because most people do not fully comprehend the technology and inner workings, it is hard to understand how and when you are in danger. And yet, as we become more and more reliant on Internet, we clearly need to use it. The Internet was invented by people with large ideological ideas which completely trusted each other. Yet it was conceived to withstand a nuclear bomb and keep on functioning. It appears that the threats we encounter are quite different though. As you are using Internet banking and started to buy stuff on-line, it seems ‘they’ are out there to steal your money or, worse, your identity.

One of the ‘easy’ protections of websites are certificates. The ‘little locks’ and nowadays greenish address bar. Certificates do not protect a website, but protect the channel between your browser and the server; from your bank, for example. These are server certificates and do not prevent malicious people for accessing the site (and trying loads of passwords fro example). But at least it prevents people from ‘eavesdropping’ while you are typing your password or checking your bank account. It is the first step in trusting your bank on-line.

Security has no other purpose than to establish and maintain trust.

Of course there is much more to securing a website or application than merely using certificates. But there seems to be a longstanding problem in IT about when and how to use certificates. Most site owners allow access to their websites without a certificate (plain old http) and only restrict certain portions of the site to be accessed over a secure channel with a certificate (https). I think this is wrong and should be improved.

A couple of years ago, having a certificate on your server meant a lot of overhead: Every request needed to be decrypted and the answers needed to be encrypted before sent back. This was a burden on the web-servers, especially when the traffic increased. However, it seems that this overhead has largely been removed. Partially because all major websites use special dedicated firewalls which can do this encryption much more efficient, and also because CPU’s have become faster and faster each year. Changing a channel from non-secure to secure has little impact on your web-servers nowadays (unless you are Google or HoTMaiL or so).

Having a switch between secure and non secure channels, can lead to mistakes in which pages or web forms submit confidential data over a non secured channel.

If all traffic would be secure, it would lead to several advantages, beside the no-more-mistakes. For instance, when I browse to the homepage of my bank, why doesn’t it immediately make itself known and switch to a secure channel? This increases my trust with the bank, because they immediately tell me that they are who they say they are by enabling all the markers (green address bar, locks etc). Whatever I do on the site, the transmission is secure between me and the site.

Most phising attacks happen by luring people to websites which look ‘just like’ your bank (or PayPal or so) and trying to let you log in, so they can steal your password. I used to work for a Dutch bank called ABNAMRO and at some point we discovered a fake site on WWW.ABNAMR0.COM, trying to steal passwords. Did you see the trick they did? (let me rewrite the fake site in small caps: www.abnamr0.com). The last letter ‘O’ was replaced by a zero.

If this bank used to have certificates for their whole website, they would increase the bar for thieves. Especially if they would obtain something which is called an extended certificate, which modern browsers use to display more security information, because the owner of the site has gone though more trouble authenticating himself, before he got this better certificate. It is not that criminals could not create secure fake sites, but it would increase the bar.

unfortunately there are more problems with security than just this. Mal-ware exists, which tries to live in your browser to try to steal passwords, which intervenes with your sessions before they get encrypted. But every little step counts in building trust.

On the server side there are also some problems. The first is where to terminate this secure tunnel between the browser and the companies data center. This boils down to a question of who do you trust within your data center? Most large clients I worked for used to have a policy to ‘trust the data center‘ and not use any security inside the data center. Often because the operators think security is a burden and difficult. Again, I totally disagree. I think that most traffic, also within the datacenter, should be made secure as well. And if your software does not work with it or cannot be setup securely, you should ask yourself if it is worth to use. Major software vendors have completely moved to building software which can use certificates for all communication channels. There might be a problem with intrusion detection software, but this should be checked between firewalls anyway, as all traffic should move through firewalls as much as possible.

I would like to see a lot more usage of certificates. Even though they seem to bring some problems to webmasters and operators. These people will need to work out ways to make it simpler for themselves and it will become easier if they do it more often than now: If you change a certificate once a year, it is difficult. If you do it weekly or monthly, it gets easier and you are more likely to partly automate the process.

Organisations should start using the most secure certificates they can obtain for all communications and not settle for less security. It is well worth the (littlebit of) extra money and they seem to become cheaper all the time. It is perfectly okay for them to use their own security authority for their data center.

Nobody should accept non secure communications. There is no argument left to leave security out of IT solutions. Especially when you are in some way connected to the Internet. And who isn’t?


One response to “A secure blanket”

Leave a Reply

strelitzia.net