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]

Message-ID: <871wumzka4.fsf@mid.deneb.enyo.de>
Date: Mon May 22 07:32:14 2006
From: fw at deneb.enyo.de (Florian Weimer)
Subject: Five Ways to Screw Up SSL

* Michal Zalewski:

>> 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.

There are some APIs in wide use which encourage this kind of misuse
(authenticate the CA, not the certificate holder) because doing it
right is somewhat difficult or allegedly has a performance impact
(copying the entire certificate to an environment variable, for
example).

>> SSL Mistake #3 - Falling back to TCP

> You are very, very seriously confused about the relation between SSL, TCP,
> and just about everything else.

Fallback to non-encrypted connections is quite common for protocols
like SMTP and IMAP.  I doubt this is a significant issue.  Protection
against passive eavesdropping is better than no protection at all.