proposed text for crypto-policies in Packaging Guidelines

Reindl Harald h.reindl at thelounge.net
Fri Aug 8 14:45:02 UTC 2014


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/security/attachments/20140808/a9f6c136/attachment.sig>


More information about the security mailing list