Also note that these SSL/TLS restrictions are being implemented at the JVM level as well. When you upgrade your JVM you'll likely lose these cipher suites as well.
We have chosen to be release as secure of a product as we can. If you want a less secure setup, then configure it so. That is your acknowledgement that you understand the risks and have chosen to disregard them for your specific situation. Joakim Erdfelt / [email protected] On Wed, Mar 16, 2016 at 7:46 AM, Marvin Addison <[email protected]> wrote: > I'm troubled by the following commit: > > > https://github.com/eclipse/jetty.project/commit/0a1b0b2bc69ea7e7f5f44992f47a84f926cdeebb > > That prevents the following cipher suites _by default_ required for TLS1 > interoperability according to NIST [1]: > SSL_RSA_WITH_3DES_EDE_CBC_SHA > TLS_RSA_WITH_AES_128_CBC_SHA > > In our testing, this effectively requires clients to negotiate TLS 1.2 > connections, which is simply impractical. While our strict set of cipher > suites may be contributing to this behavior, it's a pretty dramatic change > in defaults for a patch release (9.3.6-9.3.7). I appreciate your desire to > ship secure defaults, but I think this may go too far. Of course it's an > easy fix to explicitly configure all SSL protocol settings explicitly, but > I burnt several hours tracking down what to override. I encourage you to > reconsider. > > Thanks, > Marvin > > [1] > http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf, > section 3.3.1 > > > _______________________________________________ > 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
