Insecure DEFAULT cipher set

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Insecure DEFAULT cipher set

Hubert Kario
DEFAULT cipher set contains known broken cipher suites, in order which neither
provides maximum security or optimal performance.

This proposal aims to make openssl cipher order secure by default and increase
performance without decreasing security in common deployments of TLS.



Currently OpenSSL sorts ciphers according to key size first, then key exchange
and finally the mac used.

This does not result in a list sorted by strength (as the documentation would
suggests). Ciphers using 3DES use 168 bit key but because of meet
in the middle attack, the effective cipher strength is 112 bit, see [NIST
SP800-57] and [ENISA] for details.

Current cipher order also does put ciphers that don't provide Forward Secrecy
above ciphers that do (AES256-SHA is the most prominent example).

Additionally, the default cipher list contains export grade ciphers (which never
were secure) and RC4 (which we now know are not secure) [1], [2], [3], [4].

Note that while I do concentrate on HTTPS services and clients, the underlying
libraries used by browsers and web clients have the same limitations or usually
use the same defaults for all TLS clients and servers. HTTPS is also the most
commmonly used TLS protocol on the Internet for which users security depends on.

I also don't suggest removing support for broken or insecure ciphers completely,
the only functionality affected will be the DEFAULT, HIGH, MEDIUM and LOW cipher
sets.

Proposed ordering
=================

This proposal largely follows the one put forth by Brian Smith in Proposal to
Change the Default TLS Ciphersuites Offered by Browsers[5] and implemented by
new Firefox. The main differences are caused by the fact that servers do not
have to limit the cipher list to workaround problems in SSL terminators related
to Client Hello size. As such, the DEFAULT list can include all cipher suites
generally regarded as secure.


Rationale
=========

The change is needed because with some clients OpenSSL is not able to negotiate
optimal cipher (either the most secure or one that offers at least 128 bit
security and PFS). For example older Android clients, Java or older Windows
(XP, 2k3). It is also needed because of the new threats that current usage of
crypo on Internet needs to face.


Forward secrecy
---------------

Currently many commercial CAs use 2048 bit RSA keys signed with SHA-1 and only
recently started migration to SHA-256. This makes most of keys used currently on
the Internet to be weak by cryptographic standards. Even if the migration to
SHA-256 is completed, 2048 bit RSA keys are secure only up to 2030 (see [NIST
SP800-57] and [ENISA]).

Using suites that provide forward secrecy allows to preserve security of data
past 2030, even with current CA infrastructure.

Those cipher suites also protect against compromise of server private key, which
while uncommon, does happen.

Because of that, we want to prioritise ciphers that provide PFS over ones that
don't.


Integrity mechanism
-------------------

Because TLS uses the MAC-then-encrypt mechanism, it is hard to perform
decryption in a way that does not leak timing information. In fact, there were
many vulnerabilities that exploited this problem (see Gutmann extenstion
draft[6]) the most recent being Lucky 13[7].

Because AEAD cipher suites are not vulnerable to them, we want to use them
before regular cipher suites.

This effectively doesn't change the current ordering with regards to integrity
mechanism.


Ciphers
=======


128 vs 256 bit
--------------

Ciphers that provide at least 128 bit security and received extensive
cryptanalysis should be considered equivalent (PFS and MAC mechanism not
withstanding).

This is mostly caused by the complexity of configuring the whole crypto system
to support above 128 bit crypto. Non exhaustive list of items that need to
be addressed before system reaches effective level of security above 128bits:

 * No commercial CA uses 15k RSA or 521bit ECDSA keys
 * Servers like Apache or nginx encrypt TLS session tickets using AES-128-CBC
 * SHA-1 MAC does not provide enough security, so the server effectively can
   support only TLSv1.2 clients
 * both ECDHE and DHE parameters used by Apache don't provide 256 or 192 bit
   security
 * There are no standard 15k DHE parameters so the administrator needs to
   generate them himself or herself (which takes a lot of time)
 * Support for 521bit NIST curve is limited among clients, on the other hand
   15k RSA and DHE operations are very slow
 * Both the server and client must have access to good entropy sources and use
   more of it for key derivation (eg. SSL Random Seed Directive in Apache)

The need to change offered cipher suite set is part of this process.

As such, moving 128bit ciphers above 256bit security doesn't reduce the security
of the whole crypto system in general case while provides higher performance.
For systems with AES-NI and SSE3, AES-GCM is the fastest cipher available in TLS (I
measured speeds in excess of 1GB/s on a mobile Intel i7, twice the speed of
aes-128-cbc without any MAC).

In cases where administrator still wants to put 256 bit ciphers before 128bit
ones, he should be able to do that just by using @STRENGTH.


Camellia vs AES
---------------

Because of performance, Camellia ciphers should be placed after AES ciphers (PFS
mechanism not withstanding).

While hardware acceleration for AES is relatively widespread, there are
virtually no hardware accelerators of Camellia. Fully software implementation of
AES and Camellia have similar performance (depending on platform, AES or
Camellia is faster).


