Hi Greg, thanks for taking time for jumping in.
I'm glad we are using a good recommended configuration. If I may ask, do you think that jetty client is correctly behaving when I explicitly set the exclusion list to "SSLv3" only that jetty client starts the initial SSL connection with a SSLv2Hello message? I get it that the SSLv2Hello protocol is now supported because I changed the default exclusion list. But shouldn't we start the communication with the "best"/more secure protocol? I was expecting it to start with TLSv1.2. Thanks for your attention. Regards, Douglas On Thu, Apr 7, 2016 at 7:13 PM, Greg Wilkins <[email protected]> wrote: > > 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 _______________________________________________ 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
