[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 ] Dave Thompson updated TS-3699: -- Labels: Yahoo (was: ) > 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.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)
[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 ] Dave Thompson updated TS-3699: -- Fix Version/s: (was: 6.2.0) 7.0.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: 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)
[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: -- Component/s: SSL > 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 > Components: SSL >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)
[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 ] Bryan Call updated TS-3699: --- Fix Version/s: (was: 7.0.0) sometime > 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 > Components: SSL >Reporter: Dave Thompson >Assignee: Dave Thompson > Labels: Yahoo > Fix For: sometime > > > 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)
[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 ] Susan Hinrichs updated TS-3699: --- Assignee: Dave Thompson > 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 > > 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)
[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)
[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)
