[ https://issues.apache.org/jira/browse/TS-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593193#comment-14593193 ]
Ivan Ristic commented on TS-3136: --------------------------------- I think the proposed cipher suite selection is pretty good in terms of security, but it can be improved for performance. Here are my suggestions: - Prefer AES128 over AES256. The latter is about 8% slower (for bulk transfers, not handshakes) but no better for security. In fact, some believe that AES128 is stronger. - Prefer SHA non-GCM suites over SHA256 and SHA384. Non-GCM suites that use SHA256 and SHA384 are _much_ slower over those that use SHA. I never measured the difference for SHA384, but SHA256 suites are twice as slow (bulk tranfers, not handshakes) as their SHA counterparts. At the same time, there is no measurable security advantage. Non-GCM suites use hash functions for integrity validation in tandem with HMAC and there are no known practical attacks against them. - Additionally, SHA256 and SHA384 introduce additional transport overhead (per each TLS record), because these hashes are substantially larger. - Side note: despite the same suffix (e.g., SHA256 and SHA384), GCM suites don't use these hash functions in the same way as non-GCM suites. For that reason, they're not slow. In fact, they're the fastest suites currently available. If you're curious, in the names of GCM suites, the SHA256/SHA384 prefix denotes the hashing function used by the protocol's pseudorandom function (PRF). - Please make sure that your DH parameters are at least 2048 bits. I don't know if this isn't the case at the moment, but 1024-bit parameters are very common and yet weak. - If you want to be at the cutting edge of TLS performance, consider adding support for ChaCha20-Poly1305 suites. These are not yet supported by OpenSSL, but they will be soon. LibreSSL supports them natively. CloudFlare maintain an OpenSSL fork that adds support. ChaCha20 suites are strong and provide better performance for mobile users... Chrome has been using them extensively. You should test, but it may be that simply adding the ChaCha20 suites by name to your configuration is enough when ATS is running against a library that supports them. There's a catch when it comes to suite ordering: for desktop users ChaCha20 should be below GCM suites; for mobile users, ChaCha20 should come first. I believe the OpenSSL patch handles this. When you look at CloudFlare's suite configuration https://www.ssllabs.com/ssltest/analyze.html?d=cloudflare.com&s=198.41.214.163 you can see that the ChaCha20 suites are at the end. I believe that OpenSSL detects mobile users somehow and selects a ChaCha20 suite even though they're nominally at the bottom. I haven't tested this myself. [~shinrich] to be absolely sure about any performance degradation, is it possible that you disconnect two servers from the persistent session storage? Leave one server with the original cipher suite configuration and try the new configuration the other. Source: Bulletproof SSL and TLS, chapter 9. (I am the author.) Disclaimer: all benchmarks performed on servers that support AES-NI hardware acceleration. > Change default TLS cipher suites > -------------------------------- > > Key: TS-3136 > URL: https://issues.apache.org/jira/browse/TS-3136 > Project: Traffic Server > Issue Type: Improvement > Components: Security, SSL > Reporter: Leif Hedstrom > Assignee: Susan Hinrichs > Labels: compatibility > Fix For: 6.0.0 > > > In TS-3135 [~i.galic] suggested: > {quote} > also, recommendations for a safer ciphersuite: > SSLCipherSuite > ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4 > > from https://cipherli.st/ > {quote} > [~jacksontj] had responded with: > {quote} > [~i.galic] That cipher quite is geared towards security, but doesn't support > quite a few older clients. I'd recommend we use the suite from mozilla > (https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Server_Configurations) > which is a good mix of security and compatibility: > {code} > 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:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA > {code} > {quote} -- This message was sent by Atlassian JIRA (v6.3.4#6332)