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 <[email protected]>:
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