Weak ciphers
------------

Cipher suites with ciphers that didn't receive extensive cryptanalysis should
not be placed in DEFAULT cipher set (meaning IDEA and SEED). Since 3DES based
cipher suites don't provide 128bit security but they don't have known
weaknesses, they should also be placed in MEDIUM.

Because 3DES is required to provide backwards compatibility for old clients and
received extensive cryptanalysis, it should remain in DEFAULT cipher set.
But because it provides only 112 bit security and has very low performance, all
cipher suites that use it should be placed last in cipher order.

Cipher suites with ciphers that have known weaknesses should be moved to LOW set
(that means RC4).

To limit the chances of "unpleasant surprise", the cipher suites in DEFAULT,
HIGH, MEDIUM or LOW set should not include cipher suites that don't perform
authentication or encryption. Environments in which such configuration are
desirable are very specific and will require modification of used cipher set
anyway.


DEFAULT set
===========

 1. The cipher suites should first be sorted by the key exchange, ECHDE first,
    then DHE, non ephemeral, finally SRP and PSK.
 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.
 3. Equivalent ciphers should be sorted by their performance (faster first).
 4. Then cipher suites should be sorted by used integrity mechanism: GCM,
    SHA-2, SHA-1

3DES ciphers are left in only because of compatibility with old implementations
that do not support AES ciphers.

This results in following cipher order:

ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-SHA256
ECDHE-ECDSA-AES128-SHA256
ECDHE-RSA-AES128-SHA
ECDHE-ECDSA-AES128-SHA
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA384
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES256-SHA
ECDHE-ECDSA-AES256-SHA
DHE-DSS-AES128-GCM-SHA256
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-SHA256
DHE-DSS-AES128-SHA256
DHE-RSA-AES128-SHA
DHE-DSS-AES128-SHA
DHE-DSS-AES256-GCM-SHA384
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-SHA256
DHE-DSS-AES256-SHA256
DHE-RSA-AES256-SHA
DHE-DSS-AES256-SHA
DHE-RSA-CAMELLIA128-SHA
DHE-DSS-CAMELLIA128-SHA
DHE-RSA-CAMELLIA256-SHA
DHE-DSS-CAMELLIA256-SHA
ECDH-RSA-AES128-GCM-SHA256
ECDH-ECDSA-AES128-GCM-SHA256
ECDH-RSA-AES128-SHA256
ECDH-ECDSA-AES128-SHA256
ECDH-RSA-AES128-SHA
ECDH-ECDSA-AES128-SHA
ECDH-RSA-AES256-GCM-SHA384
ECDH-ECDSA-AES256-GCM-SHA384
ECDH-RSA-AES256-SHA384
ECDH-ECDSA-AES256-SHA384
ECDH-RSA-AES256-SHA
ECDH-ECDSA-AES256-SHA
DH-DSS-AES128-GCM-SHA256
DH-RSA-AES128-GCM-SHA256
DH-RSA-AES128-SHA256
DH-DSS-AES128-SHA256
DH-RSA-AES128-SHA
DH-DSS-AES128-SHA
DH-DSS-AES256-GCM-SHA384
DH-RSA-AES256-GCM-SHA384
DH-RSA-AES256-SHA256
DH-DSS-AES256-SHA256
DH-RSA-AES256-SHA
DH-DSS-AES256-SHA
DH-RSA-CAMELLIA128-SHA
DH-DSS-CAMELLIA128-SHA
DH-RSA-CAMELLIA256-SHA
DH-DSS-CAMELLIA256-SHA
AES128-GCM-SHA256
AES128-SHA256
AES128-SHA
AES256-GCM-SHA384
AES256-SHA256
AES256-SHA
CAMELLIA128-SHA
CAMELLIA256-SHA
PSK-AES128-CBC-SHA
PSK-AES256-CBC-SHA
SRP-DSS-AES-128-CBC-SHA
SRP-RSA-AES-128-CBC-SHA
SRP-DSS-AES-256-CBC-SHA
SRP-RSA-AES-256-CBC-SHA
ECDHE-RSA-DES-CBC3-SHA
ECDHE-ECDSA-DES-CBC3-SHA
DHE-RSA-DES-CBC3-SHA
DHE-DSS-DES-CBC3-SHA
ECDH-RSA-DES-CBC3-SHA
ECDH-ECDSA-DES-CBC3-SHA
DH-RSA-DES-CBC3-SHA
DH-DSS-DES-CBC3-SHA
DES-CBC3-SHA
PSK-3DES-EDE-CBC-SHA
SRP-DSS-3DES-EDE-CBC-SHA
SRP-RSA-3DES-EDE-CBC-SHA

