Why does the LE Apache conf cipher suite option have AES128 ciphers ahead of / preferred over AES256 ciphers?
probably for performance reasons
they use the same on this forums too
cipherscan community.letsencrypt.org:443
........................
Target: community.letsencrypt.org:443
prio ciphersuite protocols pfs curves
1 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 ECDH,P-256,256bits prime256v1
2 ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 ECDH,P-256,256bits prime256v1
3 DHE-RSA-AES128-GCM-SHA256 TLSv1.2 DH,2048bits None
4 DHE-RSA-AES256-GCM-SHA384 TLSv1.2 DH,2048bits None
5 ECDHE-RSA-AES128-SHA256 TLSv1.2 ECDH,P-256,256bits prime256v1
6 ECDHE-RSA-AES128-SHA TLSv1,TLSv1.1,TLSv1.2 ECDH,P-256,256bits prime256v1
7 ECDHE-RSA-AES256-SHA384 TLSv1.2 ECDH,P-256,256bits prime256v1
8 ECDHE-RSA-AES256-SHA TLSv1,TLSv1.1,TLSv1.2 ECDH,P-256,256bits prime256v1
9 DHE-RSA-AES128-SHA256 TLSv1.2 DH,2048bits None
10 DHE-RSA-AES128-SHA TLSv1,TLSv1.1,TLSv1.2 DH,2048bits None
11 DHE-RSA-AES256-SHA256 TLSv1.2 DH,2048bits None
12 DHE-RSA-AES256-SHA TLSv1,TLSv1.1,TLSv1.2 DH,2048bits None
13 AES128-GCM-SHA256 TLSv1.2 None None
14 AES256-GCM-SHA384 TLSv1.2 None None
15 AES128-SHA256 TLSv1.2 None None
16 AES256-SHA256 TLSv1.2 None None
17 AES128-SHA TLSv1,TLSv1.1,TLSv1.2 None None
18 AES256-SHA TLSv1,TLSv1.1,TLSv1.2 None None
19 DHE-RSA-CAMELLIA256-SHA TLSv1,TLSv1.1,TLSv1.2 DH,2048bits None
20 CAMELLIA256-SHA TLSv1,TLSv1.1,TLSv1.2 None None
21 DHE-RSA-CAMELLIA128-SHA TLSv1,TLSv1.1,TLSv1.2 DH,2048bits None
22 CAMELLIA128-SHA TLSv1,TLSv1.1,TLSv1.2 None None
23 DES-CBC3-SHA TLSv1,TLSv1.1,TLSv1.2 None None
Certificate: trusted, 2048 bit, sha256WithRSAEncryption signature
TLS ticket lifetime hint: 300
OCSP stapling: not supported
Cipher ordering: server
Fallbacks required:
big-SSLv3 config not supported, connection failed
big-TLSv1.0 no fallback req, connected: TLSv1 ECDHE-RSA-AES128-SHA
big-TLSv1.1 no fallback req, connected: TLSv1.1 ECDHE-RSA-AES128-SHA
big-TLSv1.2 no fallback req, connected: TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256
We haven’t finished deciding what the ciphersuite preferences should be by default in the released client. If you have comments or suggestions, they can be mentioned in the Let’s Encrypt client GitHub issue number #555:
We’re using the “Modern” cipher suite (and the order) recommended here: https://wiki.mozilla.org/Security/Server_Side_TLS As we already have everything set up to achieve an A+ rating at ssllabs.com, it would be great if we’d keep that as we transition to LE.
That recommendation appears to favor AES128 over AES256. Probably favoring performance over cipher strength.
Favoring the AES256 ciphers instead should not reduce your SSL Labs rating.
Also I believe you could put your cipher string into the LE options-ssl-*.conf file so it would be your LE default.
The preferred order of that recommendation:
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-GCM-SHA384
DHE-RSA-AES128-GCM-SHA256
DHE-DSS-AES128-GCM-SHA256
kEDH+AESGCM
ECDHE-RSA-AES128-SHA256
ECDHE-ECDSA-AES128-SHA256
ECDHE-RSA-AES128-SHA
ECDHE-ECDSA-AES128-SHA
ECDHE-RSA-AES256-SHA384
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES256-SHA
ECDHE-ECDSA-AES256-SHA
DHE-RSA-AES128-SHA256
DHE-RSA-AES128-SHA
DHE-DSS-AES128-SHA256
DHE-RSA-AES256-SHA256
DHE-DSS-AES256-SHA
DHE-RSA-AES256-SHA
!aNULL
!eNULL
!EXPORT
!DES
!RC4
!3DES
!MD5
!PSK
Hey @NOYB – if LE’s default configuration would keep up with SSL Labs’ A+ requirements, that would certainly be a major asset as Let’s Encrypt becomes a trusted, worldwide authority in web security.
Agree. Though I don’t think SSL Labs A+ grade necessarily requires the strongest ciphers be preferred. From what I’ve seen A+ grade can be achieved using AES128 ciphers even when there are AES256 ciphers available to negotiate instead.
It seems that some of the more major criteria for getting a high grade are things like forward secrecy, TLSv1.2, cert chain, . . . Not saying that is a problem. Just my observation that cipher strength doesn’t seem to carry as much weight in the grade.
Sure thing. It was when we added
Header always set Strict-Transport-Security “max-age=63072000; includeSubdomains; preload”
that our rating went from A to A+. Would be great if this also were included in LE’s default configuration.
If not, it appears you should be able to add it to at least make it your LE default.
It indeed does – Chrome says:
"Your connection to www.fashion.net is encrypted using a modern cipher suite.
The connection uses TLS 1.2.
The connection is encrypted and authenticated using AES_128_GCM and uses ECDHE_RSA as the key exchange mechanism."
99% of the time SSL Labs A vs A+ is the difference between enabling HSTS headers or not. The cipher strength of 128 vs 256 has has no bearing on whether you get A+ or not if you have the right ciphers in place
This is my Centmin Mod Nginx HTTP/2 (compiled against LibreSSL 2.2 for chacha20 cipher support) enabled Letsencrypt SSL certificate site’s ssl cipher preferences. SSL Labs gives it a T for untrusted but if trusted would be an A. I don’t have HSTS enabled as i test on both http and https sides so leave HSTS off. If HSTS is enabled = A+
SSL Labs score https://community.centminmod.com/posts/17795/
cipherscan le1.http2ssl.xyz:443
.....................
Target: le1.http2ssl.xyz:443
prio ciphersuite protocols pfs curves
1 ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 ECDH,P-256,256bits prime256v1
2 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 ECDH,P-256,256bits prime256v1
3 ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 ECDH,P-256,256bits prime256v1
4 DHE-RSA-AES128-GCM-SHA256 TLSv1.2 DH,2048bits None
5 DHE-RSA-AES256-GCM-SHA384 TLSv1.2 DH,2048bits None
6 ECDHE-RSA-AES128-SHA256 TLSv1.2 ECDH,P-256,256bits prime256v1
7 ECDHE-RSA-AES128-SHA TLSv1,TLSv1.1,TLSv1.2 ECDH,P-256,256bits prime256v1
8 ECDHE-RSA-AES256-SHA384 TLSv1.2 ECDH,P-256,256bits prime256v1
9 ECDHE-RSA-AES256-SHA TLSv1,TLSv1.1,TLSv1.2 ECDH,P-256,256bits prime256v1
10 DHE-RSA-AES128-SHA256 TLSv1.2 DH,2048bits None
11 DHE-RSA-AES128-SHA TLSv1,TLSv1.1,TLSv1.2 DH,2048bits None
12 DHE-RSA-AES256-SHA256 TLSv1.2 DH,2048bits None
13 DHE-RSA-AES256-SHA TLSv1,TLSv1.1,TLSv1.2 DH,2048bits None
14 AES128-GCM-SHA256 TLSv1.2 None None
15 AES256-GCM-SHA384 TLSv1.2 None None
16 AES128-SHA256 TLSv1.2 None None
17 AES256-SHA256 TLSv1.2 None None
18 AES128-SHA TLSv1,TLSv1.1,TLSv1.2 None None
19 AES256-SHA TLSv1,TLSv1.1,TLSv1.2 None None
20 DES-CBC3-SHA TLSv1,TLSv1.1,TLSv1.2 None None
Certificate: UNTRUSTED, 2048 bit, sha256WithRSAEncryption signature
TLS ticket lifetime hint: 3600
OCSP stapling: not supported
Cipher ordering: server
Fallbacks required:
big-SSLv3 config not supported, connection failed
big-TLSv1.0 no fallback req, connected: TLSv1 ECDHE-RSA-AES128-SHA
big-TLSv1.1 no fallback req, connected: TLSv1.1 ECDHE-RSA-AES128-SHA
big-TLSv1.2 no fallback req, connected: TLSv1.2 ECDHE-RSA-CHACHA20-POLY1305
I appreciate all of the comments. Does anyone have references to expert guidance or opinion talking about the choice between AES-256 and AES-128? (Again, this might be better posted to the GitHub issue, which is trying to collect everything about the ciphersuites topic in one place.)
Hey @schoen! As posted on GitHub, there is indeed some interesting information on AES128 vs AES256: https://wiki.mozilla.org/Security/Server_Side_TLS#Prioritization_logic (“AES 128 is preferred to AES 256. There has been discussions on whether AES256 extra security was worth the cost, and the result is far from obvious. At the moment, AES128 is preferred, because it provides good security, is really fast, and seems to be more resistant to timing attacks.”)
Also see this by @jvehent [on the GitHub issue] (Review all cryptographic algorithm and parameter defaults · Issue #555 · certbot/certbot · GitHub):
While the performance difference is probably not the highest concern,
there has been some research that suggest that attacks on AES256 are
easier to achieve than on the 128 variant. The reasoning is that most
attack on AES do not directly target the rounds or the key length, but
focus more on side channels like timing attacks. If AES 128 is more
resistant to those than 256, then 128 should be preferred. This thread
has more information: Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
I'm happy to explain more about the reasoning behind each level if
you'd like. We spend a lot of time making sure the levels are current
and support the security and compatibility needs of old, intermediate
and modern web applications.
That’s right, HSTS with a max-age
greater than half a year toggles the grade from A to A+.
These are my ciphers and they work splendidly -
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc13)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)
8 ciphers, covers every browser in ssllabs test that supports NSI.
The first one isn’t available in current OpenSSL.
The last one is only needed because otherwise Tumblr can’t scrape the page, oh and I believe crusty versions of OpenSSL and libcurl can’t do ECDHE.
As far as AES256 vs AES128 - I know the argument but I’m not convinced it is worth giving 128 priority. Might be better in timing attacks but 256 is better is the NSA is logging the session to try and crack later, no?
My opinion is that at this point in time, only ciphers with forward secrecy should be used, and really only ECDHE unless you need Tumblr support - but to be honest, I have been moving my certs to ECDSA anyway and there are no DHE suites for those certs (at least with LibreSSL)
ChaCha20 should be first for mobile performance. Desktop users with chips that can have acceleration for AES-GCM should not report ChaCha20 as a supported cipher.
FYI there was another discussion about cipher suites and it's order (especially AES 256bit vs AES 128 bit) here too:
FYI LE has explained in detail why they use the ciphers they use in the doc:
https://letsencrypt.readthedocs.org/en/latest/ciphers.html