There should be a way to reorder the JSSE ciphers

[Matthew Hall]

On Wed, Aug 07, 2013 at 04:57:39AM +0200, Bernd Eckenfels wrote:
> (One could think about a generic CipherSelector interface or a
> decide method in the HandshakeListener if you really want to make
> this configurable independend of the implementations. I somewhat
> doubt that there are a lot of users who implement high-performance
> SSL servers in pure Java anyway).

This is not totally true. Many people use the PKCS11 Provider to do it with 
Java in the upper layer, and C for the crypto primitives, but the cipher 
negotiation happens in the C code. It is a very popular and performant way of 
handling SSL + NIO in Tomcat for example.

> I can imagine one wants to influence the picking of ciphers on the
> server in a way that it is not RFC compliant but more
> performant/secure. A ordered list on the server is not a method I
> would chose. Instead I would have a list of prefered ciphers (pick
> the first prefered cipher from the client and only if there are none
> pick the first otherwise supported cipher from the client).

This sounds good in theory but when you work in an Internet scale content 
provider it breaks things when the client can pick bad ciphers and the server 
just allows it to happen like in default Java up until now.

So you really need a way to have a very short list on the server, ordered by 
level of socket connections and amount of bandwidth that can be handled by a 
given cipher according to internal benchmarks, and you need to find the most 
peformant one the client can allow from your very short list of ciphers, that 
you've decided meet your minimum security cut-off for a given service.

Matthew.