(this sorting can be simulated using following cipher string:
kEECDH:+kEECDH+AES256:+kEECDH+CAMELLIA128:+kEECDH+CAMELLIA256:
kEDH:+kEDH+AES256:+kEDH+CAMELLIA128:+kEDH+CAMELLIA256:
kECDH:+kECDH+AES256:+kECDH+CAMELLIA128:+kECDH+CAMELLIA256:
kDH:+kDH+AES256:+kDH+CAMELLIA128:+kDH+CAMELLIA256:
kRSA:+kRSA+AES256:+kRSA+CAMELLIA128:+kRSA+CAMELLIA256: kPSK:+kPSK+AES256:
kSRP:+kSRP+AES256: !aNULL:!eNULL:!SSLv2:!RC4:!DES:!EXP:!SEED:!IDEA:+3DES )


HIGH
====

This list should contain only ciphers that use AES and Camellia based cipher
suites (in other words, provide robust 128 bit security). It should not contain
cipher suites that don't offer authentication (aNULL). It may contain suites
that don't use certificate based authentication (SRP, PSK). It should follow the
same cipher ordering rules as the DEFAULT cipher list.

MEDIUM
======

This list should contain only ciphers that don't have obvious shortcomings or
don't provide 128 bit security.

In other words, 3DES based cipher suites, IDEA, SEED. It should not contain
cipher suites that don't offer authentication (aNULL). It may contain suites
that don't use certificate based authentication (SRP, PSK). It should follow the
same cipher ordering rules as the DEFAULT cipher list.

LOW
===
This list should contain ciphers with known weaknesses: RC4, RC2, 56 bit DES and
export grade cipher suites. It should not contain cipher suites that don't offer
authenticaion (aNULL). It may contain suites that don't use certificate based
authentication (SRP, PSK).



References
==========

 NIST SP800-57 -
http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.
pdf

 ENISA -
http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/
algorithms-key-sizes-and-parameters-report

 1 -
http://blog.cryptographyengineering.com/2013/03/attack-of-week-rc4-is-kind-of-
broken-in.html

 2 - http://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-01
 
 3 -
http://blogs.technet.com/b/srd/archive/2013/11/12/security-advisory-2868725-
recommendation-to-disable-rc4.aspx

 4 - http://www.isg.rhul.ac.uk/tls/
 
 5 - https://briansmith.org/browser-ciphersuites-01.html
 
 6 - http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-mac-05
 
 7 - http://www.isg.rhul.ac.uk/tls/Lucky13.html

--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
http://wiki.brq.redhat.com/hkario
Email: [hidden email]
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Insecure DEFAULT cipher set

Dr. Stephen Henson
On Fri, Mar 28, 2014, Hubert Kario wrote:

>
> Currently OpenSSL sorts ciphers according to key size first, then key exchange
> and finally the mac used.
>
> This does not result in a list sorted by strength (as the documentation would
> suggests). Ciphers using 3DES use 168 bit key but because of meet
> in the middle attack, the effective cipher strength is 112 bit, see [NIST
> SP800-57] and [ENISA] for details.
>

To address this I'd suggest we just change the security bits for 3DES
ciphersuites to 112 bits in the SSL_CIPHER structure. The SSL_CIPHER structure
has separate fields for key length and security bits.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Insecure DEFAULT cipher set

Hubert Kario
----- Original Message -----

> From: "Dr. Stephen Henson" <[hidden email]>
> To: [hidden email]
> Sent: Friday, 28 March, 2014 3:55:28 PM
> Subject: Re: Insecure DEFAULT cipher set
>
> On Fri, Mar 28, 2014, Hubert Kario wrote:
>
> >
> > Currently OpenSSL sorts ciphers according to key size first, then key
> > exchange
> > and finally the mac used.
> >
> > This does not result in a list sorted by strength (as the documentation
> > would
> > suggests). Ciphers using 3DES use 168 bit key but because of meet
> > in the middle attack, the effective cipher strength is 112 bit, see [NIST
> > SP800-57] and [ENISA] for details.
> >
>
> To address this I'd suggest we just change the security bits for 3DES
> ciphersuites to 112 bits in the SSL_CIPHER structure. The SSL_CIPHER
> structure
> has separate fields for key length and security bits.

Problem is, that while 3DES provides about 112 bits of security, RC4 with
128bit keys is certainly weaker. So its security level should also be
adjusted.

Why do you want to change just this? What are the reasons for not making
the default cipher set secure?

--
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                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Insecure DEFAULT cipher set

Dr. Stephen Henson
On Fri, Mar 28, 2014, Hubert Kario wrote:

> ----- Original Message -----
> > From: "Dr. Stephen Henson" <[hidden email]>
> > To: [hidden email]
> > Sent: Friday, 28 March, 2014 3:55:28 PM
> > Subject: Re: Insecure DEFAULT cipher set
> >
> > On Fri, Mar 28, 2014, Hubert Kario wrote:
> >
> > >
> > > Currently OpenSSL sorts ciphers according to key size first, then key
> > > exchange
> > > and finally the mac used.
> > >
> > > This does not result in a list sorted by strength (as the documentation
> > > would
> > > suggests). Ciphers using 3DES use 168 bit key but because of meet
> > > in the middle attack, the effective cipher strength is 112 bit, see [NIST
> > > SP800-57] and [ENISA] for details.
> > >
> >
> > To address this I'd suggest we just change the security bits for 3DES
> > ciphersuites to 112 bits in the SSL_CIPHER structure. The SSL_CIPHER
> > structure
> > has separate fields for key length and security bits.
>
> Problem is, that while 3DES provides about 112 bits of security, RC4 with
> 128bit keys is certainly weaker. So its security level should also be
> adjusted.
>
> Why do you want to change just this? What are the reasons for not making
> the default cipher set secure?
>

