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 < [email protected]> 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 > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins <[email protected]> CTO http://webtide.com
_______________________________________________ jetty-users mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
