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

> 2014-05-28 1:35 GMT+04:00 Tim Whittington <t...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to