I wasn't suggesting just changing that. I was addressing that specific point.

I agree that the defaults should be made secure.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Insecure DEFAULT cipher set

Viktor Dukhovni
In reply to this post by Hubert Kario
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).

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

> To limit the chances of "unpleasant surprise", the cipher suites in DEFAULT,
> HIGH, MEDIUM or LOW set should not include cipher suites that don't perform
> authentication or encryption.

This is already the case.

> 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

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

in other words all elementary (non-composite) built-in cipher-suite
classes should have the same relative order of their component
cipher-suites (obtained by applying a suitable filter to the
internall pre-sorted ALL).

Everything below should be either a specification of how to order
"ALL" or what to include in COMPLEMENTOFDEFAULT.

>
>  1. The cipher suites should first be sorted by the key exchange,
>     ECHDE first, then DHE, non ephemeral, finally SRP and PSK.

Note, we don't really know that ECDHE is more secure than DHE, but
it is more interoperable, because the curve is negotiated.  Also
ECDHE performs better on the server side.

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

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

        +FAST:-FAST:DEFAULT

where FAST includes all AES128 ciphers first (not CAMELLIA, because
AES256 hardware is faster than CAMELLIA128 software).  This does raise
the point that performance is highly platform dependent, and no single
ordering will properly optimize for performance on all platforms.

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

> 3DES ciphers are left in only because of compatibility with old
> implementations that do not support AES ciphers.

Ditto RC4-SHA1, which is much more broadly interoperable.

> kEECDH:+kEECDH+AES256:+kEECDH+CAMELLIA128:+kEECDH+CAMELLIA256:
> kEDH:+kEDH+AES256:+kEDH+CAMELLIA128:+kEDH+CAMELLIA256:
> kECDH:+kECDH+AES256:+kECDH+CAMELLIA128:+kECDH+CAMELLIA256:
> kDH:+kDH+AES256:+kDH+CAMELLIA128:+kDH+CAMELLIA256:
> kRSA:+kRSA+AES256:+kRSA+CAMELLIA128:+kRSA+CAMELLIA256: kPSK:+kPSK+AES256:
> kSRP:+kSRP+AES256: !aNULL:!eNULL:!SSLv2:!RC4:!DES:!EXP:!SEED:!IDEA:+3DES )

- Sort "ALL", not "DEFAULT".  Since "ALL" already excludes "eNULL",
obtain DEFAULT from ALL via:

        DEFAULT := ALL:!aNULL:!SEED:!IDEA:!EXPORT:!LOW

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

> It should not contain cipher suites that don't offer authentication
> (aNULL).

SORRY, NO WAY, this breaks applications that do aNULL with channel
binding or want strong passive eavesdropping protection, but can't
authenticate the peer.  DO NOT confuse crypto strength with
authentication.  To get the "HIGH" you want (no pun intended), use:

        HIGH:!COMPLEMENTOFDEFAULT

which is likely the same as:

        HIGH:!aNULL

> It should follow the same cipher ordering rules as the DEFAULT cipher list.

Already covered if all ordering is descended from "ALL".

> MEDIUM
> ======
>
> This list should contain only ciphers that don't have obvious shortcomings or
> don't provide 128 bit security.

It MUST include RC4-SHA1, and MUST also include aNULL ciphers where
applicable.  That is, like HIGH, it DOES NOT exclude COMPLEMENTOFDEFAULT.

To get the MEDIUM you want, use either of:

        MEDIUM:!COMPLEMENTOFDEFAULT
        MEDIUM:!aNULL

One might define *new* elementary lists that do this, but don't break
the existing HIGH, MEDIUM, LOW, EXPORT.

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Insecure DEFAULT cipher set

Tim Hollebeek-3
Windows XP is no longer a supported operating system.  If you require compatibility with it, use a non-default cipher suite.  It really is time for RC4-SHA1 to go away.

-Tim

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Viktor Dukhovni
Sent: Friday, March 28, 2014 12:49 PM
To: [hidden email]
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).

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

> To limit the chances of "unpleasant surprise", the cipher suites in
> DEFAULT, HIGH, MEDIUM or LOW set should not include cipher suites that
> don't perform authentication or encryption.

This is already the case.

> 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

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

in other words all elementary (non-composite) built-in cipher-suite classes should have the same relative order of their component cipher-suites (obtained by applying a suitable filter to the internall pre-sorted ALL).

Everything below should be either a specification of how to order "ALL" or what to include in COMPLEMENTOFDEFAULT.

