2014-07-21 19:57 GMT+02:00 Mark Thomas <ma...@apache.org>: > On 20 July 2014 23:40:50 CEST, Tim Whittington <t...@apache.org> wrote: > >This doesn’t look like it’ll work as expected on IBM JDKs (which do > >s/^TLS_/SSL_/ on all the TLS era cipher suite names). > > > >Also a big -0 for importing the brokenness that is the openssl ciphers > >syntax (seriously, I have to recite > >HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5 to do something sensible?). > >(I get the consistency argument internally (JSSE/APR connectors) and > >externally (Apache, nginx etc.), but meh). > > > >I’m not a fan of the closed-set approach either, but I haven’t got a > >better option that doesn’t involve magic cipher-suite name parsing > >unfortunately (both put you in an arms race with new suites for > >different reasons). > > This seems like a good point to add that I've been looking in to this and > the current mapping doesn't look right. It references cipher suites that > aren't in the standard names doc provided in the JRE docs and it also fails > to reference many suites that are in it. > > I'm less concerned about keeping up with new cipher suites. We can write > unit tests to catch those. > > Different cipher names in different JREs is going to be problematic. > > This is currently top if my to do list when I get back to work next week. > My current view of this feature is buggy with maintenance issues but I also > believe all these to be fixable/manageable. > > I might find some time to play with this this week so don't be surprised > if you see the odd commit from me in this area. >
We plan to do maintenance as needed on it too. Rémy
