Summary: Although SSL does provide an encrypted layer of protection to Web transactions, it is not the answer to every security concern. This week, Bri overviews SSL and casts a critical eye on its advantages and disadvantage.

Anyone who has filed out their personal or billing info online has likely entered it via a 'secure Web server'. You can tell the transmission is secure because the URL reads 'https://...' instead of http. SSL , the secure sockets layer protocol, is the 'S' in HTTPS. [1]

The beauty of SSL is its integration into most Web browsers, where it invisibly encrypts Web transactions and prevents any attacker in the middle from seeing the data you send and receive. Attackers can see that you are making a connection to the remote system, but not the transmission's content itself. SSL even authenticates the server, so when you hit https://microsoft.com/jobs/stop_bugging_me.asp, you know that you are talking to the Evil Empire and no cracker could be positioned between you, intercepting or modifying the packets.

Unfortunately, many folks look at SSL as the magic answer to all security concerns. Every three months or so, I find myself giving a discussion about what SSL does and does not protect.

SSL guarantees:

• The server you want to contact is the one you got. SSL verifies that the server's certificate (similar to a public key) is signed by a trusted entity from your browser's preinstalled list of companies that it trusts. [2]

• No attacker can read or modify the data being transmitted between you and the Web server.

That's it, and nothing else. In fact, if you got a warning about a certificate problem and you blindly click, 'Ok, ok, sure, whatever, yeah', then you aren't even guaranteed the above two points.

Now let's see a partial list of things that SSL does not protect you from:

• Host Insecurities -- People frequently think that having an SSL- enabled Web server, often just called a 'secure Web server,' secures the machine itself. No, you still need to keep patches up to date, harden your system, turn off unneeded services, and check your logs.

• Stupid Programming (CGI/mod_perl/etc) Mistakes -- The transmission may be encrypted but an attacker can still connect and try to break your buggy software. And since it's encrypted, your IDS systems can't even warn you about it.

• Is the Web page Run by the People You Think? -- The SSL certificate is based on the host name, nothing else. I can get a certificate for 'buildinglinuxvpns.net' since I own it. However, I can whip up the content that looks just like your bank, complete with forms for account numbers and passwords, and host it there. I could even have it relay the info to your bank such that it shows you everything exactly as it should be, but saving a decrypted copy the whole while.

  You're not likely to fall for this trick with such a blatantly unrelated URL, but what if an attacker registered 'www.my_banks.com' when the real URL was supposed to be 'www.my_bank.com'? An easy typo, and you may never notice the difference.

• Backend cleartext storage and transmissions. Many Web servers get and store data using outside sources, such as databases or flat files. You may be entering your credit card on a secure channel, but they may still be taking it and emailing it in the clear to their main office for processing.

You may feel that many of the things I listed above are obvious. For that matter, you may feel offended that I'd even mention some of them. However I find that people are often confused, and don't realize where the security of SSL begins and ends. This usually results in hours of bickering about security needs before we figure out exactly where the faulty assumptions came from.

NOTES

[1] TLS, the Transport Layer Security protocol, is the latest/greatest version of SSL, but it's not as widely available in browsers so most folks still just say SSL. However SSL/TLS is more accurate.

[2] Now how much you trust the folks who wrote your browser is a different question all together.

Bri Hatch is Chief Hacker at Onsight, Inc, author of Hacking Linux Exposed and Building Linux VPNs, and the maintainer of http://www.stunnel.org, home to Stunnel, the Universal SSL Wrapper. He likes SSL, really. He just doesn't like seeing it abused, mistreated, or expected to cure cancer. Bri can be reached at bri@hackinglinuxexposed.com.

Copyright Bri Hatch, 2002.

This article was first published here in ITworld.com Inc., 118 Turnpike Rd., Southborough, MA 01772  on 23-Apr-2002.