Where are others "SHA256 " cipher suits in Firefox 27?

Rasj

unread,

Feb 6, 2014, 12:54:55 AM2/6/14

to

Hi,
I see only:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)

Where are others? For example:
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d)

Many web-sites have only TLS_RSA_WITH_AES_256_CBC_SHA256 as kind of strong(even without PFS) and weak RC4 and 3DES. If I have not TLS_RSA_WITH_AES_256_CBC_SHA256 server will choose RC4 or 3DES!

Why Mozilla doesn't add others "SHA256" cipher suits? What is the problem to add them, is it so hard? :)

Brian Smith

unread,

Feb 6, 2014, 3:50:16 AM2/6/14

to mozilla's crypto code discussion list

On Wed, Feb 5, 2014 at 9:54 PM, Rasj <ras...@gmail.com> wrote:
> Where are others? For example:
> TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d)

See https://briansmith.org/browser-ciphersuites-01.html. Also, please
look at the archives of this mailing list. There have been several
DOZEN of emails about the cipher suite selection on this mailing list.

in particular: "This proposal does not include the new HMAC-SHA256 or
HMAC-SHA384 ciphersuites that were added in TLS 1.2 since there is not
a clear need for them. Given our current understanding, HMAC-SHA-1,
HMAC-SHA-256, and HMAC-SHA-384 are all more-or-less equal in terms of
security given how they are used in TLS. (This is HMAC-SHA, not plain
SHA. Also, there is a huge difference in the ability to resist an
offline attack vs. the ability to resist an online attack.) Avoiding
these ciphersuites also allows us to sidestep the possibility of
performance regressions from enabling TLS 1.2."

> Many web-sites have only TLS_RSA_WITH_AES_256_CBC_SHA256 as kind of strong(even without PFS) and weak RC4 and 3DES.

Please provide some examples of such sites.

Some of the information in my proposal is outdated. For example, it
seems like we don't have constraints on handshake size, since we've
discovered workarounds for those compatibility issues. So, we have
more flexibility to add these cipher suites than we previously did.

My main thought here is that these cipher suites aren't really
increasing security, but they are decreasing performance, when they
are used. We should advocate instead for cipher suites that increase
security and increase performance. That means, for example, cipher
suites that waste fewer bytes per record on nonces and padding. See
https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04 for an
example of what I mean.

More generally, the CBC-HMAC mode of cipher suites is outdated and
should just be replaced. We have to support the older variants for
backward compatibility, but I don't see much reason, right now, to add
support for the new, less efficient, no-more-secure, variants.

Cheers,
Brian
--
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

Rasj

unread,

Feb 6, 2014, 7:55:06 AM2/6/14

to

On Thursday, February 6, 2014 12:50:16 PM UTC+4, Brian Smith wrote:
> > Many web-sites have only TLS_RSA_WITH_AES_256_CBC_SHA256 as kind of strong(even without PFS) and weak RC4 and 3DES.
> Please provide some examples of such sites.

Some Banks.

You can include it by default but turn it off if you worry about performance. So standard users get what you want and some users as I can turn it on in about:config.

gegard432...@yahoo.co.uk

unread,

Feb 6, 2014, 4:57:34 PM2/6/14

to dev-tec...@lists.mozilla.org

Regarding the other variants of AES-GCM
-TLS_RSA_WITH_AES_128_GCM_SHA256
There are some sites support AES-GCM that use only ciphers with RSA key
exchange. I think it would be best not to support new standards that
don't provide Forward Secrecy, but on the other hand, if this cipher is
enabled then users browsing to those sites will at least have something better than RSA with AES-CBC. If I'm correct, AES-GCM is not vulnerable to some of the newer TLS attacks, in particular Lucky13. Even when used together with TLS 1.2, AES-CBC is
vulnerable to Lucky13.
-TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
I'm
aware that a lot of sites only use 1024 bit DH, but with the patent
issues regarding ECC, there are still enough sites who don't support
ECDHE. If this cipher is enabled, users can benefit both from protection
against Lucky13 and Forward Secrecy. Also there are enough sites out
there that do have 2048 or even 4096 bit DH key exchange.
For sites
that have both ECDHE and DHE ciphers enabled, ECDHE variants are usually
the preferred anyway and if the server has no preference, they are also
preferred by NSS. I also think that diversity should be maintained in
case a vulnerability in some standard or protocol is discovered. Just
like supporting ChaCha20_Poly1305 and AES with other modes like CCM to avoid the same
disaster as with the BEAST attack, where AES-CBC was the only really
secure protocol, found vulnerable and then having tons of sites switch
back to the insecure RC4. Just in case ECC is being discovered
vulnerable, there should be an alternative key exchange method that does not use EC cryptography. The only widely used are RSA and DHE, and DHE
supports Forward Secrecy and is the better alternative IMO.
Bruce Schneier believes ECC is relatively easier to break for the NSA. Whether or not you find his advice important, the fact is that ECC is
relatively new and there should at least be one older and proven method as well.

