You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Glen Peterson <gl...@organicdesign.org> on 2014/11/13 03:58:51 UTC
Feature suggestion: excludeCiphers
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?
Background:
=========
We're getting an 'A' on the Qualys TLS test with stand-alone Tomcat,
which is pretty cool:
https://www.ssllabs.com/ssltest/index.html
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,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA" />
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: https://www.ssllabs.com/ssltest/index.html
- 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Feature suggestion: excludeCiphers
Posted by Zala Pierre GOUPIL <go...@gmail.com>.
Thanks, man! It's really helpful!
On Thu, Nov 13, 2014 at 5:43 PM, Glen Peterson <gl...@organicdesign.org>
wrote:
> 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?):
> http://tomcat.apache.org/tomcat-8.0-doc/ssl-howto.html
>
> 2. The "ciphers" section here doesn't mention that it accepts the
> OpenSSL syntax:
> http://tomcat.apache.org/tomcat-8.0-doc/security-howto.html
>
> This page has a helpful description of the syntax (what I used to
> learn it today):
> https://www.openssl.org/docs/apps/ciphers.html
>
> 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:
>
>
> ciphers="ALL:!aNULL:!eNULL:!EXPORT:!LOW:!MEDIUM:!3DES:!TLS_RSA_WITH_AES_128_CBC_SHA256:!TLS_RSA_WITH_AES_128_CBC_SHA:!TLS_RSA_WITH_AES_128_GCM_SHA256:@STRENGTH
> "
>
> 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 <ma...@apache.org> 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:
> >> https://www.ssllabs.com/ssltest/index.html
> >>
> >> 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,
> >> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
> >> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
> >> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,
> >> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
> >> TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
> >> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,
> >> TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA" />
> >>
> >> 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: https://www.ssllabs.com/ssltest/index.html
> >> - 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: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
>
>
>
> --
> Glen K. Peterson
> (828) 393-0081
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Si le sang ne coule pas assez chaud dans tes veines, je le répandrai sur le
sable pour qu'il bouille au soleil.
Re: Feature suggestion: excludeCiphers
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Glen,
On 11/13/14 3:18 PM, Glen Peterson wrote:
> On Thu, Nov 13, 2014 at 2:23 PM, Christopher Schultz
> <ch...@christopherschultz.net> wrote:
>> Patches are always welcome, including patches to the
>> documentation. Let me know if you'd like to provide one, and I
>> can give you instructions (they are pretty simple).
>
> Yes please.
The easiest thing (believe it or not) is to get a Subversion client
and then check-out the Tomcat trunk:
$ svn checkout http://svn.apache.org/repos/asf/tomcat/trunk
In there, you'll find all the Tomcat documentation in webapps/docs
Now, modify any of the files. Most of the documentation is stored in
.xml format but it's very easy to understand how it maps to the HTML
that gets generated.
When you are done, you can check things out by running:
$ ant build-docs
This will build the documentation as HTML, and you can proof-read your
edits.
When you are happy with them, you can make a patch by running svn diff:
$ svn diff webapps/docs
This will produce (on stdout) a patch that you can submit to the team.
Can you redirect it to a file to save it. The best way to submit a
patch is to create an issue in Bugzilla and attach the patch to it.
We'll do the rest.
Thanks!
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUZWCFAAoJEBzwKT+lPKRY5MAQAKsZlUuzOFZScGubr089x1v3
35WolyT/AH5A1IVks5J5LXyaZEgy/Qn/1Cs3ktVUE4oK1nLnWk+igEAIjvZiLrsw
paItTXndh20LLLbS9pWEb7kotOsy65Qe6UbSYIdn6gA12IiOIrvWMgZhf1vEPC9L
VHFpghWPHf207Ga/BTS7i6NaaZ2ZKjJPUMLkvLvmyLQZmUX9PYs9OzSe7SLd8gb3
EzEsDUgeYI/N6aWQ7/UzHbQIU8K7eP8o62re0SYZL13baUzLpdm4cbso8NTZGZWb
MOwSw4C/8Bi06uwQpXDi+trLsirRkyyhwnNk6+CnAwY9inNNK8KlvZqGaMua3eeV
P2cRjm/amhaX6wjX+yFrCM0t+VvVgm5jaN3KSrnWegzrpu841+e0yPzvorx6BbHP
FPLnCNwi0QiRjWDmMIIyFupEx8jDNq+9xvmZ4hjZ32kI+HV8Ncw8JW7/IBV8Vimk
GVB7mJ9fhzYM56kxB4IldOpUj7i1koy53pqHgaGBpd1srMikfXd1awtCu7pDm50h
0G5LBXBj75gM3euZxWvPKrRIcyabvPC6E6GHkSsZ04jdlDqqFl4seJioR/h7FtKf
dJ85cXvGsfirYEihMTlZ6rLPj96iDSLT7JZW3TQudSoNC8Xb5t3BQSFZu2vH2FhY
T3PUjUBgdncCw/JVrWUw
=xEdZ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Feature suggestion: excludeCiphers
Posted by Glen Peterson <gl...@organicdesign.org>.
On Thu, Nov 13, 2014 at 2:23 PM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> Patches are always welcome, including patches to the documentation.
> Let me know if you'd like to provide one, and I can give you
> instructions (they are pretty simple).
Yes please.
--
Glen K. Peterson
(828) 393-0081
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Feature suggestion: excludeCiphers
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Glen,
On 11/13/14 11:43 AM, Glen Peterson wrote:
> 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?):
> http://tomcat.apache.org/tomcat-8.0-doc/ssl-howto.html
>
> 2. The "ciphers" section here doesn't mention that it accepts the
> OpenSSL syntax:
> http://tomcat.apache.org/tomcat-8.0-doc/security-howto.html
>
> This page has a helpful description of the syntax (what I used to
> learn it today): https://www.openssl.org/docs/apps/ciphers.html
>
> If you like the ciphers element below, you are welcome to paste it
> in the docs.
Patches are always welcome, including patches to the documentation.
Let me know if you'd like to provide one, and I can give you
instructions (they are pretty simple).
> For anyone interested, this is what I ended up with:
>
> ciphers="ALL:!aNULL:!eNULL:!EXPORT:!LOW:!MEDIUM:!3DES:!TLS_RSA_WITH_AES_128_CBC_SHA256:!TLS_RSA_WITH_AES_128_CBC_SHA:!TLS_RSA_WITH_AES_128_GCM_SHA256:@STRENGTH"
>
> 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."
I don't believe JSSE has the ability for the server to specify a
preferred cipher order like tcnative/APR/OpenSSL do with
"SSLHonorCipherOrder".
http://serverfault.com/questions/316313/control-ssl-cipher-priority-order-for-tomcat-to-avoid-beast-attack
> 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.
IE8 on Windows XP should work as long as the proper TLS protocols have
been enabled. I believe Qualys is talking about a "default
configuration" of MSIE 8 on Windows XP.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUZQUrAAoJEBzwKT+lPKRYgToP/1rYKGihmAJLn21CzkSxURWZ
rT0FBibKeycm6i4AY6KIlOm3DyXnfd0N47yxKv0F/0OdX3Ms83trvMKjKT8Gh2jL
Z83JXU19aKFinHgRhCJDWHGKBKx+cFTxo9KEpljGd0YQInB4/AkBItVCGvdQKwX+
tr1YD6RC9kXbzD0tjn9+SMuqzmJSSs7XR33gBl4eCB5lGDE7vz3++JU7xbDzYNCA
ctqxuQstJq2fjeuvc3Bq6WhffP8/qQZHkTBGV64b55vnkXMPZL3Hb0kIYC1oFo/U
ni664Mc9WKTzf4NHRdmAHkA9cbrSV0kUQdxEEzFIWJ/gj3FyHdIydgz0sMa2+HEd
Rg2nQtmTsiLnHiIucqOrktZBgmBUtONCti5cSsRjfhwhh/7IjY9QLhFWIvbvLcz8
rFmwjW9c8qiT8D13E9PujSbuhxAL+gfgWdRlKePBqsZH6ftOWK4V1fA2cIAiW5rX
rL+Dozac5AtxXYQ7RvD651FG9YS/9Nv5t9NCm4muIBufg1dlbOQc8/jcEHA7tsUU
GaCb72qmVU9/XSP6IiWtLjC2PbCh4ouAfHgL7UyPPWlBv+UnZbvJzmNfX38NPrGG
LAN99XUFiqsHAP7P8vr58UNLoi/at2t0WHLIm3eO/txpKgZQOvK/dQ9Bxb0NDT2T
56D8Affe/VSQf0RnE5/4
=bLG/
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Feature suggestion: excludeCiphers
Posted by Glen Peterson <gl...@organicdesign.org>.
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?):
http://tomcat.apache.org/tomcat-8.0-doc/ssl-howto.html
2. The "ciphers" section here doesn't mention that it accepts the
OpenSSL syntax:
http://tomcat.apache.org/tomcat-8.0-doc/security-howto.html
This page has a helpful description of the syntax (what I used to
learn it today):
https://www.openssl.org/docs/apps/ciphers.html
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:
ciphers="ALL:!aNULL:!eNULL:!EXPORT:!LOW:!MEDIUM:!3DES:!TLS_RSA_WITH_AES_128_CBC_SHA256:!TLS_RSA_WITH_AES_128_CBC_SHA:!TLS_RSA_WITH_AES_128_GCM_SHA256:@STRENGTH"
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 <ma...@apache.org> 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:
>> https://www.ssllabs.com/ssltest/index.html
>>
>> 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,
>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,
>> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
>> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,
>> TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA" />
>>
>> 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: https://www.ssllabs.com/ssltest/index.html
>> - 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: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
--
Glen K. Peterson
(828) 393-0081
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Feature suggestion: excludeCiphers
Posted by Mark Thomas <ma...@apache.org>.
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:
> https://www.ssllabs.com/ssltest/index.html
>
> 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,
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,
> TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA" />
>
> 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: https://www.ssllabs.com/ssltest/index.html
> - 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: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org