>
>  1. The cipher suites should first be sorted by the key exchange,
>     ECHDE first, then DHE, non ephemeral, finally SRP and PSK.

Note, we don't really know that ECDHE is more secure than DHE, but it is more interoperable, because the curve is negotiated.  Also ECDHE performs better on the server side.

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

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

        +FAST:-FAST:DEFAULT

where FAST includes all AES128 ciphers first (not CAMELLIA, because
AES256 hardware is faster than CAMELLIA128 software).  This does raise the point that performance is highly platform dependent, and no single ordering will properly optimize for performance on all platforms.

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

> 3DES ciphers are left in only because of compatibility with old
> implementations that do not support AES ciphers.

Ditto RC4-SHA1, which is much more broadly interoperable.

> kEECDH:+kEECDH+AES256:+kEECDH+CAMELLIA128:+kEECDH+CAMELLIA256:
> kEDH:+kEDH+AES256:+kEDH+CAMELLIA128:+kEDH+CAMELLIA256:
> kECDH:+kECDH+AES256:+kECDH+CAMELLIA128:+kECDH+CAMELLIA256:
> kDH:+kDH+AES256:+kDH+CAMELLIA128:+kDH+CAMELLIA256:
> kRSA:+kRSA+AES256:+kRSA+CAMELLIA128:+kRSA+CAMELLIA256: kPSK:+kPSK+AES256:
> kSRP:+kSRP+AES256:
> !aNULL:!eNULL:!SSLv2:!RC4:!DES:!EXP:!SEED:!IDEA:+3DES )

- Sort "ALL", not "DEFAULT".  Since "ALL" already excludes "eNULL", obtain DEFAULT from ALL via:

        DEFAULT := ALL:!aNULL:!SEED:!IDEA:!EXPORT:!LOW

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

> It should not contain cipher suites that don't offer authentication
> (aNULL).

SORRY, NO WAY, this breaks applications that do aNULL with channel binding or want strong passive eavesdropping protection, but can't authenticate the peer.  DO NOT confuse crypto strength with authentication.  To get the "HIGH" you want (no pun intended), use:

        HIGH:!COMPLEMENTOFDEFAULT

which is likely the same as:

        HIGH:!aNULL

> It should follow the same cipher ordering rules as the DEFAULT cipher list.

Already covered if all ordering is descended from "ALL".

> MEDIUM
> ======
>
> This list should contain only ciphers that don't have obvious
> shortcomings or don't provide 128 bit security.

It MUST include RC4-SHA1, and MUST also include aNULL ciphers where applicable.  That is, like HIGH, it DOES NOT exclude COMPLEMENTOFDEFAULT.

To get the MEDIUM you want, use either of:

        MEDIUM:!COMPLEMENTOFDEFAULT
        MEDIUM:!aNULL

One might define *new* elementary lists that do this, but don't break the existing HIGH, MEDIUM, LOW, EXPORT.

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]


________________________________

This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Insecure DEFAULT cipher set

Viktor Dukhovni
On Fri, Mar 28, 2014 at 05:23:45PM +0000, Tim Hollebeek wrote:

> Windows XP is no longer a supported operating system.  If you
> require compatibility with it, use a non-default cipher suite.  It
> really is time for RC4-SHA1 to go away.

That's nice, but wishing it, does not make it so.  There are still
many Windows 2003 servers running IIS and Exchange 2007, that only
support RC4-SHA1.

Making a deployed system more secure is largely engineering, not
mathematics and there are trade-offs to consider, and some naive
attempts to increase security weaken it instead.

Just because SP-800 lives in a legacy-free utopia of balanced
algorithms, does not mean that one should follow SP-800 to the
letter.  In the real world better security is sometimes attained
by not following SP-800 too closely.

Many of these bar-raising exercises, run entirely counter to recent
efforts at IETF to promote "opportunistic security", where you do
the best you can to resist pervasive monitoring, even if it means
less strong minimum security (unauthenticated, ...).

The primary threat is not pervasive brute-forcing of somewhat
tarnished existing crypto, rather it is the vast majority of
traffic that is in the clear.

Raising the bar to the point where many applications are not
tall enough to take the ride is counter-productive.

TLS negotiates most parameter values to the strongest mutually
available (DH prime size a notable exception), and after providing
a high-enough ceiling of strong algorithms, one should be cautious
about raising the floor.

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Insecure DEFAULT cipher set

Dr. Stephen Henson
On Fri, Mar 28, 2014, Viktor Dukhovni wrote:

> On Fri, Mar 28, 2014 at 05:23:45PM +0000, Tim Hollebeek wrote:
>
> > Windows XP is no longer a supported operating system.  If you
> > require compatibility with it, use a non-default cipher suite.  It
> > really is time for RC4-SHA1 to go away.
>
> That's nice, but wishing it, does not make it so.  There are still
> many Windows 2003 servers running IIS and Exchange 2007, that only
> support RC4-SHA1.
>

Some have decided that CBC mode should be disabled or given lower priority
in TLS versions below 1.1 due to certain attacks on CBC mode. That leaves
RC4-SHA1 as all that is left.

