You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Leif Hedstrom (JIRA)" <ji...@apache.org> on 2015/07/02 04:06:05 UTC
[jira] [Updated] (TS-3699) TLS 64GB transfer fails with AES GCM
cipher
[ https://issues.apache.org/jira/browse/TS-3699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leif Hedstrom updated TS-3699:
------------------------------
Fix Version/s: 6.1.0
> 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
> Fix For: 6.1.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)