TLS ALPN Proposal v5

Simone Bordet sbordet at webtide.com
Fri Sep 25 08:11:58 UTC 2015


Hi,

On Fri, Sep 25, 2015 at 3:44 AM, Xuelei Fan <xuelei.fan at 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.



More information about the security-dev mailing list