I'm not saying I agree with that, just observing that it happens.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Insecure DEFAULT cipher set

Hubert Kario
In reply to this post by Viktor Dukhovni
----- Original Message -----

> From: "Viktor Dukhovni" <[hidden email]>
> To: [hidden email]
> 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                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Insecure DEFAULT cipher set

Viktor Dukhovni
On Fri, Mar 28, 2014 at 02:39:17PM -0400, Hubert Kario wrote:

> > 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've observed and reported (Google for my name and this issue) this
frequently with Exchange 2003 on Windows 2003 servers, which botches
3DES CBC padding.  I've heard rumour of similar problems with IIS,
but have not personally tested this.

I am much more concerned about servers than clients, but it is
likely that TLS client apps on XP (perhaps Outlook Express, ...)
also have similar problems.

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

Applications that do anonymous TLS and then channel-bind with
GSSAPI, or clients that use "HIGH" for mandatory encryption without
authentication...  There is no history of excluding aNULL in HIGH,
and breaking compatibility to change this would be rather bad.

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Insecure DEFAULT cipher set

Hubert Kario
----- Original Message -----

> From: "Viktor Dukhovni" <[hidden email]>
> To: [hidden email]
> Sent: Friday, 28 March, 2014 7:49:33 PM
> Subject: Re: Insecure DEFAULT cipher set
>
> On Fri, Mar 28, 2014 at 02:39:17PM -0400, Hubert Kario wrote:
>
> > > 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've observed and reported (Google for my name and this issue) this
> frequently with Exchange 2003 on Windows 2003 servers, which botches
> 3DES CBC padding.  I've heard rumour of similar problems with IIS,
> but have not personally tested this.
>
> I am much more concerned about servers than clients, but it is
> likely that TLS client apps on XP (perhaps Outlook Express, ...)
> also have similar problems.

From what I found through googling I see that the issue was actually
fixed quite a few years ago.

I don't think we should put known weak ciphers in future version of
openssl's DEFAULT set to work with software configuration that is not
supported by the vendor right now and won't be supported at all in just
over a year.

And since current order already puts 3DES before RC4, people that
need to workaround this issue, already know about it, so even if they
update to future openssl version, they know the solution. The workaround
won't change.

--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Email: [hidden email]
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Insecure DEFAULT cipher set

Viktor Dukhovni
On Fri, Mar 28, 2014 at 03:11:46PM -0400, Hubert Kario wrote:

> > I am much more concerned about servers than clients, but it is
> > likely that TLS client apps on XP (perhaps Outlook Express, ...)
> > also have similar problems.
>
> From what I found through googling I see that the issue was actually
> fixed quite a few years ago.

In theory only.  The fix was very thinly applied, and is no longer
available for download.

> I don't think we should put known weak ciphers in future version of
> openssl's DEFAULT set to work with software configuration that is not
> supported by the vendor right now and won't be supported at all in just
> over a year.

You're still playing "my security level is bigger than yours".
There is no benefit in excluding RC4-SHA1 from the default list.
When servers support stronger algorithms, those will be negotiated.
All you get by exclusing RC4-SHA1 is loss of interoperability, which
may be OK for dedicated environments, but is not a good DEFAULT.

> And since current order already puts 3DES before RC4, people that
> need to workaround this issue, already know about it, so even if they
> update to future openssl version, they know the solution. The workaround
> won't change.

Except that the Microsoft servers in question elect RC4 ahead of
3DES even when the client lists 3DES first.  Disabling RC4 is
typically counter-productive.  You feel better about your security,
but mostly you've just reduced interoperability.

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Insecure DEFAULT cipher set

Hubert Kario
----- Original Message -----

> From: "Viktor Dukhovni" <[hidden email]>
> To: [hidden email]
> Sent: Friday, 28 March, 2014 8:25:50 PM
> Subject: Re: Insecure DEFAULT cipher set
>
> On Fri, Mar 28, 2014 at 03:11:46PM -0400, Hubert Kario wrote:
>
> > > I am much more concerned about servers than clients, but it is
> > > likely that TLS client apps on XP (perhaps Outlook Express, ...)
> > > also have similar problems.
> >
> > From what I found through googling I see that the issue was actually
> > fixed quite a few years ago.
>
> In theory only.  The fix was very thinly applied, and is no longer
> available for download.

I see it available:
http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=948963&kbln=en-us
http://support.microsoft.com/kb/948963
 

> > I don't think we should put known weak ciphers in future version of
> > openssl's DEFAULT set to work with software configuration that is not
> > supported by the vendor right now and won't be supported at all in just
> > over a year.
>
> You're still playing "my security level is bigger than yours".
> There is no benefit in excluding RC4-SHA1 from the default list.
> When servers support stronger algorithms, those will be negotiated.
> All you get by exclusing RC4-SHA1 is loss of interoperability, which
> may be OK for dedicated environments, but is not a good DEFAULT.

