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

Michal Zalewski <lcamtuf@...ne.ids.pl> wrote:
>You claim that this is a practical checklist for five very common problems
>with SSL deployments... but to me, they seem to be arbitrarily chosen,
>partly inaccurate (see #3), and otherwise very much random.

Inaccurate?  Not to my knowledge.  Incomplete, certainly,
but not inaccurate.  If you have additions or corrections
please send them through.

Random?  Slightly. =)

Arbitrary?  Not really.  Major applications have made and
continue to make these errors.  For example:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6249270
   Note the default setting of validate-server-cert.

http://www-128.ibm.com/developerworks/websphere/techjournal/0502_benantar/0502_benantar.html
   Check the section "Endpoint validation."

http://e-docs.bea.com/wls/docs81/config_xml/SSL.html#HostnameVerificationIgnored
   BEA gets the default configuration correct, but a fair
   number of administrators will set this to true.


> > SSL Mistake #1 - Trusting too many Certificate Authorities
> > Most SSL servers do not have this problem [...]
>
>So why is it #1?

The numbers *are* completely arbitrary.  They don't
indicate any kind of priority.


> > SSL Mistake #2 - Assuming a signed certificate is the right
> > certificate
>
>I don't understand what you're trying to say here: it seems to me that
>you're suggesting that allowing all users with a valid certificate the
>same privileges is a bad idea. Probably, but this has little to do with
>certificates or SSL - the same may be true for passwords or any other
>scheme.

Agreed.  However, application developers and administrators
generally have an intuitive understanding of password
authentication.  They don't understand client certificates
as well, and so they screw this up.

As an example of how easy it is to do, check out the IIS
documentation for requiring client certificates.  There are
two steps: the first is setting "Require client
certificates."  The second is setting up a mapping from
client certificates to accounts.  Other web servers have
similar configuration options.

People forget to do the second step, or they do it badly.
And so they treat all valid client certificates as
identical.  Microsoft's documentation for this is clearer
than most.  Other applications make it really difficult
to configure this mapping, and so administrators and
developers get it wrong.


> > 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.
> >
> > [...]
> >
> > 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.
>
>You are very, very seriously confused about the relation between SSL, TCP,
>and just about everything else.

I think my reference to a TCP connection instead of an
SSL connection may have been confusing.  I was referring
to the difference between sending data in clear-text over
a TCP connection vs establishing SSL over the TCP connection
and sending the data encrypted.

I've seen multiple applications where, if an SSL connection
failed, would try for an unencrypted connection instead.
The conversation that prompted this recommendation
went something like this.

"You can't fall back to an http connection here, if https
doesn't work you have to give up."
"Why?"
"Because an attacker could be eavesdropping, or they could
force you to talk to the wrong server."
"Huh?  If someone doesn't want to use http, they shouldn't
have a server running on port 80."

Some application developers have been told "use SSL for
these connections," but they don't understand why.  They
put too much faith in the privacy of TCP connections, and
in the authenticity of the IP addresses they use.  Because
they don't know of any methods to attack unencrypted
TCP connections, they assume it can't be done.

Does this clear up why I included mistake #3 in the list?


> > SSL Mistake #4 - Allowing insecure SSL ciphers
> >
> > This is not a paper about cryptography, and I am not going to tell you
> > which SSL ciphers are safe.
>
>Kind of defeats the purpose of a checklist, then?

No.  The goal of this particular recommendation is to make
people aware that they need to think about the SSL ciphers
they use.  Different applications have different legal and
policy requirements for SSL ciphers, and unfortunately in
many cases application developers are not aware of those
requirements.  They need to find out what policies apply to
their applications, and make sure that they enforce those
policies.

-- GR

_________________________________________________________________
Don’t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/

Powered by blists - more mailing lists