JDK-4885061 : JSSE does not renegotate after hitting 2^64-1 sequenced packets.
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Affected Version: 5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2003-06-27
  • Updated: 2010-07-30
  • Resolved: 2010-07-30
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7Resolved
Related Reports
Duplicate :  
JDK-4873188 - Support TLS 1.1
Relates :  
JDK-7166487 - checkSequenceNumber method never called within readRecord of SSLEngineImpl
Description
According to Eric Rescorla (TLS 1.1 spec lead), SSL/TLS implementations
must renegotiate before reaching 2^64-1 packets.  We currently roll
over to 0.

Yes, this is for *REALLY* long lived processes, but Jessie's Fast TCP got me
thinking about it.  Eric will be adding a clarification to the TLS 1.1
spec.

###@###.### 2003-06-27
Comments
EVALUATION Didn't get this quite right, see: 7166487
04-05-2012
EVALUATION Don'w worry too much about the sequence wrap, it will take thousands of years to run out the 2^64 sequence number in practice. Address the defect with CR 4873188.
30-07-2010
EVALUATION I think what we can do is to send a renegotiation request after some large number (say 2^64 - 2^62), then kickstart a renegotiation. If we are in danger of a rollover (within a few packets), we need to shutdown the connection cleanly.
30-07-2010
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: dragon
02-09-2004
EVALUATION should do this either in 1.5.0 or 1.5.1. Does not need API changes. ###@###.### 2003-09-03
03-09-2003