Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jetty-users] RE : SSL-handshake more or less broken in Jetty 9.0.3

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 : jetty-users-bounces@xxxxxxxxxxx [jetty-users-bounces@xxxxxxxxxxx] de la part de Lothar Kimmeringer [job@xxxxxxxxxxxxxx]
Date d'envoi : lundi 15 juillet 2013 15:05
À : jetty-users@xxxxxxxxxxx
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


Back to the top