As
discussed before, ECC cryptography has better performance, but if
webmasters prefer performance then they put DHE ciphers lower in the
order or disable them completely. IMO, the weighing whether to prefer
performance or security is the choice of siteowners and webmasters. By
supporting only variants you or someone else prefers, you're limiting
their choice.

Kurt Roeckx

unread,

Feb 6, 2014, 6:13:29 PM2/6/14

to mozilla's crypto code discussion list

On Thu, Feb 06, 2014 at 09:57:34PM +0000, gegard432...@yahoo.co.uk wrote:
> Regarding the other variants of AES-GCM
> -TLS_RSA_WITH_AES_128_GCM_SHA256
> There are some sites support AES-GCM that use only ciphers with RSA key
> exchange. I think it would be best not to support new standards that
> don't provide Forward Secrecy, but on the other hand, if this cipher is
> enabled then users browsing to those sites will at least have something better than RSA with AES-CBC. If I'm correct, AES-GCM is not vulnerable to some of the newer TLS attacks, in particular Lucky13. Even when used together with TLS 1.2, AES-CBC is
> vulnerable to Lucky13.

Lucky13 is a timing attack on MAC-then-Encrypt, which CBC uses.
This attack can be fixed, but it's harder to get this right than
it should be.

Maybe you're refering to the BEAST attack instead of Lucky 13,
which TLS 1.1 fixed and can be worked around in older versions
by splitting?

Anyway, I see no need for adding support for ciphers that do not
support forward secrecy.

> -TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
> I'm
> aware that a lot of sites only use 1024 bit DH, but with the patent
> issues regarding ECC, there are still enough sites who don't support
> ECDHE. If this cipher is enabled, users can benefit both from protection
> against Lucky13 and Forward Secrecy. Also there are enough sites out
> there that do have 2048 or even 4096 bit DH key exchange.

Please name a few of those sites that have > 1024 DH keys.

> For sites
> that have both ECDHE and DHE ciphers enabled, ECDHE variants are usually
> the preferred anyway and if the server has no preference, they are also
> preferred by NSS. I also think that diversity should be maintained in
> case a vulnerability in some standard or protocol is discovered. Just
> like supporting ChaCha20_Poly1305 and AES with other modes like CCM to avoid the same
> disaster as with the BEAST attack, where AES-CBC was the only really
> secure protocol, found vulnerable and then having tons of sites switch
> back to the insecure RC4. Just in case ECC is being discovered
> vulnerable, there should be an alternative key exchange method that does not use EC cryptography. The only widely used are RSA and DHE, and DHE
> supports Forward Secrecy and is the better alternative IMO.

Some of the curves using by ECDHE might have some problems which
is why people are working on getting alternatives like curve25519
standardized. But DHE is so slow that people want to avoid it,
and there are both clients and servers have problems with sizes
of 2048 or more which really is what you want.

But I can understand that some people might prefer DHE instead of
ECDHE. And I've actually requested that this cipher would be
enabled too.

> Bruce Schneier believes ECC is relatively easier to break for the NSA. Whether or not you find his advice important, the fact is that ECC is
> relatively new and there should at least be one older and proven method as well.

I understand that RSA is expected to get broken in the next 10 years
and we need alternatives. ECDSA is currently the only other
standardised method for using in TLS that we should consider using
as far as I know. I would also like to point out that EC isn't
exactly new, it's just seeing more wide deployment now.

So I'm actually concerned that in the long run all of RSA, DHE and
ECC will be broken and that we don't really have alternatives.
But we have to go with what we currently know.

Kurt

Matthijs Janssen

unread,

Feb 6, 2014, 2:00:20 PM2/6/14

to dev-tec...@lists.mozilla.org

Regarding the other variants of AES-GCM
-TLS_RSA_WITH_AES_128_GCM_SHA256
There are some sites support AES-GCM that use only ciphers with RSA key exchange. I think it would be best not to support new standards that don't provide Forward Secrecy, but on the other hand, if this cipher is enabled then users browsing to those sites will at least have something better than RSA with AES-CBC. If I'm correct, AES-GCM is not vulnerable to some of the newer TLS attacks, in particular Lucky13. Even when used together with TLS 1.2, AES-CBC is vulnerable to Lucky13.

-TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
I'm aware that a lot of sites only use 1024 bit DH, but with the patent issues regarding ECC, there are still enough sites who don't support ECDHE. If this cipher is enabled, users can benefit both from protection against Lucky13 and Forward Secrecy. Also there are enough sites out there that do have 2048 or even 4096 bit DH key exchange.

For sites that have both ECDHE and DHE ciphers enabled, ECDHE variants are usually the preferred anyway and if the server has no preference, they are also preferred by NSS. I also think that diversity should be maintained in case a vulnerability in some standard or protocol is discovered. Just like supporting ChaCha20_Poly1305 and AES with other modes like CCM to avoid the same disaster as with the BEAST attack, where AES-CBC was the only really secure protocol, found vulnerable and then having tons of sites switch back to the insecure RC4. Just in case ECC is being discovered vulnerable, there should be an alternative key exchange method that does not use EC cryptography. The only widely used are RSA and DHE, and DHE supports Forward Secrecy and is the better alternative IMO.

