On 09/07/2014 13:46, jean-frederic clere wrote: > On 09/07/14 02:22, Konstantin Kolinko wrote: >> 2014-07-08 23:52 GMT+04:00 Rémy Maucherat <r...@apache.org>: >>> Hi, >>> >>> Using the newly added OpenSSL syntax processor, a safe default cipher >>> suite >>> can be expressed as (for both native and JSSE): >>> "HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5" >>> This avoids weak ciphers in a neat and portable way, although the "best" >>> default is still under investigation. >>> >>> I plan to change the default for AbstractProcessor.ciphers and >>> AprEndpoint.SSLCipherSuite to that string. >> >> Do you expect to maintain that string and to change the value between >> point releases in the future? >> >> (1.) If not, then it may become obsolete and the situation will not be >> much different from what we have now. >> >> (2.) If yes, then do we have enough man power to test and support such >> changes? >> An expected situation is that some clients won't be able to connect to >> their servers after such changes. >> >> Do we make a decision of changing the setting by ourselves, or we rely >> on some authority? E.g. we may follow [1]. >> >> In general, I like the idea. >> I think it targets those admins who do not care enough to be able to >> configure the values by themselves. >> >> Regarding testing any changes to the value, >> https://www.ssllabs.com/ssltest/ server test simulates some known >> clients and prints what cipher they would choose with those settings. >> E.g. (results for some site) >> "IE 6 / XP": "Protocol or cipher suite mismatch" >> so those people wouldn't be able to connect. >> >> >> A good resource: >> [1] https://wiki.mozilla.org/Security/Server_Side_TLS >> >> Their current recommendation is >> "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128:AES256:AES:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK" >> >> > > Actually people in our security team suggest to remove DES-CBC3-SHA and > document how to add back it for backwards compatibility if needed.
My personal preference would be a selection that gets the best possible score given the limitation of the ciphers provided by the JRE (with the export grade stuff enabled) with https://www.ssllabs.com/ssltest/ with the additional requirement that it includes a working configuration for all of the reference clients. On a related topic, it would be extremely useful if the available ciphers were exposed through the native interface. Anyone with C skills fancy taking a look? My main motivation for this is that we can write a unit test that checks the mapping of OpenSSL ciphers to JSSE ciphers and highlights (by a failure) when the mapping changes (e.g. one of them adds support for a new cipher). Mark > > Cheers > > Jean-Frederic > >> >> So >> 1) I am OK with the change. >> 2) I think there must be an explicit warning in documentation that the >> default value may change at any time. >> 3) I think we should rely on some authority like [1] and follow them. >> >> Instead of hard-coding the value in Java code, maybe put it as a >> property into catalina.properties file, and reference it as >> ${propertyname} in server.xml? >> >> We have a nice tool to compare catalina.properties between versions at >> http://tomcat.apache.org/migration-8.html#Upgrading_8.0.x >> >> Best regards, >> Konstantin Kolinko >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: security-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: security-h...@tomcat.apache.org >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
