There should be a way to reorder the JSSE ciphers

[Xuelei Fan]

Thank you for the valued feedback!

On 8/7/2013 1:37 AM, Bruce Rich wrote:
> 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 <http://www.ietf.org/rfc/rfc5246.txt>), 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?)
> 
The cipher suites in the ClientHello message is always ordered.  What I
want to propose to honor local cipher suites order in the return value
SSLParameters.getCipherSuites() during SSL/TLS handshaking.  In the
past, we don't specify what the cipher suite order should look like in
ClientHello message.  I think most providers use the order of the return
value of SSLParamaters.getCipherSuites().  But we won't declare the
behavior in the specification.   With this update, I want to describe
this behavior as part the specification.

But we may run into compatibility issues if third party's implementation
does not honor the order in SSLParamaters.getCipherSuites().  In order
to avoid compatibility issues, it is safer to set the default value of
getUseCipherSuitesOrder() to false, and won't define the behavior when
getUseCipherSuitesOrder() is false.

That is:

In client side:
1. if getUseCipherSuitesOrder() return true, the ClientHello messages
should use same the cipher suites order as getCipherSuites();

2. if getUseCipherSuitesOrder() return false, the behavior is not
defined (It is not required to honor the order in getCipherSuites()).


In server side:
1. if getUseCipherSuitesOrder() return true, the cipher suite selection
prefer to use the order in getCipherSuites, but not the order in
ClientHello message;

2. if getUseCipherSuitesOrder() return false, the behavior should comply
to TLS specification: the cipher suite selection should honor the order
in ClientHello message. (It is not required to honor the order in
getCipherSuites(), but should comply to TLS protocols.)


> 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?)
> 
See above.

> 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).
Not exactly, when SSLParameters is used in sever side,
setUseCipherSuitesOrder(false) means won't honor the order in
getCipherSuites(), which is the default behavior today and tomorrow.

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.

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

Yes.

>  However, a
> setting to "false" still cannot really mean anything on the client side,
> for the reasons mentioned above.
> 
Right, the behavior is not defined. See above.

I will try to make the specification more clear.

Thanks again for the feedback.

Xuelei

> Bruce A Rich
> brich at-sign us dot ibm dot com
> 
> 
> 
> 
> From:        Xuelei Fan <xuelei.fan at oracle.com>
> To:        OpenJDK <security-dev at 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-bounces at 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
> 
>