Message-ID: <BAY21-F9D577AEFB6DCDCEA1DC9BA7A50@phx.gbl>
Date: Sun May 21 16:26:16 2006
From: ginsurabbit at hotmail.com (Ginsu Rabbit)
Subject: Five Ways to Screw Up SSL

Five Ways to Screw Up SSL

SSL is a wonderful protocol, but it is frequently used
badly.  This note is intended to point out some of the more
common errors made by applications using SSL.

This checklist should be useful for application developers,
system administrators, and the occasional penetration
tester.  This note assumes you have at least a casual
knowledge of SSL, but is not a paper about cryptography.  If
you know enough to write an SSL library, you will know
every single one of the mistakes I mention below, plus a
few more.  Still, I hope that those of you who are writing
SSL toolkits will consider why these mistakes are made.
Perhaps it will help you design your toolkits so that
novices use them correctly.


SSL Mistake #1 - Trusting too many Certificate Authorities

Most SSL servers do not have this problem, since it only
affects those applications that need to verify
certificates.  If you are dealing with an SSL client
application, or your SSL server expects clients to
authenticate using certificates, you need to consider which
certificate authorities you trust to sign certificates.

Somewhere on your system there is probably a file
containing a few dozen trusted CA certificates, belonging
to big names like Verisign, RSA, and Entrust.  All of these
certificate authorities are businesses.  Someone pays them
money, and they give that someone a signed certificate.
Verisign has several hundred thousand customers.  For some
applications, such as a web browser, it might make sense to
trust those several hundred thousand people simply because
they have paid Verisign money.  For an application with
tighter security requirements, accepting every certificate
signed by major CA is a horribly bad idea.

If you trust everyone with one of those certificates, you
run the risk of an attacker paying $50 to a CA, getting a
certificate, and using that certificate to authenticate to
your application.  The CA is not to blame when that happens:
they publish descriptions of exactly what they do to verify
identities before issuing certificates.  If a CA's level of
identity verification is not acceptable for your business,
you should not trust that CA.  It may be that there is no
public CA sufficiently trustworthy for your purposes.  In
that case, you should use self-signed certificates, or you
could even create your own CA to issue certificates to the
people you want to use your application.

Most applications trust all of the major root CA
certificates by default.  Administrators, you need to
correct that situation by deleting all of those
certificates, and adding back only the CA certificates you
intend to trust.

This should not need to be said, but some applications
include demonstration or test certificates.  Never trust
those certificates for anything.  Everyone and their little
brother has a copy, which means those certificates provide
no identity verification whatsoever.  Throw them away.

Now.

I'll wait.


SSL Mistake #2 - Assuming a signed certificate is the right
certificate

Again, you can skip this section if your application does
not need to verify certificates.

Many applications use the following algorithm to verify
certificates:

- Did the SSL toolkit think the certificate was valid?
- If so, allow access.

That system has a serious flaw: it performs authentication,
but not authorization.  Just because someone has a valid
certificate doesn't mean you want to let them use your
application.  Would you grant everyone with a valid user-id
and password administrative access to the system? Probably
not.  Don't grant everyone with a valid certificate the same
rights.  Consider who they are, and what you want them to
do.

Many HTTP clients perform the authorization step by
comparing the common name (CN) attribute of the certificate
to the host name of the URL they are trying to access.  If
the host name and the CN match, the client completes the
connection.  If the host name and the CN don't match, someone
is trying to impersonate the HTTP server, and the client
needs to abort the connection.  Some SSL clients skip the
authorization step entirely.  Other clients try to do the
SSL verification properly, but fall back to an insecure
connection if the SSL verification fails.  That brings us to
the next common error.


SSL Mistake #3 - Falling back to TCP

A surprising number of SSL client applications use the
following "logic":

- Try to make an SSL connection.
- If the SSL connection succeeds, great!
- Otherwise, the administrator probably made a mistake.  Go
ahead and use a TCP connection instead.

This is great for usability, but it completely defeats the
purpose of using SSL.  If your application falls back to a
TCP connection, you have none of the security provided by
SSL.  If an application is supposed to establish an SSL
connection but can't, then the application needs to abort
the connection and report an error.  Falling back to TCP is
not a good idea.

For some examples of why falling back to TCP is not a good
idea, please search the web for "promiscuous mode", "DNS
cache poisoning", "ARP cache poisoning", or "IP spoofing".
The internet is not a friendly place.  SSL was invented for
a reason.


SSL Mistake #4 - Allowing insecure SSL ciphers

Of all the mistakes listed in this note, perhaps only this
one is really the fault of the SSL toolkit used.  Certain
SSL ciphers provide little or no security.  Most application
developers do not have the knowledge to select an
appropriate set of acceptable SSL ciphers, so the SSL
implementation should only use strong ciphers unless
explicitly instructed otherwise.

This is not a paper about cryptography, and I am not going
to tell you which SSL ciphers are safe.  If you are
uncertain which SSL ciphers are acceptable for your
purposes, ask an expert.  You can test your application for
some of the more blatantly insecure ciphers using the
openssl s_server and s_client applications with the
'-cipher aNULL' or '-cipher eNULL' options.


SSL Mistake #5 - Thinking SSL is magic

Avoiding all of the other mistakes mentioned in this note
does not make your application secure.  When everything is
done properly, SSL provides strong authentication and
privacy.  Those are both good things, but they are not the
same thing as a secure application.  You need to understand
the threats that are relevant to you, and defend against
those threats.  SSL is an important tool for secure
applications.  It is not a magic wand.

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Powered by blists - more mailing lists