There should be a way to reorder the JSSE ciphers

[Bernd Eckenfels]

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). 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