1178092 - Cannot establish connection to a site that supports only TLS 1.2 and 256-bit forward secrecy cipher suites

Status: RESOLVED FIXED

(Core :: Security: PSM, defect)

Description

[Michał Staruch]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20150525141253

Steps to reproduce:

I've tried to open https://thundr.eu/ site, 4x100 in Qualys SSL Server test:
https://www.ssllabs.com/ssltest/analyze.html?d=thundr.eu&hideResults=on


Actual results:

I've got ssl_error_no_cypher_overlap error.


Expected results:

Connection should be established.

BlackBerry 10 built-in browser works fine, text-mode browser Links (v2.8) works fine.

OpenSSL works fine for both ECDHE:
openssl s_client -connect thundr.eu:443 -cipher kEECDH
and DHE, too:
openssl s_client -connect thundr.eu:443 -cipher kEDH

Comment 1

[Michał Staruch]

Attachment: Screenshot from Windows 8.1 with IE11

Comment 2

[Michał Staruch]

Attachment: Screenshot from Debian 8.1 with Links 2.8

Comment 3

[Michał Staruch]

Attachment: Screenshot from OS X 10.10 with Safari 8

Comment 4

[:Gijs (he/him)]

That Qualys report actually predicts this problem, indicating that because these are the only supported cipher suites:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)   ECDH 521 bits (eq. 15360 bits RSA)
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f)   DH 4096 bits (p: 512, g: 1, Ys: 512)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   ECDH 521 bits (eq. 15360 bits RSA)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b)   DH 4096 bits (p: 512, g: 1, Ys: 512)


connecting with Firefox won't work.

I don't know why they still score the site 100; they probably shouldn't.

I don't know enough about these ciphers to know why we don't support them. Maybe dkeeler can help?

Comment 5

[:Gijs (he/him)]

(FWIW, qualys also indicates it won't work with Chrome, and indeed it does not. Likewise, it won't work with IE < IE11, the net effect of which is that it won't be reachable at all for anyone running Windows Vista or earlier (or pre-11 IE), for instance.)

Comment 6

[Michał Staruch]

Gijs:
1. To get 100 in Cipher Strength server needs to support only 256-bit ciphers.
2. To get 100 in Protocol Support server needs to support only TLSv1.2-compatible cipher suites.
3. To have session keys protected from long-term keys compromise only Forward Secrecy cipher suites are enabled.
4. To have "foreseeable future" level of protection strong parameters for ECDHE and DHE are selected, see the ECRYPT II recommendations here: http://www.keylength.com/en/3/.

Please list all the cipher suites supported in Firefox meeting requirements listed above.

Comment 7

[Dana Keeler (she/her) (use needinfo) [:keeler]]

(In reply to :Gijs Kruitbosch from comment #4)
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)   ECDH 521 bits (eq. 15360
> bits RSA)
> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f)   DH 4096 bits (p: 512, g: 1, Ys:
> 512)
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   ECDH 521 bits (eq. 15360
> bits RSA)

It looks like NSS doesn't support these yet, so Firefox can't use them.

> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b)   DH 4096 bits (p: 512, g: 1, Ys:
> 512)

NSS does support this, but Firefox has never enabled it, as far as I can tell. Unless we get many reports of incompatibility, it's unlikely it will get enabled.

(In reply to lcf from comment #6)
> Gijs:
> 1. To get 100 in Cipher Strength server needs to support only 256-bit
> ciphers.

That seems wrong to me. My understanding is the AES-128 ciphers are comparable to AES-256 in terms of the actual security they provide.

> 2. To get 100 in Protocol Support server needs to support only
> TLSv1.2-compatible cipher suites.
> 3. To have session keys protected from long-term keys compromise only
> Forward Secrecy cipher suites are enabled.
> 4. To have "foreseeable future" level of protection strong parameters for
> ECDHE and DHE are selected, see the ECRYPT II recommendations here:
> http://www.keylength.com/en/3/.
> 
> Please list all the cipher suites supported in Firefox meeting requirements
> listed above.

Unless I'm misunderstanding the requirements, the following should work:

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA

Comment 8

[Michał Staruch]

David:
1. SHA-1 is breakable and deprecated, it shouldn't be used for crypto anymore. Not a big problem in case of HMAC, but still, it should be replaced with SHA-256 or SHA-384.
2. If fixing this problem requires some changes in NSS, then I guess you could just links those to "depends on" list.
3. Difference between 256-bit and 128-bit crypto (both implemented without flaws) is that I cannot imagine any attack breaking 256-bit security, and breaking 128-bit is physically possible (very expensive, but still). Implementation flaws happen, though, so we should also assume some degradation of security level is possible. And I'd prefer degraded 256-bit much more than degraded 128-bit.

Comment 9

[Masatoshi Kimura [:emk]]

(In reply to Michał Staruch from comment #8)
> 3. Difference between 256-bit and 128-bit crypto (both implemented without
> flaws) is that I cannot imagine any attack breaking 256-bit security, and
> breaking 128-bit is physically possible (very expensive, but still).
> Implementation flaws happen, though, so we should also assume some
> degradation of security level is possible. And I'd prefer degraded 256-bit
> much more than degraded 128-bit.

AES-256 is known to be more vulnerable to related-key attack than AES-128.
https://cryptolux.org/images/4/42/Aes-boom-revised.pdf

Comment 10

[Michał Staruch]

(In reply to Masatoshi Kimura [:emk] from comment #9)
> AES-256 is known to be more vulnerable to related-key attack than AES-128.
> https://cryptolux.org/images/4/42/Aes-boom-revised.pdf

Related-key attack against AES-256 has data complexity 2^99, so it doesn't really applies against short-living TLS session keys.

Of course it would be better to move to 256-bit grade AEAD ciphers (TLS 1.3 compatible) without any known weakness, like ChaCha20-Poly1305 or Camellia-256-GCM - but adoption of those in crypto libraries is still pretty low.

Comment 11

[Masatoshi Kimura [:emk]]

(In reply to Michał Staruch from comment #6)
> 1. To get 100 in Cipher Strength server needs to support only 256-bit
> ciphers.
> 2. To get 100 in Protocol Support server needs to support only
> TLSv1.2-compatible cipher suites.

SSL Labs should really remove the misleading scores...
https://community.qualys.com/thread/16011

Comment 12

[Masatoshi Kimura [:emk]]

Firefox has added a support for ChaCha20-Poly1305 that is a 256-bit cipher.
The particular server does not still connect, but the reason is no loner what the bug summary describes.

Comment 13

[Michał Staruch]

Attachment: Page Info on Firefox 49.0a2 (2016-06-22)

Nice to see it's fixed in current version of Firefox Developer Edition :). I've just tested 49.0a2 (2016-06-22) and connection was established using ECDHE-RSA-AES256-GCM-SHA384 cipher suite, NIST P-521 curve and TLSv1.2 protocol.

Support for ChaCha20-Poly1305 is most welcomed, too - but at the moment of writing using it on the server side can be a bit troublesome for those who want to (or have to) use stable software channels (OpenSSL 1.1.0 not yet released, and not included in distros).