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: hka...@redhat.com
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 openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
