[
https://issues.apache.org/jira/browse/TS-3699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15083752#comment-15083752
]
Dave Thompson commented on TS-3699:
-----------------------------------
Status Note: at IETF94 TLS working group (Nov 2015), ciphers re-keying schedule
discussion occurred initiating the establishment of a standard schedule, with
particular eye on AES-GCM and ChaCha20/Poly1305. Discussion considered
recommendations that were different than the 64GB implementation that has been
witnessed using OpenSSL for this bug. No resolution occurred, the standard is
in play while the cryptographers debate safe re-key schedules. For now,
perhaps the best course is for the user to pick a different cipher that is not
re-key schedule limited (e.g. AES-CBC) if their use case requires continuous
streams that exceed 64GB or similar.
https://www.ietf.org/proceedings/94/slides/slides-94-tls-5.pdf (page 22)
> 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: 6.2.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)
