full-disclosure - Five Ways to Screw Up SSL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sun May 21 16:52:24 2006
From: lcamtuf at dione.ids.pl (Michal Zalewski)
Subject: Five Ways to Screw Up SSL

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