Thinking out loud here...seems like we need to talk about impacts on both
sides of the wire.
On the client side, I don't think this can have any effect. According to
the TLS RFC (link), the ClientHello includes the
cipher_suites
This is a list of the cryptographic options supported by the
client, with the client's first preference first. If the
session_id field is not empty (implying a session resumption
request), this vector MUST include at least the cipher_suite from
that session. Values are defined in Appendix A.5.
So according to the spec, the client's first preference is to be first in
the list. If the client is now passing an unordered list, how does the
server know the client doesn't care? There's no provision for passing an
indicator in the protocol. So I don't think this proposal really applies
on the client side, and perhaps the setting name is too general (should be
setUseClientsCipherSuiteOrder?)
On the server side, this may explicitly force the server to follow the
client's list order, or to do whatever it does today. We need to be clear
what "true" means and what "false" means. (Does "false" mean that the
server CANNOT follow the client's preferences?)
And if I understood your example correctly, the Oracle server today
follows SSLParameters.setUseCipherSuitesOrder(true), so to change
behavior, it would have to be set to
SSLParameters.setUseCipherSuitesOrder(false). Unless of course, it's
supposed to mean "use local preferences for cipher ordering", and the
server interprets it according to its priority order (not expressed in the
protocol in any way), in which case maybe the operation would be called
SSLParameters.setUseLocalCipherSuitesOrder(boolean). However, a setting
to "false" still cannot really mean anything on the client side, for the
reasons mentioned above.
Bruce A Rich
brich at-sign us dot ibm dot com
From: Xuelei Fan <xuelei....@oracle.com>
To: OpenJDK <security-dev@openjdk.java.net>
Date: 08/05/2013 09:10 PM
Subject: There should be a way to reorder the JSSE ciphers
Sent by: security-dev-boun...@openjdk.java.net
Hi,
We are thinking about to support cipher suites preference in JSSE by
defining new methods in javax.net.ssl.SSLParameters.
----------------------------------------------------
+ /**
+ * Sets whether the cipher suites preference should be honored.
+ *
+ * @param on whether local cipher suites order in
+ * {@code #getCipherSuites}
+ * should be honored during SSL/TLS handshaking.
+ */
+ public final void setUseCipherSuitesOrder(boolean on);
+ /**
+ * Returns whether the cipher suites preference should be honored.
+ *
+ * @return whether local cipher suites order in
+ {@code #getCipherSuites}
+ * should be honored during SSL/TLS handshaking.
+ */
+ public final boolean getUseCipherSuitesOrder();
----------------------------------------------------
By default, Oracle JSSE provider still honors the client's preference.
The behavior can be changed by calling
SSLParameters.setUseCipherSuitesOrder(true) in server side.
We have had the cipher suites preference ordering in client side for
many years, but we never said how to actually do it in specification and
JSSE Reference Guide. With this update, the client side can enforce to
honor cipher suite preference with the new method,
SSLParameters.setUseCipherSuitesOrder(true). Other providers should
also comply with this specification.
Any feedback are welcome.
Thanks,
Xuelei
