Full Disclosure mailing list archives

Re: Five Ways to Screw Up SSL


From: Michal Zalewski <lcamtuf () dione ids pl>
Date: Sun, 21 May 2006 17:52:17 +0200 (CEST)

On Sun, 21 May 2006, Ginsu Rabbit 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.

SSL Mistake #1 - Trusting too many Certificate Authorities
Most SSL servers do not have this problem [...]

So why is it #1?

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.

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.

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?

/mz

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


Current thread: