On 9/25/2015 7:45 AM, Bradford Wetmore wrote:
>
> On 9/23/2015 2:33 AM, Simone Bordet wrote:
>> Hi,
>>
>> On Wed, Sep 23, 2015 at 7:04 AM, Bradford Wetmore
>> <bradford.wetm...@oracle.com> wrote:
>>>
>>>> This new proposal still requires that ciphers are sorted in a way that
>>>> matches the ApplicationProtocol order.
>>>> Would be nice if, along with the HTTP/2 blacklist, there is a HTTP/2
>>>> comparator that sorts ciphers putting the blacklisted ones at the end.
>>>
>>> Hm...is the sample code at the end of the initial class description
>>> insufficient? Adding a comparator seems a little heavyweight in that it
>>> could require access to the ciphersuite internals and would add a lot of
>>> complexity for this one known use case. When TLSv1.3 is done, the
>>> blacklist
>>> stuff in HTTP/2 goes away.
>>
>> Sure, but until TLS 1.3 widely deployed, applications will have to
>> sort the ciphers to put HTTP/2 ones before the blacklisted ones.
>> Providing this comparator is as trivial as providing
>> ApplicationProtocol.HTTP2BLACKLIST, so I thought to mention it.
>
> I learned something today: Collections/Arrays.sort()/others are stable.
> (i.e. equal elements will not be reordered as a result of the sort) My
> expectation of "equals" was .equals(), not return value == 0.
>
> I was concerned that such a Comparator might reorder valid H2 suites
> from what was passed in. Thankfully, that's not the case, so I've added
> this Comparator. There is a warning now about "consistency with
> equals()", as the Strings obvioulsy won't be equals() and thus sorted
> sets/maps just won't work. (See the Comparator pages for further
> discussion.)
It might be not customers expected behavior to re-order/sort their
preference of cipher suites or preference.
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.
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.
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);
// 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.
We may need a handy tool for the sorting for stronger cipher suites.
But, AFAIU, the tool does not belong to ALPN.
Hope it helps.
Xuelei
