[
https://issues.apache.org/jira/browse/TS-3699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15235191#comment-15235191
]
Dave Thompson commented on TS-3699:
-----------------------------------
Key rescheduling recommendations are still being discussed in IETF working
group CFRG and TLS, this particular cipher in particular. The limits listed
in original description are under debate. No news as of IETF95 (April 2016).
After key rescheduling recommendations are worked out, it's possible this issue
is fixed entirely at the OpenSSL layer with no impact on ATS. Regardless,
for the use case of 64GB in a single tranfer, any non-GCM cipher should suffice.
Suggest keeping ticket open for tracking purposes though move out version.
> TLS 64GB transfer fails with AES GCM cipher
> -------------------------------------------
>
> Key: TS-3699
> URL: https://issues.apache.org/jira/browse/TS-3699
> Project: Traffic Server
> Issue Type: Bug
> Reporter: Dave Thompson
> Assignee: Dave Thompson
> Labels: Yahoo
> Fix For: 7.0.0
>
>
> Running ATS 5.0.1, over a TLS connection using cipher suite AES128-GCM-SHA256
> will fail every time just before hitting 64GB. Switching cipher to the same
> CBC cipher (AES128-SHA), and data transfers can go beyond the 64GB limit.
> It appears we are hitting the GCM design limit of 2^39-256 bits (64GB). TLS
> should be able to renegotiate keys which resets the GCM counter, and in fact
> I have successfully tested this with ATS 4.0.2.
> Work around is to use the CBC variant (AES128-SHA), though it would be good
> to know what changed between 5.0.1 and 4.0.2 to stop cipher run out initiated
> renegotiation.
> FWIW proxy.config.ssl.allow_client_renegotiation, does not appear to come
> into play here. Looking at the code, this appears to be written to prevent
> client initiated renegotiation (prevent renegotiation attack circa 2009).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
