August 30, 2004

(In)securities of SSL

Today Mark Wagner asked me how secure SSL is, in the face of a MSDN presenter who said that SSL was only secure when sent from client to the server. Since I didn’t attend this session and hearing this 3rd hand, I can’t really comment to the extent of the presenter’s view, as I have no context to base his assumptions on.

However, as a security professional let me give you my take on the (in)securities of SSL.

SSL is one of those tools that give people a false sense of security. Touted as the end-all/be-all for eCommerce security, it has been shamelessly plugged as the best solution for secure transactions. The reality is that it is far from it.

SSL doesn’t provide the right protection mechanisms that you think it does, and actually does nothing to protect you when you expect it to. It really is nothing more than a secure communication channel with weak endpoints. It uses public key encryption and provides data encryption, server authentication, message integrity, and in some cases, even client authentication. These are all good things. And you rarely hear about attacks against the communication channel itself.

However, you are only as strong as your weakest link. In this case one aspect is the end points. Although you have data integrity across the SSL channel, once it hits the server or client it is decrypted and at the mercy of the machine. The attack path won’t be against the communications pipe, but rather the unencrypted data on the endpoint. Further to this, the weakest link is the human factor when it comes to security. It is common for administrators of these endpoints to misconfigure the SSL endpoint or use lax security policies for protecting this configuration, putting the tunnel at risk. I have seen a few cases in the past where people have used Linux boxes with OpenSSL and then have copies of their cert lying around (and worse yet world readable access to the private cert), which makes the tunnel moot; once an adversary has the private cert he can simply use it to decrypt the session midstream at any time. Actually, some application level firewalls use this to their advantage to allow them to “covertly” monitor SSL streams entering the network by decrypting the stream, reviewing the content, and then deciding whether or not to actually forward it to the real host you intended it to.

If history is an indication, attackers couldn’t care less about the stream. Most information disclosure incidents which relate to theft of data are actually done by breaching the host, and just taking it. Why? Because it is easier to use a weaker attack vector such as vulnerable software on the host than to try to breach an encrypted stream. It’s like spending $15,000 for a solid core oak door at the front of your house, and then leaving the $100 back door unlocked. Your effective level of security is really $100… not $15,000. (Some infosec pros would say the effective level of security is actually $0, the back door was open anyways… but that’s not the point)

Does this mean we shouldn’t use SSL? Far from it. Using SSL to secure communications is a good thingTM (sorry Martha… sue me from jail). But to really be effective solid security policies need to augment this by ensuring strong data protection of the data as it enters the host. Levels of data integrity and assurance need to be maintained by ensuring that as the data enters the system it continues to be protected. Further to this, remember that for secure communications SSL cannot be used to create a trust relationship between the client and the server. It can really only give you a CERTAIN level of assurance that you are connecting to the right server. An implicit trust level must occur in the stream for the exchange of data.

So Mark, SSL itself can be made secure in either direction. But that’s a moot point. Neither the client nor the server can be trusted past that without other methods of authentication and authorization to be in place for access to data.

Hope that answers your question.

Posted by SilverStr at August 30, 2004 09:12 AM | TrackBack
Comments

Dana, Thanks for your excellent response!

Posted by: Mark Wagner at August 30, 2004 11:44 AM

Using SSL to secure communications is a good thingTM (sorry Martha… sue me from jail)

Posted by: . at August 30, 2004 11:47 PM

Using SSL to secure communications is a good thingTM (sorry Martha… sue me from jail)

Posted by: . at August 30, 2004 11:48 PM