-
Notifications
You must be signed in to change notification settings - Fork 6.2k
8274524: SSLSocket.close() hangs if it is called during the ssl handshake #7432
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Closed
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
d1c2a4f
8274524: SSLSocket.close() hangs if it is called during the ssl hands…
alexeybakhtin 065073d
Reimplemented readLock, added lock in readHandshakeRecord
alexeybakhtin 145149b
Add ClientSocketCloseHang jtreg test
alexeybakhtin 02aa671
Fix jcheck issues
alexeybakhtin 7ac9481
Add read timeout for deplete
alexeybakhtin 6ea3007
Change read timeout value for skip
alexeybakhtin File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
134 changes: 134 additions & 0 deletions
134
test/jdk/sun/security/ssl/SSLSocketImpl/ClientSocketCloseHang.java
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,134 @@ | ||
| /* | ||
| * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved. | ||
| * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. | ||
| * | ||
| * This code is free software; you can redistribute it and/or modify it | ||
| * under the terms of the GNU General Public License version 2 only, as | ||
| * published by the Free Software Foundation. | ||
| * | ||
| * This code is distributed in the hope that it will be useful, but WITHOUT | ||
| * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or | ||
| * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License | ||
| * version 2 for more details (a copy is included in the LICENSE file that | ||
| * accompanied this code). | ||
| * | ||
| * You should have received a copy of the GNU General Public License version | ||
| * 2 along with this work; if not, write to the Free Software Foundation, | ||
| * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. | ||
| * | ||
| * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA | ||
| * or visit www.oracle.com if you need additional information or have any | ||
| * questions. | ||
| */ | ||
|
|
||
| /* | ||
| * @test | ||
| * @bug 8274524 | ||
| * @summary 8274524: SSLSocket.close() hangs if it is called during the ssl handshake | ||
| * @library /javax/net/ssl/templates | ||
| * @run main/othervm ClientSocketCloseHang TLSv1.2 | ||
| * @run main/othervm ClientSocketCloseHang TLSv1.3 | ||
| */ | ||
|
|
||
|
|
||
| import javax.net.ssl.*; | ||
| import java.net.InetAddress; | ||
|
|
||
| public class ClientSocketCloseHang implements SSLContextTemplate { | ||
|
|
||
| public static void main(String[] args) throws Exception { | ||
| System.setProperty("jdk.tls.client.protocols", args[0]); | ||
| for (int i = 0; i<= 20; i++) { | ||
| System.err.println("==================================="); | ||
| System.err.println("loop " + i); | ||
| System.err.println("==================================="); | ||
| new ClientSocketCloseHang().test(); | ||
| } | ||
| } | ||
|
|
||
| private void test() throws Exception { | ||
| SSLServerSocket listenSocket = null; | ||
| SSLSocket serverSocket = null; | ||
| ClientSocket clientSocket = null; | ||
| try { | ||
| SSLServerSocketFactory serversocketfactory = | ||
| createServerSSLContext().getServerSocketFactory(); | ||
| listenSocket = | ||
| (SSLServerSocket)serversocketfactory.createServerSocket(0); | ||
| listenSocket.setNeedClientAuth(false); | ||
| listenSocket.setEnableSessionCreation(true); | ||
| listenSocket.setUseClientMode(false); | ||
|
|
||
|
|
||
| System.err.println("Starting client"); | ||
| clientSocket = new ClientSocket(listenSocket.getLocalPort()); | ||
| clientSocket.start(); | ||
|
|
||
| System.err.println("Accepting client requests"); | ||
| serverSocket = (SSLSocket) listenSocket.accept(); | ||
|
|
||
| serverSocket.startHandshake(); | ||
| } finally { | ||
| if (clientSocket != null) { | ||
| clientSocket.close(); | ||
| } | ||
| if (listenSocket != null) { | ||
| listenSocket.close(); | ||
| } | ||
|
|
||
| if (serverSocket != null) { | ||
| serverSocket.close(); | ||
| } | ||
| } | ||
| } | ||
|
|
||
| private class ClientSocket extends Thread{ | ||
| int serverPort = 0; | ||
| SSLSocket clientSocket = null; | ||
|
|
||
| public ClientSocket(int serverPort) { | ||
| this.serverPort = serverPort; | ||
| } | ||
|
|
||
| @Override | ||
| public void run() { | ||
| try { | ||
| System.err.println( | ||
| "Connecting to server at port " + serverPort); | ||
| SSLSocketFactory sslSocketFactory = | ||
| createClientSSLContext().getSocketFactory(); | ||
| clientSocket = (SSLSocket)sslSocketFactory.createSocket( | ||
| InetAddress.getLocalHost(), serverPort); | ||
| clientSocket.setSoLinger(true, 3); | ||
| clientSocket.startHandshake(); | ||
| } catch (Exception e) { | ||
| } | ||
| } | ||
|
|
||
| public void close() { | ||
| Thread t = new Thread() { | ||
| @Override | ||
| public void run() { | ||
| try { | ||
| if (clientSocket != null) { | ||
| clientSocket.close(); | ||
| } | ||
| } catch (Exception ex) { | ||
| } | ||
| } | ||
| }; | ||
| try { | ||
| // Close client connection | ||
| t.start(); | ||
| t.join(2000); // 2 sec | ||
| } catch (InterruptedException ex) { | ||
| return; | ||
| } | ||
|
|
||
| if (t.isAlive()) { | ||
| throw new RuntimeException("SSL Client hangs on close"); | ||
| } | ||
| } | ||
| } | ||
| } | ||
|
|
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This set will impact the socket overall behavior unexpectedly, not just the close() method.
Maybe, an input stream level synchronization is missed in the SSLSocketInputRecord method, so that logic of deplete could be interrupted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @XueleiFan,
Not quite sure What could be wrong with setting SO_TIMEOUT during the socketClose() operation. We still close the socket and SO_TIMEOUT will be restored just after skip() operation is completed. These changes could affect the parallel read of the handshake records (we hold appInput.readLock during the skip) but we still close the socket and interrupt connection in this case.
If you still think these changes are incorrect, What do you think about the most first version of the patch: d1c2a4f
This version adds a new lock in the SSLSocketInputRecord and protects the parallel execution of the read and skip operations.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I understand the issue correctly, the problem is about that the skip method cannot get the right length if the input stream could be accessed in another thread.
I think we could focus on on address the synchronization problem, because the problem could result in other weird behaviors we don't know yet.
For the SO_TIMEOUT, I think it is a good workaround. But I'm not sure if it will impact other behaviors or not. Besides, I know you are trying to use a small timeout, but it is still blocked and it not easy to find a number fit all situation that does not impact the performance.
As I commented in the 1st version, I'm not sure of the locks logic in the patch, which changes the behavior of SSLSocket.
I may suggest to an input stream level synchronization. I know the update could take a while, and may not be able to integrate in time. If you want to fix the issue as soon as possible, I'm OK to move ahead with your current direction, but please set the SO_TIMEOUT to as minimal as possible, for example 1 ms; and have a comment that this is a temporary/workaround solution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you again for your detailed response and comments.
Your assumption about this issue is right and I think SO_TIMEOUT should be an acceptable solution.
I've changed DEFAULT_SKIP_TIMEOUT to 1 ms and added comments about a temporary workaround.
If you don't mind, I'd like to commit it asap because this patch should be backported to the early versions.
No regressions were found on the sun/security/ssl tests.