SSL overuse or why do I hate certificates 1

If an IT architect needs some kind of secure connection in 99 out of 100 cases he will choose SSL. The standard is there, it is widely used, the implementation is trivial and the problem is solved. Being for ignorance or lack of creativity, SSL is overused in many of enterprise IT communication, which alone doesn’t guarantee the security and comes with indirect costs.

Common usage

Among others, the two main use-cases for SSL are to encrypt the communication and to authenticate the sender. Both are easy to exemplify: the first one is when you log in to a website sending your username and password and the second one is when you sign an e-mail with your personal certificate. In the corporate world, both cases also happens often, either a system is sending a message which contains sensitive data or system A wants to make sure that only system B is allowed to send a particular type of message.

All modern programming languages support SSL natively or via some free library and as most of the IT people have no idea of what it is and how it works, SSL became synonym of IT security.

Naive sense of security

I have no doubts that the SSL protocol itself gives you a pretty good cost-benefit solution. For Internet communication it is in most of the cases the only reasonable solution. Nevertheless, on a company Intranet if other factors are not taken into consideration at the end it is pretty useless. It is the same as locking your door with the hardest lock in the market and leaving the key under the carpet.

We can take both cases as example: In the first one, we want to make sure that a bad employee doesn’t have access to someone’s password and do bad things. In this case, SSL will prevents that this bad person can read the password in clear text after hacking into the network, injecting his sniffer in the Intranet backbone and listening to all the communication filtering exactly the login command from his target victim (like the NSA does with all the Internet communication).

Well, a bad person that smart, that evil and with such a deep knowledge of IT will probably considered some easier ways to achieve his goal (to look for the key under the carpet):

• Look at the DBs to see if the password is not saved with a very weak encryption (or no encryption at all). If he has access to the application source code it is even easier.
• Look at the log files (believe me I’ve seen clear text password in log files)
• Most of the systems are based on a session id. Having this session id would be enough to impersonate the victim without even knowing the password (if the developer doesn’t take proper care)
• Or just wait for the person to have a coffee and sneak to his computer to do his bad things.

For the second case we have the similar flaws. All the authentication is based on a client/server certificate. Anyone possessing such certificates can do his bad things. Most of the time the certificates are simply exchanged through e-mail or sitting in some network machine that everybody has access. Once again, is the same as leaving key under the carpet.

The price we pay

While the implementation cost is very low, there is one detail that everybody forgets about SSL: the certificates expires. The implication to your company is that, in the best case, every year for every communication between two systems one or more person will spend time to renew and redeploy the certificates in both ends (probably on test and QA environments too). You can multiply this by the number of interfaces in your company. In the worst case you will have one interface down and 10 persons trying to find out why this thing is no longer working and running like crazy to create new certificates and deploy them.

Another relevant cost is the network overhead and for this one I have a practical example: we have an interface that communicates with an external system via web-service. Daily upon some user approval up to 1000 XMLs are sent and must reach the destination before 12:00 AM. This thing runs stable almost everyday. Discarding delays in the user’s approval, in rare cases we perceive an unexplainable slowness in the network communication which make us cross the deadline. Last time this happened, we did a joint analysis of what was taking time. Against all odds, between reading the data from the DB, generating an XML, sending it to the destination over the Internet (no VPN) and having it parsed on the other side, guess who was the slowest process: The SSL handshake.

Back to the use-cases

Having learned that SSL doesn’t really come for free we should ask us the question: are we sending sensitive data? In the example above, no. Actually the information we are sending is public and published on the Internet.

Do we have to validate the recipient? If yes is there any other way of doing it?

We have another interface which is very similar to the one above. Actually the data is mostly the same, but the recipient and format are different. This second company when defining the protocol had a much more pragmatic approach: “The data that you are sending is public. I just want to make sure that only you can send it to me, so I must only validate the sender IP address.” Is it as secure as SSL? For sure it is simpler and cheaper and doesn’t involve replacing certificates every year. And as mention above, if there is someone so smart and so evil that can impersonate the sender IP address he would also be able to break a simple SSL communication (like the NSA does).