----- Original Message -----
> From: "Viktor Dukhovni" <openssl-us...@dukhovni.org>
> To: openssl-dev@openssl.org
> Sent: Friday, 28 March, 2014 5:48:37 PM
> Subject: Re: Insecure DEFAULT cipher set
>
> On Fri, Mar 28, 2014 at 10:40:33AM -0400, Hubert Kario wrote:
>
> > Because 3DES is required to provide backwards compatibility for
> > old clients and received extensive cryptanalysis, it should remain
> > in DEFAULT cipher set.
>
> As must RC4-SHA1. There are still considerably many Windows XP
> and Windows 2003 systems whose strongest working cipher-suite is
> RC4-SHA1, and whose 3DES cipher-suite implements broken CBC padding
> (perhaps the breakage is in appications rather than the TLS library,
> but this is not important).
I have not known that XP implementation of 3DES-CBC is broken, can
you provide some more info about that?
I know at least one e-bank website that uses 3DES exclusively, I'm
quite sure their clients wouldn't let them live if it did not
work on Win XP...
Also, current cipher order already uses 3DES before RC4...
I did see libraries that did implement just 3DES, I have not seen
ones that implement just RC4. And Internet servers that enable
just RC4 will quickly disappear since Win 8.1 does not support RC4.
> > Cipher suites with ciphers that have known weaknesses should be
> > moved to LOW set (that means RC4).
>
> Removing cipher-suites from the bottom of the cipherlist is an
> exercise in self-righteousness, but generally reduces security,
> because opportunistic connections will revert to cleartext when
> the TLS handshake fails. Even RC4 is noticeably better than
> cleartext, and is required for interoperability with older Microsoft
> systems.
Systems which use fallback to cleartext should be using the ALL set
in the first place.
> > DEFAULT set
> > ===========
>
> The cipherlist ordering MUST be consistent between "DEFAULT" and
> "ALL". In other-words, the "DEFAULT" cipher-suite MUST NOT revert
> to being a manual hack radically different from "ALL". Rather,
> the "DEFAULT" ciphersuite should simply be:
>
> DEFAULT := ALL:!COMPLEMENTOFDEFAULT
No problem, if it is required for other parts of OpenSSL to
function properly I can extend the definition of sorting rules to
ALL ciphersuites.
As a bonus it will make the opportunistic encryption faster too.
> and furthermore it MUST be the case that:
>
> HIGH := ALL:!MEDIUM:!LOW:!EXPORT
> MEDIUM := ALL:!HIGH:!LOW:!EXPORT
> LOW := ALL:!HIGH:!MEDIUM:!EXPORT
> EXPORT := ALL:!HIGH:!MEDIUM:!LOW
It can't be
HIGH := ALL:!MEDIUM:!LOW:!EXPORT:!aNULL:!eNULL
MEDIUM := ALL:!HIGH:!LOW:!EXPORT:!aNULL:!eNULL
LOW := ALL:!HIGH:!MEDIUM:!EXPORT:!aNULL:!eNULL
EXPORT := ALL:!HIGH:!MEDIUM:!LOW:!aNULL:!eNULL
because of channel binding, yes?
> > 2. Then by used cipher, with all ciphers that provide 128 bit security and
> > received extensive cryptanalysis treated as equivalent (Camellia, AES),
> > other ciphers should be excluded with the exception of 3DES
> > which should be placed last.
>
> This essentially requires augmenting the cipher key lengths with
> a cipher grade ordinal and changing @STRENGTH to sort on these, or
> adding a new @GRADE, which sorts on the new GRADE and does not
> distinguish between adequately strong ciphers, but then within each
> grade sort by algorithm preference and then bit-strength. (Not
> fastest first, see below).
This was only about the default ordering (be it DEFAULT or ALL).
I know that openssl cipher ordering algorithm will need changes to
accommodate this proposal. @STRENGTH will need fixing to support placing
3DES after AES128 (and probably RC4 after 3DES) anyway.
> > 3. Equivalent ciphers should be sorted by their performance (faster
> > first).
>
> That's a radical departure from existing practice. If you want to
> optimize for performance, allow users to exclude 256-bit cipher-suites
> entirely, they all have 128-bit equivalents that are faster. The
> DEFAULT ciphersuite should probably not take this step, the
> performance cipherlist can be some other cipherlist.
Problem is that some custom clients enable only 256 bit ciphersuites, so
even with server side cipher ordering, you are forced to negotiate
256 bit ciphers.
>
> +FAST:-FAST:DEFAULT
>
> where FAST includes all AES128 ciphers first (not CAMELLIA, because
> AES256 hardware is faster than CAMELLIA128 software).
FAST does not imply forward secrecy, in case of DHE it even is slower
for server...
> This does raise
> the point that performance is highly platform dependent, and no single
> ordering will properly optimize for performance on all platforms.
True, performance is highly platform dependant, but there is a very
high chance that at least one part of connection will have hardware
acceleration for AES. And for a specific platform AES128 is always
faster than AES256.
because performance is platform dependant, we can provide only a
reasonably good default, and in cases where the administrator wants
to make his SSL terminators faster, he will have to optimise for his
specific hardware configuration, IMHO, not something a FAST set can solve
> > 4. Then cipher suites should be sorted by used integrity mechanism: GCM,
> > SHA-2, SHA-1
>
> I think you mean AEAD not GCM specifically (GCM is perhaps an
> unfortunate choice of AEAD modes, but we're going down that rathole
> at this time).
yes, AEAD in general. I fixed it in "Integrity mechanism" section, but
missed it here
> > HIGH
> > ====
> >
> > This list should contain only ciphers that use AES and Camellia based
> > cipher suites (in other words, provide robust 128 bit security).
>
> That just means excluding 3DES, from HIGH.
Yes. But if this subject comes up in future again, we will have a record
of not only what was done, but /why/. Which I consider as important.
> > It should not contain cipher suites that don't offer authentication
> > (aNULL).
>
> SORRY, NO WAY, this breaks applications that do aNULL with channel
> binding
aah, right, missed that
Then we will have to leave aNULL ciphers in HIGH, MEDIUM and LOW but
that should be documented in the man page.
> One might define *new* elementary lists that do this, but don't break
> the existing HIGH, MEDIUM, LOW, EXPORT.
I think the "HIGH:!aNULL" and similar is good enough.
--
Regards,
Hubert Kario
BaseOS QE Security team
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
