Am 08.08.2014 um 16:30 schrieb Eric H. Christensen: > On Fri, Aug 08, 2014 at 04:11:51PM +0200, Reindl Harald wrote: >> Am 08.08.2014 um 15:44 schrieb Eric H. Christensen: >>> On Fri, Aug 08, 2014 at 03:36:51PM +0200, Reindl Harald wrote: >>>> Am 08.08.2014 um 15:21 schrieb Nikos Mavrogiannopoulos: >>>>> Postfix is a different kind of beast though. It does not typically use >>>>> TLS, but uses some kind of opportunistic security that allows anonymous >>>>> ciphersuites. So it's a bit hard to enforce anything there, as >>>>> man-in-the-middle attacks are possible by design >>> >>>> and keep in mind in case of opportunistic TLS if you restrict >>>> ciphers and the SMTP client don't support what you offer it >>>> falls back to completly plaintext which defeats the intention >>> >>> Falling back to an insecure cipher only provides a false sense of security >>> which isn't any better than plaintext. > >> you *can not* enforce ciphers for opportunistic TLS - period >> because that is the nature of *opportunistic* > > I agree with your assessment, however, ordering the ciphers that are to be used can still be done agreed, with caution below, that is still an issue and 64 is sadly exceeded with defaults and in future versions of openssl that will grow (new cipher types) [harry@srv-rhsoft:~]$ openssl ciphers -v | wc -l 75 71: RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 http://www.ietf.org/mail-archive/web/tls/current/msg10554.html The Windows 2003 TLS stack (still used by a non-trivial number of Microsoft Exchange SMTP servers) only looks at the first 64 elements of the cipherlist. If neither RC4-SHA nor RC4-MD5 are among these, it sometimes chooses 3DES (for which it misimplements CBC padding) and fails during data transfer, or if that is suppressed or also too far down the list, just fails the handshake
Attachment:
signature.asc
Description: OpenPGP digital signature
-- security mailing list security@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/security