tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Peterson <>
Subject Re: Feature suggestion: excludeCiphers
Date Thu, 13 Nov 2014 16:43:08 GMT
Thank you Mark - that works great!  That feature suggestion is not
needed after all.

I found two places where the Tomcat 8 documentation could be more
helpful.  I would be happy to do the following updates if I'm allowed:

1. I didn't see "ciphers" on this page at all (maybe it should be
renamed TLS-howto in a post-POODLE world?):

2. The "ciphers" section here doesn't mention that it accepts the
OpenSSL syntax:

This page has a helpful description of the syntax (what I used to
learn it today):

If you like the ciphers element below, you are welcome to paste it in the docs.

For anyone interested, this is what I ended up with:


Maybe someone more familiar with OpenSSL options could do better, but
this is working and should be forward-compatible because it eliminates
weaker ciphers without specifying which stronger ones to use.  Note
that without specifying @STRENGTH (which means to sort in decreasing
order by strength), nmap couldn't find
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 but Qualys did, so sorting seems
to have some effect for certain clients.  Even sorted like this,
Qualys still reports that, "the server has no preference."

Also note, that the new configuration doesn't support IE8 on Windows
XP, but we currently support IE8/Vista and forward.  Qualys says IE7
on Vista still works, so presumably IE8 would work there too.

On Thu, Nov 13, 2014 at 9:16 AM, Mark Thomas <> wrote:
> On 13/11/2014 02:58, Glen Peterson wrote:
>> Tomcat has been one of my favorite pieces of software for about a
>> decade.  Thanks to all your generous contributions it just keeps
>> getting better!  I appreciate the focus on security in Tomcat 8.
>> Suggestion:
>> =========
>> Instead of specifying allowed ciphers in the Connector node of
>> server.xml, I'd like to specify dis-allowed/excluced ciphers so that
>> as new, better cipher suites become available we won't have to do
>> anything.  Maybe an "excludeCiphers" attribute?
> You should be able to do this already in Tomcat 8 if you use the OpenSSl
> syntax.
> Mark
>> Background:
>> =========
>> We're getting an 'A' on the Qualys TLS test with stand-alone Tomcat,
>> which is pretty cool:
>> Mostly, that's because of the following settings (in case this helps anyone):
>> <Connector port="8443"
>>   protocol="org.apache.coyote.http11.Http11NioProtocol"
>>   maxThreads="150" SSLEnabled="true"
>>   scheme="https" secure="true"
>>   clientAuth="false"
>>   sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2"
>>   compression="on" disableUploadTimeout="true"
>>   connectionTimeout="180000"
>>   URIEncoding="UTF-8"
>>   keystorePass="notTheRealPassword"
>>   ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
>> It seems like just a few years ago there were about 50 cipher suites
>> to choose from.  Now there are 12 that work with TLS.  Eight of those
>> have Forward Security (the 8 listed above).  Presumably those eight
>> will also become outdated over time and new ones will be added to
>> replace them.  The problem with specifying ciphers as above is that
>> someone will have to know when and how to manually update the cipher
>> list.
>> With each upgrade of Java, we need to remember to do something like
>> the following:
>>  - Delete the ciphers attribute
>>  - Restart tomcat
>>  - Test here:
>>  - Copy the list of cipher suites
>>  - Delete any that don't support Forward Security
>>  - Make a new ciphers attribute.
>>  - Verify that the browsers and devices we support will still work.
>> To be honest, I'm not sure if that needs to be done with each Java
>> patch release, or only when Java 9 comes out.  If instead of
>> specifying valid ciphers, I specified invalid ones, then the new ones
>> would just flow through the system and become available without me
>> doing anything!
>> Thank you in advance for considering this suggestion.
>> @GlenKPeterson
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Glen K. Peterson
(828) 393-0081

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message