Bruce Schneier believes ECC is relatively easier to break for the NSA. Whether or not you find his advice important, the fact is that ECC is relatively new and there should at least be one older and proven method as well.

As discussed before, ECC cryptography has better performance, but if webmasters prefer performance then they put DHE ciphers lower in the order or disable them completely. IMO, the weighing whether to prefer performance or security is the choice of siteowners and webmasters. By supporting only variants you or someone else prefers, you're limiting their choice.

gegard4321

unread,

Feb 9, 2014, 1:40:48 PM2/9/14

to dev-tec...@lists.mozilla.org

>Lucky13 is a timing attack on MAC-then-Encrypt, which CBC uses.
>This attack can be fixed, but it's harder to get this right than
>it should be.
>Maybe you're refering to the BEAST attack instead of Lucky 13,
>which TLS 1.1 fixed and can be worked around in older versions
>by splitting?
>Anyway, I see no need for adding support for ciphers that do not
>support forward secrecy.

Yes, because CBC is vulnerable to Lucky13, using GCM will not be vulnerable,
thus GCM support is important.
So if some sites support GCM but not Forward Secrecy, making
TLS_RSA_WITH_AES_128_GCM_SHA256 available in Firefox, they will at least be
safe from Lucky13.
But on the other hand I agree with you that supporting new ciphers without
Forward Secrecy is undesirable.

>Please name a few of those sites that have > 1024 DH keys.

I went looking for some more, but the apparently the only sites that have >
1024 DH keys are a few small sites usually concerning privacy and/or
security.

>But I can understand that some people might prefer DHE instead of
>ECDHE. And I've actually requested that this cipher would be
>enabled too.

>I understand that RSA is expected to get broken in the next 10 years
>and we need alternatives. ECDSA is currently the only other
>standardised method for using in TLS that we should consider using
>as far as I know. I would also like to point out that EC isn't
>exactly new, it's just seeing more wide deployment now.

>So I'm actually concerned that in the long run all of RSA, DHE and
>ECC will be broken and that we don't really have alternatives.
>But we have to go with what we currently know.

Hopefully alternatives will emerge in the near future.

--
View this message in context: http://mozilla.6506.n7.nabble.com/Where-are-others-SHA256-cipher-suits-in-Firefox-27-tp306678p306864.html
Sent from the Mozilla - Cryptography mailing list archive at Nabble.com.

gegard4321

unread,

Mar 23, 2014, 11:43:35 AM3/23/14

to dev-tec...@lists.mozilla.org

Another reason to enable DHE_RSA_AES_*_GCM: Mozilla's new account system only
supports RSA and DHE_RSA ciphers:
https://www.ssllabs.com/ssltest/analyze.html?d=accounts.firefox.com
Same goes for mozilla.org and bugzilla.

--
View this message in context: http://mozilla.6506.n7.nabble.com/Where-are-others-SHA256-cipher-suits-in-Firefox-27-tp306678p311535.html

Julien Vehent

unread,

Mar 23, 2014, 12:17:25 PM3/23/14

to dev-tec...@lists.mozilla.org

On 2014-03-23 11:43, gegard4321 wrote:
> Another reason to enable DHE_RSA_AES_*_GCM: Mozilla's new account
> system only
> supports RSA and DHE_RSA ciphers:
> https://www.ssllabs.com/ssltest/analyze.html?d=accounts.firefox.com
> Same goes for mozilla.org and bugzilla.

On the server side, we are working to support better TLS. See this
Tracker bug: https://bugzilla.mozilla.org/show_bug.cgi?id=901393

Depending on the technology used, not all ciphers are available on all
sites. But I can already tell you that accounts.firefox.com will support
ECDHE and AES-GCM.

- Julien

Kurt Roeckx

unread,

Mar 23, 2014, 12:18:24 PM3/23/14

to mozilla's crypto code discussion list

On Sun, Mar 23, 2014 at 08:43:35AM -0700, gegard4321 wrote:
> Another reason to enable DHE_RSA_AES_*_GCM: Mozilla's new account system only
> supports RSA and DHE_RSA ciphers:
> https://www.ssllabs.com/ssltest/analyze.html?d=accounts.firefox.com
> Same goes for mozilla.org and bugzilla.

Firefox selects TLS_DHE_RSA_WITH_AES_128_CBC_SHA, while chrome
selects TLS_DHE_RSA_WITH_AES_128_GCM_SHA256. And I would really
prefer the GCM version over the CBC version.

Please add support for TLS_DHE_RSA_WITH_AES_*_GCM_SHA*, which
currently probably means TLS_DHE_RSA_WITH_AES_128_GCM_SHA256.

Kurt

gegard4321

unread,

Mar 23, 2014, 2:49:24 PM3/23/14

to dev-tec...@lists.mozilla.org

>On the server side, we are working to support better TLS.

Thanks for the information.
Please also have a look at AMO, it doesn't even support TLS 1.2 and Forward
Secrecy:
https://www.ssllabs.com/ssltest/analyze.html?d=addons.mozilla.org

--
View this message in context: http://mozilla.6506.n7.nabble.com/Where-are-others-SHA256-cipher-suits-in-Firefox-27-tp306678p311571.html