tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Whittington <t...@apache.org>
Subject Re: Tomcat cipher suite config. Was: Tomcat 7 cannot get ciphers with SHA256 or SHA384
Date Tue, 27 May 2014 22:10:41 GMT

On 28/05/2014, at 9:48 am, Konstantin Kolinko <knst.kolinko@gmail.com> wrote:

> 2014-05-28 1:35 GMT+04:00 Tim Whittington <timw@apache.org>:
>> Switching to dev list…
>> 
>>> 
>>>> I’m using the interactive mode of https://github.com/timw/groktls
>>>> to dump these.
>>> 
>>> Cool. I was just using the SSLInfo class and grep, obviously :)
>>> 
>>> I've been thinking that the way Tomcat does JSSE cipher suites is a
>>> bit ... verbose. It would be nice to roll something like what
>>> groktls/OpenSSL can do into Tomcat.
>>> 
>> 
>> I was kinda planning that when I wrote it,  but it ended up getting a bit big to
insert into Tomcat - doing a Java 7 upgrade across Oracle/HP and IBM (who have mostly the
same cipher suites, but with SSL_ instead of TLS_ at the front) and trying to enumerate the
sensible cipher suites broke me.
>> 
>> I’m using it in our internal platform (which embeds Tomcat), and that works really
well - ciphers=FIPS:@STRENGTH is a lot simpler as a default config than the 84 cipher suite
names it was previously (will be worse again in Java 8). I know you don’t have to list a
bunch of those 84 for things to work OK, but it’s still easier to understand if it’s policy
based.
>> 
>> I’d still be interested in helping Tomcat get something like this - inserting a
third party lib is probably a no go, but there’s no problem with copying the code (APLv2)
or the idea.
>> 
>> The biggest problem I see with the policy based approach is the lack of standardisation
of names that makes forward compatibility quite tricky - for example the CCM suites in RFC6655
leave off the digest/mac algo, the CHACHA20_POLY1305 construction in draft-agl-tls-chacha20poly1305
(among others) use different numbers of terms for the cipher suite etc.
>> I’m wondering whether a simpler term matching approach might work better than the
full parsing approach currently used in groktls.
>> 
>> The OpenSSL expressions are horrific though (I copied some of the syntax, but not
the semantics):
>> e.g. our current internal Apache config is -ALL:!ADH:!EXP:!aNULL:!SSLv2:!MD5:!KRB5:!PSK:HIGH+TLSv1.2:HIGH+TLSv1
>> Surely we can do better than that...
>> 
> 
> I do not see how "FIPS:@STRENGTH" or similar can be done without
> coding some list of actual cipher names.
> 

groktls does it by parsing cipher suite names, and then matching on component parts, but in
general you’re correct.
The matching is fairly sane (although things like FIPS can evolve - new CCM cipher suites
is an example), the parsing is pretty hacky though...

> As for that I have an idea not for Apache Tomcat source code, but for
> an administrator:
> 
> Put that list into catalina.properties as a property, and reference it
> in actual server.xml, e.g. ${FIPS_STRENGTH}.
> 
> How to prepare that list may be a topic for a Wiki.
> 

This just shifts the problem, so preparing the list is still hard to manage.
groktls in interactive mode lets you produce that list based on policy expressions, so you
can do that now if it’s workable for you.
(I just hacked in a bare mode that spits out a comma separated list).

cheers
tim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message