Problem is that RC4 is providing comparable security to export grade suites.
It is essentially broken.

Sure, it will prevent opportunistic eavesdropping, but it is not secure.

It is not a "my security level is bigger than yours", it is a difference
between known broken and weak. 3DES is weak, RC4 is broken.

As such, it should be a concious decision by the admin to enable it.

--
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                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Insecure DEFAULT cipher set

Viktor Dukhovni
On Mon, Mar 31, 2014 at 08:49:37AM -0400, Hubert Kario wrote:

> > There is no benefit in excluding RC4-SHA1 from the default list.
> > When servers support stronger algorithms, those will be negotiated.
> > All you get by exclusing RC4-SHA1 is loss of interoperability, which
> > may be OK for dedicated environments, but is not a good DEFAULT.
>
> Problem is that RC4 is providing comparable security to export grade suites.
> It is essentially broken.

The situation is not quite that dire, and the solution is not to
*remove* RC4 from the DEFAULT cipherlist (breaking interoperability),
but for servers to stop explicitly preferring it.  OpenSSL has for a long
time placed RC4 *last* in the medium cipherlist, which is about right.

    https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what

    At the moment, the attack is not yet practical because it
    requires access to millions and possibly billions of copies of
    the same data encrypted using different keys. A browser would
    have to make that many connections to a server to give the
    attacker enough data. A possible exploitation path is to somehow
    instrument the browser to make a large number of connections,
    while a man in the middle is observing and recording the traffic.

The reason it is not last in practice is because some folks explicitly
raise its priority for performance reasons, out of habit, or because
of the various CBC attacks BEAST, CRIME, ...

To phase out RC4, encourage server operators to place it last in
their cipher-list (per the default cipherlist, which clearly many
of them are not using).

I am not arguing for continuing widespread use of RC4, I am arguing
against unnecessary incompatible changes in the DEFAULT cipherlist.

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Insecure DEFAULT cipher set

Hubert Kario
----- Original Message -----

> From: "Viktor Dukhovni" <[hidden email]>
> To: [hidden email]
> Sent: Monday, 31 March, 2014 3:09:12 PM
> Subject: Re: Insecure DEFAULT cipher set
>
> On Mon, Mar 31, 2014 at 08:49:37AM -0400, Hubert Kario wrote:
>
> > > There is no benefit in excluding RC4-SHA1 from the default list.
> > > When servers support stronger algorithms, those will be negotiated.
> > > All you get by exclusing RC4-SHA1 is loss of interoperability, which
> > > may be OK for dedicated environments, but is not a good DEFAULT.
> >
> > Problem is that RC4 is providing comparable security to export grade
> > suites.
> > It is essentially broken.
>
> The situation is not quite that dire, and the solution is not to
> *remove* RC4 from the DEFAULT cipherlist (breaking interoperability),
> but for servers to stop explicitly preferring it.  OpenSSL has for a long
> time placed RC4 *last* in the medium cipherlist, which is about right.
>
>     https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what
>
>     At the moment, the attack is not yet practical because it
>     requires access to millions and possibly billions of copies of
>     the same data encrypted using different keys. A browser would
>     have to make that many connections to a server to give the
>     attacker enough data. A possible exploitation path is to somehow
>     instrument the browser to make a large number of connections,
>     while a man in the middle is observing and recording the traffic.

Note that this is just the effect of most obvious, easiest to perform attack.

Attacks which don't require millions of copies of the same data encrypted
with different keys will undoubtedly be harder to perform. But by how much?

Even an automated system which connects once a minute to a server will generate
over half a million connections after a year. If the password resides
in "unfortunate" bytes with high biases, the attack requires just 30 times
more data to recover parts of the password. Even if that means 2^10 more
computational power, the attack is certainly in the realm of possibility for
any determined adversary.

As such, RC4 should be considered as secure as export grade cipher suites.

> I am not arguing for continuing widespread use of RC4, I am arguing
> against unnecessary incompatible changes in the DEFAULT cipherlist.

And I'm primarily arguing about future releases of openssl (1.0.3 or 1.1.0,
possibly 1.0.2).

For older branches I'd like to see those changes incorporated too, but
as you say, disabling RC4 there might be too risky.

--
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                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

AW: Insecure DEFAULT cipher set

Stefan.Neis@t-online.de
In reply to this post by Viktor Dukhovni
> You're still playing "my security level is bigger than yours".
> There is no benefit in excluding RC4-SHA1 from the default list.
> When servers support stronger algorithms, those will be negotiated.

But that is only true as long as there is no new attack which succesfully
downgrades the cipher suite, i.e. something comparable to
http://www.openssl.org/news/secadv_20101202.txt.

And with all those successful attacks on SSL protocol that
we have seen in the past years its overly optimistic to expect
to never see a "ciphersuite downgrade reloaded", IMHO.
And if that happens you are faced with a choice of either
"raising the floor" (as you called it so graphically)
"immediately" or leaving "everyone" exposed for the possibly
not so short time it takes to develop a fix.

