You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Alan M. Carroll (JIRA)" <ji...@apache.org> on 2015/12/16 22:18:46 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 ]

Alan M. Carroll updated TS-3699:
--------------------------------
    Fix Version/s:     (was: 6.1.0)
                   6.2.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
>              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)