SSL is Not a Magic Bullet

by Brian Hatch

April 22, 2002 —

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 (http://www.webopedia.com/TERM/S/SSL.html), 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. [1]
* 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.

ITworld