Re: [Full-disclosure] Five Ways to Screw Up SSL

[Michal Zalewski <lcamtuf@xxxxxxxxxxxx>]

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/