Hi,
On Fri, Sep 25, 2015 at 3:44 AM, Xuelei Fan <xuelei....@oracle.com> wrote:
> For example, a client wants to negotiate {HTTP2, HTTP1.1} or {HTTP1.1,
> HTTP2} and {TLS_RSA_WITH_AES_128_CBC_SHA,
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384}.
> HTTP1.1/TLS_RSA_WITH_AES_128_CBC_SHA should be negotiated per the TLS
> and HTTP2 specification. If the cipher suites are sorted,
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 would be negotiated, this is not
> what the customer really expected. The customer preference should be
> respected.
>
> I don't think we really need to re-order the cipher suites.
"We" as in the OpenJDK implementation *must not* reorder the cipher suites.
"We" as in an application that wants to use HTTP/2 *must* reorder the
cipher suites.
The comparator provided is only a help to the application to perform
this reordering.
> Let's consider the following client requests (prefer cipher suite more
> than application protocol; blacklisted_CS are HTTP2 blacklisted cipher
> suite):
>
> 1. {HTTP2, HTTP1.1} {strong_cipher_site, blacklisted_CS}
> HTTP2 and strong_cipher_site should be negotiated. Need not to re-order
> cipher suites.
>
> 2. {HTTP1.1, HTTP2} {strong_cipher_site, blacklisted_CS}
> HTTP1.1 and strong_cipher_site should be negotiated. Need not to
> re-order cipher suites.
>
> 3. {HTTP2, HTTP1.1} {blacklisted_CS, strong_cipher_site}
> HTTP1.1 and blacklisted_CS should be negotiated. Need not to re-order
> cipher suites.
Of course you need to re-order in this case.
The application has just provided a preference for HTTP/2 in the
application protocol list, it actually happens that HTTP/2 could be
negotiated because strong ciphers are present, but instead HTTP/1.1 is
chosen.
> 4. {HTTP1.1, HTTP2} {blacklisted_CS, strong_cipher_site}
> HTTP1.1 and blacklisted_CS should be negotiated. Need not to re-order
> cipher suites.
>
> 5. {HTTP2} {strong_cipher_site, blacklisted_CS}
> HTTP2 and strong_cipher_site should be negotiated. Need not to re-order
> cipher suites.
>
> 6. {HTTP1.1} {strong_cipher_site, blacklisted_CS}
> HTTP1.1 and strong_cipher_site should be negotiated. Need not to
> re-order cipher suites.
>
> 7. {HTTP2} {blacklisted_CS, strong_cipher_site}
> blacklisted_CS would be filtered out as it does not appy to HTTP2. Only
> strong_cipher_site presents in ClientHello message.
>
> HTTP2 and strong_cipher_site should be negotiated. Need not to re-order
> cipher suites.
>
> 8. {HTTP1.1} {blacklisted_CS, strong_cipher_site}
> HTTP1.1 and blacklisted_CS should be negotiated. Need not to re-order
> cipher suites.
>
> One concern may be that, the customer is not intent to negotiate HTTP2
> blacklisted cipher suite. The customer just don't know which are the
> strong cipher suites among many cipher suites. I think we may need a
> handy tool to order the cipher suites before configuration.
>
> // there are a few cipher suites are available
> String[] cipherSuites = ... // a array of cipher suites.
>
> // Q: Don't know the strength of them
> // A: OK, there is a handy tool
> cipherSuites = cipherSuiteReorder.sort(cipherSuites);
Or, with the comparator:
cipherSuites = Arrays.sort(cipherSuites,
ApplicationProtocol.H2.CIPHER_COMPARATOR);
The comparator is the handy tool.
> // configure the cipher suites
> SSLParameters.setCipherSuites(cipherSuites);
>
> The order also apply to the normally cipher suites configuration, not
> only to application protocols. The re-order should be called by
> customers explicitly. JSSE would better not sort them automatically.
>
> I think, the handy sort tool cannot be simply bind to application
> protocol. For example, HTTP2 has a blacklisted cipher suites. OK,
> ApplicationProtocol.H2BLACKLISTCOMPARATOR is expected to make the sort.
> If, in the future, a new application protocol (AP_NEW) has a different
> blacklist cipher suites, a new
> ApplicationProtocol.APNEWBLACKLISTCOMPARATOR would be defined. If both
> {HTTP2, AP_NEW} would be requested, which comparator for the sorting
> would be used? None of them can sort the cipher suite properly. The
> comparator design will not work any more.
Sure it does.
Because you explicitly set a preference in the order of the
application protocol, you only sort to favour the best protocol.
In case you have [HTTP/2, AP_NEW, HTTP/1.1], then you can simply
compose the comparators to sort first with the H2.CIPHER_COMPARATOR,
then with AP_NEW.CIPHER_COMPARATOR.
cipherSuites = Arrays.sort(cipherSuites,
ApplicationProtocol.H2.CIPHER_COMPARATOR.thenComparing(AP_NEW.CIPHER_COMPARATOR));
> We may need a handy tool for the sorting for stronger cipher suites.
> But, AFAIU, the tool does not belong to ALPN.
Indeed, it belongs to ApplicationProtocol.H2, not to ApplicationProtocol.
--
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.
