Hi, This sounds like what I was reporting in https://bugs.eclipse.org/bugs/show_bug.cgi?id=412205 for WebSocket over SSL connections where the client ends in timeout instead of an immediate handshake failure. In my case the handshake exception gets burried by the SendUpgradeRequest, maybe something similar happens in your case. I'd be interested in a fix as well.
Regards, Xavier BRUGGHEMAN ________________________________________ De : [email protected] [[email protected]] de la part de Lothar Kimmeringer [[email protected]] Date d'envoi : lundi 15 juillet 2013 15:05 À : [email protected] Objet : [jetty-users] SSL-handshake more or less broken in Jetty 9.0.3 Hi, I know the subject is quite hard (as well, since this is my first mail in this group ;-) but I don't know of a better one, since it really seems to be the case. I'm currenty doing a migration from Jetty 7 to Jetty 9 and run into problems when setting up an SSL-server with and without needed client certificates. The problems are similar to the mail at http://dev.eclipse.org/mhonarc/lists/jetty-users/msg03102.html but it goes farther. I tried to create a bug-report at bugzilla (or add a comment to https://bugs.eclipse.org/bugs/show_bug.cgi?id=402626 which covers a bit of the whole problem) but I haven't found a register-link. The problem is that the server doesn't generate SSL-Alerts leaving the client in a socket.read() until that client is running into a timeout (which might be never in dependence on how the socket is created). The closing of the endpoint in oej.io.ssl.SslConnection doesn't seem to have any effect. Until there is a garbage collector run the socket stays open. Sooner or later (on low-traffic systems expect it to be the latter) the sockets are closed, so at least you shouldn't be able to construct a DoS-attack with this. To reproduce the problem I created a JUnit-testcase that allows an easy reproduction of the problem. As well you can see another problem occuring if you comment out lines 249-252 leading to the effect that the server get no server-certificates for the connection. In that case testSslStandardConnection will also end in a read timeout (in that case after two minutes). In addition to that I added the Wireshark-trace of the second test showing that no SSL-Alert is sent to the client and that the connection is only closed after the client ran into the timeout. Don't get confused by the IPs being involved. I ran a TCP-gateway on a second computer to be able to capture the packets, since this doesn't work here on the loopback device. If this bug-report is better sent to jetty-dev, just tell me ;-) JVM being used for the test is JDK 1.7.0_21 on Windows 32 Bit. The testcase uses BouncyCastle for the creation of the certificates the server should use. The testcase sets its own KeyStore, KeyManager and TrustManager, so you don't need to create file-based KeyStores before starting the test. This bug stopped our migration, so a fix is highly appreciated ;-) Best regards, Lothar Kimmeringer _______________________________________________ jetty-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/jetty-users
