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: [email protected] [mailto:[email protected]] On Behalf Of Viktor Dukhovni Sent: Friday, March 28, 2014 12:49 PM To: [email protected] 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 [email protected] Automated List Manager [email protected] ________________________________ 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 [email protected] Automated List Manager [email protected]
