You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2014/08/01 12:34:50 UTC
Re: svn commit: r1608840 [1/2] - in /tomcat/trunk: java/org/apache/tomcat/util/net/jsse/
java/org/apache/tomcat/util/net/jsse/openssl/ java/org/apache/tomcat/util/net/jsse/res/
webapps/docs/
On 31/07/2014 22:50, Mark Thomas wrote:
> I'm beginning to think that this feature is more effort than it is worth.
<snip/>
> The expected behaviour of this code is that for any given specification:
> - passing it through OpenSSL and mapping the resulting ciphers to those
> supported by the current JRE; and
> - passing it through this parser
>
> gives the same set of JSSE ciphers in the same order.
>
> Every time this doesn't happen we have a potential security issue since
> a weaker than intended cipher may be enabled. The incorrect handling of
> "ALL" that I have just fixed is an obvious example of such an issue.
Actually it is worse than that. Any difference is a potential security
issue as aliases may be used for inclusion and exclusion. Any
differences in the results for an alias could result in a cipher being
enabled that shouldn't be.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1608840 [1/2] - in /tomcat/trunk:
java/org/apache/tomcat/util/net/jsse/ java/org/apache/tomcat/util/net/jsse/openssl/
java/org/apache/tomcat/util/net/jsse/res/ webapps/docs/
Posted by Falco Schwarz <hi...@falco.me>.
On that note I thought I'd share the cipher suites we have been using:
kEECDH+ECDSA:kEECDH:kEDH:+SHA:-3DES:kRSA+3DES:!aNULL:!eNULL:!LOW:!MD5:!EXP:!DSS:!PSK:!SRP:!RC4:!SEED:!kECDH:!CAMELLIA
- avoids using RC4
- prefers forward secrecy for all browsers except those, which do not
support it
- no server-side mitigation of beast attack
- if java6 clients have to access the site, 1024bit dhparams have to be set
kEECDH+ECDSA:kEECDH:RC4:+AES+SHA:+RSA+RC4:!aNULL:!eNULL:!LOW:!MD5:!EXP:!DSS:!SRP:!PSK:!3DES:!SEED:!kECDH:!CAMELLIA
- server-side mitigation of beast attack, uses RC4 for older browsers though
- prefers forward secrecy for modern browsers
On Sat, Aug 2, 2014 at 12:19 AM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> Mark,
>
> On 8/1/14, 3:48 PM, Mark Thomas wrote:
> > On 01/08/2014 13:57, Rémy Maucherat wrote:
> >> Well, it can be disabled easily by reverting back to the old default in
> >> the endpoint. Sorry for all the defects, the code that was submitted was
> >> supposed to be fine ;)
> >
> > Thanks. I appreciate that.
> >
> >> If you think the feature is too complex and doesn't provide enough
> benefit,
> >> it can also be removed altogether.
> >
> > I'm still on the fence. I've removed the system property part as that
> > was changing the meaning of some aliases and that might cause a few
> > surprises.
> >
> > On balance I like the idea of the feature and having spent this week
> > getting it into shape I'm reluctant to just delete it.
> >
> > In terms of ensuring correct behaviour, we now have unit tests that
> > demonstrate that all the individual aliases are correct. Next I want to
> > test some more complex expressions to check the operators all behave as
> > expected.
>
> Here's one you can try on for size:
>
> !aNULL:!eNULL:!EXPORT:!DSS:!DES:!SSLv2:ECDHE:ECDH:DHE:AES256-GCM-SHA384:AES128-GCM-SHA256:+RC4:HIGH:MEDIUM
>
> I'm sure you can find more by googling for "httpd recommended
> CipherSuite" and see what kinds of crazy things people have been
> recommending to adjust things to get the "perfect" set of ciphers in
> whatever order ;)
>
> -chris
>
>
Re: svn commit: r1608840 [1/2] - in /tomcat/trunk: java/org/apache/tomcat/util/net/jsse/
java/org/apache/tomcat/util/net/jsse/openssl/ java/org/apache/tomcat/util/net/jsse/res/
webapps/docs/
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,
On 8/1/14, 3:48 PM, Mark Thomas wrote:
> On 01/08/2014 13:57, Rémy Maucherat wrote:
>> Well, it can be disabled easily by reverting back to the old default in
>> the endpoint. Sorry for all the defects, the code that was submitted was
>> supposed to be fine ;)
>
> Thanks. I appreciate that.
>
>> If you think the feature is too complex and doesn't provide enough benefit,
>> it can also be removed altogether.
>
> I'm still on the fence. I've removed the system property part as that
> was changing the meaning of some aliases and that might cause a few
> surprises.
>
> On balance I like the idea of the feature and having spent this week
> getting it into shape I'm reluctant to just delete it.
>
> In terms of ensuring correct behaviour, we now have unit tests that
> demonstrate that all the individual aliases are correct. Next I want to
> test some more complex expressions to check the operators all behave as
> expected.
Here's one you can try on for size:
!aNULL:!eNULL:!EXPORT:!DSS:!DES:!SSLv2:ECDHE:ECDH:DHE:AES256-GCM-SHA384:AES128-GCM-SHA256:+RC4:HIGH:MEDIUM
I'm sure you can find more by googling for "httpd recommended
CipherSuite" and see what kinds of crazy things people have been
recommending to adjust things to get the "perfect" set of ciphers in
whatever order ;)
-chris
Re: svn commit: r1608840 [1/2] - in /tomcat/trunk: java/org/apache/tomcat/util/net/jsse/
java/org/apache/tomcat/util/net/jsse/openssl/ java/org/apache/tomcat/util/net/jsse/res/
webapps/docs/
Posted by Mark Thomas <ma...@apache.org>.
On 01/08/2014 13:57, Rémy Maucherat wrote:
> Well, it can be disabled easily by reverting back to the old default in
> the endpoint. Sorry for all the defects, the code that was submitted was
> supposed to be fine ;)
Thanks. I appreciate that.
> If you think the feature is too complex and doesn't provide enough benefit,
> it can also be removed altogether.
I'm still on the fence. I've removed the system property part as that
was changing the meaning of some aliases and that might cause a few
surprises.
On balance I like the idea of the feature and having spent this week
getting it into shape I'm reluctant to just delete it.
In terms of ensuring correct behaviour, we now have unit tests that
demonstrate that all the individual aliases are correct. Next I want to
test some more complex expressions to check the operators all behave as
expected. Once the unit tests are in place I think I'll be happy about
this. We are uncovering differences between the OpenSSL docs and OpenSSL
code and I view that as a good sign that the unit tests are thorough.
In terms of maintenance, my hope is that the unit tests will spot any
change in behaviour between OpenSSL versions. We'll have to see how it
goes. If the unit tests work as I hope, then maintenance should not be a
big issue.
Overall, I think a note is called for in the docs along the lines of
this is supported but if the maintenance necessary to keep up with
changes in OpenSSL becomes to great it may be deprecated.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1608840 [1/2] - in /tomcat/trunk:
java/org/apache/tomcat/util/net/jsse/ java/org/apache/tomcat/util/net/jsse/openssl/
java/org/apache/tomcat/util/net/jsse/res/ webapps/docs/
Posted by Rémy Maucherat <re...@apache.org>.
2014-08-01 12:34 GMT+02:00 Mark Thomas <ma...@apache.org>:
> On 31/07/2014 22:50, Mark Thomas wrote:
> > I'm beginning to think that this feature is more effort than it is worth.
>
> <snip/>
>
> > The expected behaviour of this code is that for any given specification:
> > - passing it through OpenSSL and mapping the resulting ciphers to those
> > supported by the current JRE; and
> > - passing it through this parser
> >
> > gives the same set of JSSE ciphers in the same order.
> >
> > Every time this doesn't happen we have a potential security issue since
> > a weaker than intended cipher may be enabled. The incorrect handling of
> > "ALL" that I have just fixed is an obvious example of such an issue.
>
> Actually it is worse than that. Any difference is a potential security
> issue as aliases may be used for inclusion and exclusion. Any
> differences in the results for an alias could result in a cipher being
> enabled that shouldn't be.
>
> Well, it can be disabled easily by reverting back to the old default in
the endpoint. Sorry for all the defects, the code that was submitted was
supposed to be fine ;)
If you think the feature is too complex and doesn't provide enough benefit,
it can also be removed altogether.
Rémy