- From: Jason Greene <jason.greene@redhat.com>
- Date: Thu, 6 Nov 2014 12:37:04 -0600
- To: Michael Sweet <msweet@apple.com>
- Cc: Mark Nottingham <mnot@mnot.net>, Greg Wilkins <gregw@intalio.com>, Patrick McManus <mcmanus@ducksong.com>, Mike Bishop <Michael.Bishop@microsoft.com>, HTTP Working Group <ietf-http-wg@w3.org>
> On Nov 6, 2014, at 5:11 AM, Michael Sweet <msweet@apple.com> wrote:
>
> There are two problems with it:
>
> 1. Many (GNU TLS, OpenSSL, MS SPI, and Apple SecureTransport for sure) have no API to control the order of cipher suites
I thought the priority strings would be sufficient, but testing at least GNUTLS, shows the order provision in my proposal, as written being unenforceable on this implementation. Unsurprisingly, the default order is all wrong[1].
You can get it close, but not completely accurate because it appears to sort key exchange over mac. As an example a priority string like:
'NONE:+AEAD:+AES-256-GCM:+AES-128-GCM:+SHA256:+AES-256-CBC:+AES-128-CBC:+VERS-TLS1.2:+ECDHE-RSA:+ECDHE-ECDSA:+RSA:+CURVE-ALL:+COMP-NULL’
It will lead to non-AEAD ciphers with higher priority than AEAD ciphers. However, since the spec requires TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, everything would work, so the proposal language could just be softened, but I can’t help but think this is just asking for trouble.
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
Glancing at OpenSSL it has the same problem
>
> 2. It still forbids the use of non-conforming ciphers which can only be enforced after a successful TLS negotiation if an endpoint wants to support both HTTP/1 and HTTP/2.
Yes, but this restriction only rejects non-compliant clients, that did not prioritize GCM over a prohibited cipher.
[1] GNU-TLS default order (NORMAL priority string)
Cipher Suites (40 suites)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)
Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041)
Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
Received on Thursday, 6 November 2014 18:37:47 UTC