There should be a way to reorder the JSSE ciphers

[Xuelei Fan]

To have the server to selection the cipher suites according to itself
preference is not standard compliant.  However, there are potential
requirements to have such feature so that the server can have more
control over the selection of cipher suites.  OpenSSL has had the option
for a while (SSL_OP_CIPHER_SERVER_PREFERENCE) and Apache support this
option also (SSLHONORCIPHERORDER).

This feature can be used to improve the security of TLS connection, for
example to mitigate the BEAST attacks in a proactive approach.
Sometimes, server cannot control the quality of TLS implementation and
usage in client side, but by choosing a stronger cipher suites or an
effective cipher suite, the server has an option to control the quality
of the TLS connection.

On 8/7/2013 10:57 AM, Bernd Eckenfels wrote:
> Hello Xuelei,
> 
> I dont get the Idea behind this. There are quite a few aspects of the
> SSL handshake which could/should be dynamically configurable and we
> don't have an option for today (for example the renegotiation).
> 
> For SSL Cipher order there is no real demand to make it configurable
> (and it seems there is not even an alternative implementation which
> differs from the RFC method). So why would one make it configurable?
> 
> If there is a specification gap, I would fix it there and simply specify
> that client implementations SHOULD honor the cipher sequence for sending
> the handshake and servers SHOULD be RFC compliant. I think major
> implementations expect exactly this anyway (there are FAQs on what
> ciphers to select).
> 
> If a server implementation choses to differ from the RFC because it
> thinks it can better decide on a cipher (for example by calculating
> strength/cost for all pairs and picking the best combination or by
> having a prefered and acceptable list - (which is I guess what google
> servers do)) it is implementation specific if and when it uses it.
> 
> (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).
> 
> Am 07.08.2013, 04:26 Uhr, schrieb Xuelei Fan <xuelei.fan at oracle.com>:
>> The tricky is that we need to think about the parameters from the
>> viewpoint of server side here. In server side,
>> SSLParameter.getCipherSuites() defines what kind of cipher suites are
>> supported in server side, and the order.
> 
> 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).

That's an alternative approach.

We have already have the server supported cipher suites
(getCipherSuites()).  We want to re-use the supported cipher suites, by
adding a feature those cipher suites can be ordered and honored (in your
words, the preferred ciphers).  It's a simpler interface, I think.

Thanks,
Xuelei

> For this to work a SSL implementation
> needs more than a ordered list, so it would do something implementation
> dependend anyway, why would one need a standardized boolean in addition?
> 
> Bernd