To me, carefully starting to drop "outdated"/"weak"
ciphersuites, so "early adaptors" can test and provide
feedback (both asking the communication partner to
upgrade their software and giving feedback on how
usable the new policy already is)  seems vastly preferable
to having to do the same "all at once" while being under
attack. Of course, if everybody is sure that such an attack
will never happen (again), then there is no point in ever
going to the trouble of "raising the floor".

    Best Regards,
              Stefan


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Insecure DEFAULT cipher set

Viktor Dukhovni
On Mon, Mar 31, 2014 at 07:36:19PM +0200, [hidden email] wrote:

> To me, carefully starting to drop "outdated"/"weak"
> ciphersuites, so "early adopters" can test and provide
> feedback (both asking the communication partner to
> upgrade their software and giving feedback on how
> usable the new policy already is)  seems vastly preferable
> to having to do the same "all at once" while being under
> attack.

Sure, that works for security levels more aggressive than the
interoperable default.  For now, RC4 should probably remain a low
priority cipher in default configurations.  Step 1 is to phase out
server preference for RC4.

I am all for some bleeding-edge clients knowingly field testing
more restrictive configurations.

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Insecure DEFAULT cipher set

Kurt Roeckx
In reply to this post by Viktor Dukhovni
On Mon, Mar 31, 2014 at 01:09:12PM +0000, Viktor Dukhovni wrote:

> On Mon, Mar 31, 2014 at 08:49:37AM -0400, Hubert Kario wrote:
>
> > > There is no benefit in excluding RC4-SHA1 from the default list.
> > > When servers support stronger algorithms, those will be negotiated.
> > > All you get by exclusing RC4-SHA1 is loss of interoperability, which
> > > may be OK for dedicated environments, but is not a good DEFAULT.
> >
> > Problem is that RC4 is providing comparable security to export grade suites.
> > It is essentially broken.
>
> The situation is not quite that dire, and the solution is not to
> *remove* RC4 from the DEFAULT cipherlist (breaking interoperability),
> but for servers to stop explicitly preferring it.  OpenSSL has for a long
> time placed RC4 *last* in the medium cipherlist, which is about right.
>
>     https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what
>
>     At the moment, the attack is not yet practical because it
>     requires access to millions and possibly billions of copies of
>     the same data encrypted using different keys. A browser would
>     have to make that many connections to a server to give the
>     attacker enough data. A possible exploitation path is to somehow
>     instrument the browser to make a large number of connections,
>     while a man in the middle is observing and recording the traffic.
>
> The reason it is not last in practice is because some folks explicitly
> raise its priority for performance reasons, out of habit, or because
> of the various CBC attacks BEAST, CRIME, ...
>
> To phase out RC4, encourage server operators to place it last in
> their cipher-list (per the default cipherlist, which clearly many
> of them are not using).

What we really need are good defaults, and everybody using those
defaults instead of applications developers and administrators
overriding the defaults.

The default of apache is actually using the client preference,
as it was supposed to be doing.  But there are some reasons not to
use the client preference:
- Prefering different ciphers for performance reasons
- Prefering different ciphers because of their strenght
  This would allow you to select RC4 over 3DES if you
  care about IE on XP, or other things.
- Some clients don't have (EC)DHE first in their list,
  and you might want to use that if the client does.
  IE never sends those first, the rest does.

> I am not arguing for continuing widespread use of RC4, I am arguing
> against unnecessary incompatible changes in the DEFAULT cipherlist.

One could argue that having the export ciphers in the DEFAULT
means that you're willing to negiotate that cipher.  But I don't
find that a good idea and would like the connection to fail if
that's the only thing to other side supports.  I clearly don't
want to do a fall back unencrypted either.  So I would really
like to have LOW and EXPORT removed from DEFAULT.

RC4 is becoming close to what I think is unacceptable, but it's
still needed to talk to way too many things that I think it
should at this time still be part of the default.


Kurt

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Insecure DEFAULT cipher set

Dave Thompson-5
In reply to this post by Viktor Dukhovni
> From: [hidden email] On Behalf Of Viktor Dukhovni
> Sent: Monday, March 31, 2014 09:09
> To: [hidden email]
> Subject: Re: Insecure DEFAULT cipher set
>
> On Mon, Mar 31, 2014 at 08:49:37AM -0400, Hubert Kario wrote:

> > Problem is that RC4 is providing comparable security to export grade
suites.
> > It is essentially broken.
>
> The situation is not quite that dire, and the solution is not to
> *remove* RC4 from the DEFAULT cipherlist (breaking interoperability),
> but for servers to stop explicitly preferring it.  OpenSSL has for a long
> time placed RC4 *last* in the medium cipherlist, which is about right.
> <snip: qualys>

> The reason it is not last in practice is because some folks explicitly
> raise its priority for performance reasons, out of habit, or because
> of the various CBC attacks BEAST, CRIME, ...
>
Nitpick: BEAST and Lucky13 are CBC. CRIME and BREACH are
compression and are modestly worse for RC4 (or GCM).



______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]