Using SSL in your applications - think again

We are used to the padded lock that appears at the bottom of the browser when visiting sites having the https:// prefix. That's a visual cue to indicate that SSL is active for that web session. SSL is used by web application architects as a security mechanism to protect data. However there are a few limitations to bear in mind when relying only on SSL for your application security needs.

1. SSL operates at the transport level not at the application level
This simply means that do not use SSL to protect persistent data on your PC. SSL protects data on when it is on the wire between the client and the server. The data is decrypted after it has reached its destination. Consider this example - You enter in your credit card number on a web page. Assuming SSL is active, the credit card number is encrypted before leaving your PC. The encrypted credit card number travels protected over the wire right upto the web server, at which point it is decrypted by SSL. Thereafter the data is in clear. It is the responsibility of the web application to protect it after that point.

2. SSL protects either all the data or none at all
As mentioned in the previous point, SSL operates at the transport level. This means that applications do not get to decide what they wish to encrypt and what they dont. This can have performance impacts in some cases as I have found that a site that uses SSL through out its pages turns out kind of slow. If SSL is active, all data is protected. Period.

3. SSL does not provide non-repudiation services
Non-repudiation means the ability to provide irrefutable evidence that a certain operation had been carried out. SSL does not, and cannot, provide that service.

4. SSL is not always effective for securing web services
Web services are not always front-ended by web servers. There often arises a scenario in which the application directly communicates with the web service (without intervention of the web server). In such cases, SSL does not help.