JDK-8049314 : javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java fails intermittently with "Unexpected EOF" message
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • Submitted: 2014-07-04
  • Updated: 2019-11-29
  • Resolved: 2016-06-21
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 9
9 b125Fixed
Related Reports
Relates :  
JDK-8160339 - Remove intermittent key from javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java
Relates :  
JDK-8231810 - javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java fails intermittently with "java.lang.Exception: Unexpected EOF"
Relates :  
JDK-8148497 - Mark SSLSocketSSLEngineTemplate.java as failing intermittently
Description
javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java test failed in JDK9/b19 Regression Tests Same Binaries Run (1 time during 139 run on linux-amd64 platform):

server unwrap: BUFFER_OVERFLOW/NOT_HANDSHAKING, 0/0 bytes
----
server wrap: OK/NOT_HANDSHAKING, 0/0 bytes
================
----------System.err:(14/782)----------
java.lang.Exception: Unexpected EOF
	at SSLSocketSSLEngineTemplate.runTest(SSLSocketSSLEngineTemplate.java:254)
	at SSLSocketSSLEngineTemplate.main(SSLSocketSSLEngineTemplate.java:157)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:484)
	at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
	at java.lang.Thread.run(Thread.java:745)
Comments
Code review: http://mail.openjdk.java.net/pipermail/security-dev/2016-June/014206.html
20-06-2016
I was able to reproduce it manually (it failed after about 2500 runs). Calling compact() method before continuing (as Brad suggested) seems to solve the issue. sun/security/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java test doesn't seems to be affected because it always calls compact() after flip().
20-06-2016
These are apparently the only ones. ./javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java ./sun/security/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java
08-07-2014
Can you help to check it? I mistake assign this bug to me.
08-07-2014
Test bug. We see this due to a race condition in how sessions are reused. If the server port is reallocated during the lifetime of the app, then clients will attempt a SSL session renegotiation, which will trigger a bug in the close code. In the data: SSLv3 proceeds with full handshakes, and alternates client/server shutting down. TLSv1 proceeds. The first handshake is full. The second handshake is abbreviated, which means a SSLSession was reused. Note ClientHello/ServerHello sizes. 154 vs 186 652 vs 86 Testing TLSv1 ================ server unwrap: OK/NEED_TASK, 154/0 bytes running delegated task... new HandshakeStatus: NEED_WRAP ---- server wrap: OK/NEED_UNWRAP, 0/652 bytes ================ server unwrap: OK/NEED_TASK, 75/0 bytes running delegated task... new HandshakeStatus: NEED_UNWRAP ---- server wrap: OK/NEED_UNWRAP, 0/0 bytes ================ server unwrap: OK/NEED_UNWRAP, 6/0 bytes ---- server wrap: OK/NEED_UNWRAP, 0/0 bytes ================ server unwrap: OK/NEED_WRAP, 53/0 bytes ---- server wrap: OK/NEED_WRAP, 0/6 bytes ================ server unwrap: BUFFER_UNDERFLOW/NEED_WRAP, 0/0 bytes ---- server wrap: OK/FINISHED, 0/53 bytes ...ready for application data ================ server unwrap: OK/NOT_HANDSHAKING, 85/49 bytes ---- server wrap: OK/NOT_HANDSHAKING, 30/69 bytes ================ server unwrap: BUFFER_UNDERFLOW/NEED_WRAP, 0/0 bytes ---- server wrap: CLOSED/NEED_UNWRAP, 0/37 bytes ================ server unwrap: CLOSED/NOT_HANDSHAKING, 37/0 bytes ---- server wrap: CLOSED/NOT_HANDSHAKING, 0/0 bytes Now the abbreviated: ================ server unwrap: OK/NEED_TASK, 186/0 bytes running delegated task... new HandshakeStatus: NEED_WRAP ---- server wrap: OK/NEED_WRAP, 0/86 bytes ================ server unwrap: OK/NEED_WRAP, 0/0 bytes ---- server wrap: OK/NEED_WRAP, 0/6 bytes ================ server unwrap: OK/NEED_WRAP, 0/0 bytes ---- server wrap: OK/NEED_UNWRAP, 0/53 bytes ================ server unwrap: OK/NEED_UNWRAP, 6/0 bytes ---- server wrap: OK/NEED_UNWRAP, 0/0 bytes ================ server unwrap: OK/FINISHED, 53/0 bytes ...ready for application data ---- server wrap: OK/NOT_HANDSHAKING, 30/69 bytes Need to read more from client ================ server unwrap: BUFFER_OVERFLOW/NOT_HANDSHAKING, 0/0 bytes ---- server wrap: OK/NOT_HANDSHAKING, 0/0 bytes Note the OVERFLOW. The final unwrap is the Finished message, and server immediately sends its text message in the wrap. We then enter the serverOut.remaining() conditional. We mark closed, then do a serverIn.flip(), and go into the "Need to read more from client" loop, and which doesn't undo the flip, thus leading to the overflow. We probably need to do a compact before continuing. We could also invalidate the session, but probably a good idea to keep it around as it exposed a bug like this. We should look in the existing test cases and see which tests were based off this template.
08-07-2014