Examining the protection provided by SSL

If you’ve attended one of our web application security classes or seminars you’ve probably heard us say “SSL does not provide application security.” It’s true. While SSL can provide great protection for data traveling across a network, it doesn’t do anything to stop most web application attacks.

Which isn’t to say we discourage SSL; just the opposite is true. You should use SSL any time you need to protect the transmission of user credentials, authentication session IDs, or other confidential content. SSL can go a long ways towards making sure your users can still safely use your application even when connecting over untrusted networks.

One question we are frequently asked is “does SSL protect the contents of URLs as well as the contents of web pages?” The answer is yes. If your application stores sensitive information as parameters in the URL these values are not exposed to anyone other than the user. The same goes for all other information in the HTTPS header. A bad guy sniffing network traffic will only see packets containing basic TCP/IP information and an encrypted data payload traveling between the client and web server.

Another question we hear is “when does SSL start protecting transmitted data?” These folks are typically worried that sensitive URL parameters might be exposed if they are included in the very first HTTPS request to the web server. Luckily, these requests are also protected.

Here’s how SSL works: A client performs a basic TCP/IP handshake with the web server, then completes the SSL certificate and key exchange, and finally requests the URL over the encrypted channel. It’s nice to know your data can be encrypted from beginning to end using SSL.

Have other questions about SSL? Let us know and we will try to answer it in an upcoming blog post.