Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Broken pipe after jetty client upgrade

Douglas,

The whole issue of TLS/SSL protocols and ciphers is fraught and it is very difficult to make changes without having unexpected consequences.

We make  efforts to make sure that the jetty default configuration is up to date with the latest recommendations for both protocols and ciphers, as do the JVM vendors that provide the base set of protocols/ciphers available.

So if you are using a recent release of Jetty running on a recent JVM, then the default exclusion list is a reasonable approach.

It will not always be perfect, as we appear to live in an era of many discoveries of crypto vulnerabilities, so sometimes it may be necessary to manually configure the exclusions.  But as of today, we do not know of any such changes that we would recommend to deploy.

cheers










On 7 April 2016 at 23:41, Douglas Lopes Pereira <douglaslopespereira@xxxxxxxxx> wrote:
Hi guys,

this is my first post to the list, hopefully I will provide enough
details so you can help me.

We write an application that eventually sends http/https callbacks to the user.
We recently upgraded from Java 7 to Java 8 and with that we upgraded
jetty client from 9.1.1 to 9.3.8.

In our code, to prevent from the POODLE vulnerability we decided to
disable "SSLv3" in our context factory:

sslContextFactory.setExcludeProtocols("SSLv3");

As you may noticed we set the excluded password instead of adding it
to the excluded list. That code didn't change with the jetty client
upgrade.

The point is that after the upgrade a lot of connections with our
users got broken. Mainly because of broken pipe.

Checking the tcpdump for the SSL negotiation we realized that on jetty
client version 9.1.1 the default session initiation protocol was
TLSv1.2 therefore our user's servers were happy.

On the new jetty client 9.3.8, because we didn't change our code and
continued setting the excluded protocol list to only exclude "SSLv3",
the default initiation protocol was SSLv2, and that seems to be
breaking the connection (looks like our user's servers don't support
renegotiation). At this point we see the "Broken Pipe" exception.

If we remove the setExcludeProtocols code (relying on the default
exclusion list for 9.3.8) the communication works.

Is that a potential bug on jetty client?
We will probably go into production with the code to not change the
default exclusion list. Is that a reasonable approach?

Best regards!
Douglas
_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users



--

Back to the top