[
https://issues.apache.org/jira/browse/TS-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14592485#comment-14592485
]
Susan Hinrichs commented on TS-3136:
------------------------------------
Ran some tests on a production box in Y! Based on those results, I suggest the
following cipher string.
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA: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
The upshot is that we remove RC4, add new ciphers, and rearrange the list to
give preference to cipher attributes in the following order: PFS, then GCM,
then stronger SHA, then stronger AES. 3DES is at the end to scoop up the
remainders.
We tested in the Y! environment which tends to have a wide variety of clients.
Removing RC4 did not seem to significantly impact handshake success rate. CBC
algorithms are also concerning, but if we care about out-of-the-box experience
it looks like the CBC algorithms need to stick around for a while longer.
Here are details of the test
With Y! original cipher string
0.0102% ssl_error_ssl
The number of DES-CBC3-SHA sessions was negligible (45). The Y! initial
configuration has one RC4 algorithm listed kind of early, so the RC4 percentage
was around 30% as [~davet] noted in an earlier comment.
With proposed default cipher string running for an hour
0.009% ssl_error_ssl
The percentage of DES-CBC3-SHA sessions grew to 0.9% of sessions. In my
experiment, it was impossible to isolate the CPU impact of this change. To
test a new cipher without updating all the machines in the production pod, I
remove the test box from the SSL session sharing communication. The test box
experienced around a 30% increase in CPU utilization, but I think that can be
mostly attributed to increased session negotiation since it did not know about
the sessions negotiated by other machines in the pod.
We did one experiment with the RC4 ciphers added after DES-CBC3 as another
measure of how many clients are only willing to do RC4. After about an hour, 2
RC4 sessions were started.
510932 = Total Successful Handshakes
Percentage of various cipher's negotiated
# Start with PFS/GCM ciphers. Give slight preference to AES256 over AES128,
and prefer stronger SHA
0% ECDHE-ECDSA-AES256-GCM-SHA384:
4.2% ECDHE-RSA-AES256-GCM-SHA384:
0% ECDHE-ECDSA-AES128-GCM-SHA256:
30.6% ECDHE-RSA-AES128-GCM-SHA256:
# DHE still gives of PFS but at increased computation cost
0% DHE-RSA-AES256-GCM-SHA384:
0% DHE-DSS-AES256-GCM-SHA384:
0% DHE-RSA-AES128-GCM-SHA256:
0% DHE-DSS-AES128-GCM-SHA256:
# CBC versions of the PFS ciphers
0% ECDHE-ECDSA-AES256-SHA384:
30.6% ECDHE-RSA-AES256-SHA384:
0% ECDHE-ECDSA-AES256-SHA:
27.7% ECDHE-RSA-AES256-SHA:
0% ECDHE-ECDSA-AES128-SHA256:
0% ECDHE-RSA-AES128-SHA256:
0% ECDHE-ECDSA-AES128-SHA:
0.14% ECDHE-RSA-AES128-SHA:
0% DHE-RSA-AES256-SHA256:
0% DHE-DSS-AES256-SHA256:
0% DHE-RSA-AES128-SHA256:
0% DHE-DSS-AES128-SHA256:
0% DHE-RSA-AES256-SHA:
0% DHE-DSS-AES256-SHA:
0% DHE-RSA-AES128-SHA:
0% DHE-DSS-AES128-SHA:
# No PFS, GCM
0.3% AES256-GCM-SHA384:
0% AES128-GCM-SHA256:
# No PFS, CBC
0.2% AES256-SHA256:
0% AES128-SHA256:
4.8% AES256-SHA:
0.5% AES128-SHA:
# 3DES as a last resort
0.9% DES-CBC3-SHA
> 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)
