[
https://issues.apache.org/jira/browse/TS-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593193#comment-14593193
]
Ivan Ristic edited comment on TS-3136 at 6/19/15 8:42 AM:
----------------------------------------------------------
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
(increasing the size of 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 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.
was (Author: ivanr):
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)
