You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Dave Thompson (JIRA)" <ji...@apache.org> on 2016/04/11 16:41:25 UTC

[jira] [Commented] (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: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)