JDK-8206968 : java/net/httpclient/CancelledResponse.java after TLS 1.3 changeset
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Affected Version: 11
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2018-07-10
  • Updated: 2022-05-06
  • Resolved: 2022-05-06
Related Reports
Duplicate :  
JDK-8207009 - TLS 1.3 half-close and synchronization issues
Relates :  
JDK-8285774 - java.lang.RuntimeException: invalid key or spec in GCM mode
Description
Observed once in  jdk 11 b21 same binaries run. It is similar with JDK-8205013 (closed as dup) but with a bit difference in the stack traces.

Please see the output:
java.lang.RuntimeException: invalid key or spec in GCM mode
	at java.base/sun.security.ssl.SSLCipher$T12GcmWriteCipherGenerator$GcmWriteCipher.encrypt(SSLCipher.java:1709)
	at java.base/sun.security.ssl.OutputRecord.t10Encrypt(OutputRecord.java:423)
	at java.base/sun.security.ssl.OutputRecord.encrypt(OutputRecord.java:357)
	at java.base/sun.security.ssl.SSLSocketOutputRecord.encodeAlert(SSLSocketOutputRecord.java:70)
	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:354)
	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:268)
	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:263)
	at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1114)
	at java.base/sun.security.ssl.SSLSocketImpl$AppOutputStream.write(SSLSocketImpl.java:721)
	at java.base/java.io.OutputStream.write(OutputStream.java:122)
	at MockServer$Connection.send(MockServer.java:235)
	at CancelledResponse.lambda$sendSplitResponse$0(CancelledResponse.java:337)
	at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.security.InvalidAlgorithmParameterException: Cannot reuse iv for GCM encryption
	at java.base/com.sun.crypto.provider.CipherCore.init(CipherCore.java:583)
	at java.base/com.sun.crypto.provider.AESCipher.engineInit(AESCipher.java:346)
	at java.base/javax.crypto.Cipher.init(Cipher.java:1431)
	at java.base/sun.security.ssl.SSLCipher$T12GcmWriteCipherGenerator$GcmWriteCipher.encrypt(SSLCipher.java:1705)
	... 12 more
java.lang.IllegalStateException: Must use either different key or iv for GCM encryption
	at java.base/com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:900)
	at java.base/com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:491)
	at java.base/javax.crypto.CipherSpi.bufferCrypt(CipherSpi.java:779)
	at java.base/javax.crypto.CipherSpi.engineDoFinal(CipherSpi.java:730)
	at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2497)
	at java.base/sun.security.ssl.SSLCipher$T12GcmWriteCipherGenerator$GcmWriteCipher.encrypt(SSLCipher.java:1743)
	at java.base/sun.security.ssl.OutputRecord.t10Encrypt(OutputRecord.java:423)
	at java.base/sun.security.ssl.OutputRecord.encrypt(OutputRecord.java:357)
	at java.base/sun.security.ssl.SSLSocketOutputRecord.encodeAlert(SSLSocketOutputRecord.java:70)
	at java.base/sun.security.ssl.TransportContext.warning(TransportContext.java:247)
	at java.base/sun.security.ssl.TransportContext.initiateOutboundClose(TransportContext.java:551)
	at java.base/sun.security.ssl.TransportContext.closeOutbound(TransportContext.java:482)
	at java.base/sun.security.ssl.TransportContext.close(TransportContext.java:450)
	at java.base/sun.security.ssl.SSLSocketImpl.close(SSLSocketImpl.java:447)
	at MockServer$Connection.cleanup(MockServer.java:286)
	at MockServer$Connection.run(MockServer.java:165)
Comments
This is being fixed by JDK-8207009
07-08-2018
The TLS code should be thread safe. The problem is believed to be that the read thread sees a close_notify which cause the read thread to do a write operation. That write operation conflicts with the on-going write thread usage of the Cipher object doing the encryption. Synchronizing the methods fixes the conflict and performance should not be affected as this is the only known situation when this happens. Other solutions, like creating cipher objects or a cipher object pool would be a bigger performance hit in this limited failure situation. As this test case is hard to reproduce, I can't prove via the test case that the fix is correct. If the failure occurs again, I'll have to try something else.
20-07-2018
The HTTP Client may indeed have more than one thread executing, is that an issue? Is the security code expect to be thread-safe, or is the suggestion that the HTTP Client should ensure that this part of the security code is only called by a single thread?
20-07-2018
[~ascarpino] Can you please confirm that this is a sec-libs bug and not an HTTP Client issue? And that sec-libs is actively investigating, with the intention of resolution in 11.
12-07-2018