Re: [jetty-dev] State of HTTP/2 in 9.3.0-SNAPSHOT

[Eirik Bjørsnøs <eirbjo@xxxxxxxxx>]

Joakim,

My questions are more of the "is it supposed to work this way?" type,
rather than "I can't get it to work".

Answering your specific questions:

Yes, I'm using Java 8:

$ java -version
java version "1.8.0_40"

I'm using the new ExtendedSslContextFactory, so my code wouldn't run
on Java 7. I've also installed the JCE Unlimited Strength policy files
to support AES256 ciphers.

I'm embedding Jetty, so not using alpn.protocols directly:

ALPNServerConnectionFactory alpn = new
ALPNServerConnectionFactory("h2", "h2-14", "http/1.1");
alpn.setDefaultProtocol("http/1.1");

Eirik.

On Fri, Apr 3, 2015 at 4:42 AM, Joakim Erdfelt <joakim@xxxxxxxxxxx> wrote:
> Lets ask the obvious questions first.
>
> Are you using Java 8? (its pretty much required for HTTP/2 ciphers)
> Also, you might want to verify your alpn.protocols list.
>
> See https://dev.eclipse.org/mhonarc/lists/jetty-users/msg05659.html
>
>
> --
> Joakim Erdfelt <joakim@xxxxxxxxxxx>
> webtide.com - intalio.com/jetty
> Expert advice, services and support from from the Jetty & CometD experts
> eclipse.org/jetty - cometd.org
>
> On Thu, Apr 2, 2015 at 3:17 PM, Eirik Bjørsnøs <eirbjo@xxxxxxxxx> wrote:
>>
>> While testing the SNI support implemented for #430951 [1] in my proxy
>> server, I noticed that Chrome would no longer connect using HTTP/2.
>>
>> Debugging showed that HTTP2ServerConnectionFactory.isAcceptable returned
>> false.
>>
>> Analysis led to these four questions:
>>
>> First, I noticed that "TLSv1.2" is in the list of blacklisted
>> protocols, so isBlackListProtocol returns true. Spec says
>> "Implementations of HTTP/2 MUST use TLS [TLS12] version 1.2 or higher
>> for HTTP/2 over TLS." [2]
>>
>> Question #1: Is this a bug? Should TLSv1.2 really be on the protocol black
>> list?
>>
>> Second, I noticed that the cipher negotiated with Chrome was on the
>> cipher black list. I added that to the list of excluded ciphers in
>> SslContextFactory. That only lead to another cipher being negotiated,
>> which was also black listed. I ended up setting
>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the only included cipher,
>> since that was mentioned in the spec as not on the black list. With
>> this change, HTTP/2 worked again.
>>
>> Question #2: What is the recommended list of included / excluded
>> ciphers for use with HTTP/2? Should all black listed ciphers be
>> excluded, or is it easier (and more secure?) to use a white list by
>> only including known working ciphers?
>>
>> Third, HTTP2ServerConnectionFactory.isAcceptable currently returns
>> true if the TLS protocol is not black listed, if the cipher is not
>> black listed, or if both the TLS protocol and ciphers are not black
>> listed. (It only returns false if both are black listed)
>>
>> Question #3: Does this logic make sense? Shouldn't this method return
>> true iff neither the protocol or cipher is black listed? In other
>> words, shouldn't the || be an && instead?
>>
>> Fourth: The black listing in HTTP seems to be added in h2-16 [3], yet
>> the black list in Jetty is in effect also for Chrome supporting only
>> h2-14.
>>
>> Question #4: Should Jetty enforce the cipher black list for h2-14 clients?
>>
>> Thanks,
>> Eirik.
>>
>> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=430951
>> [2] https://http2.github.io/http2-spec/#TLSUsage
>> [3]
>> https://http2.github.io/http2-spec/#changes.since.draft-ietf-httpbis-http2-15
>> _______________________________________________
>> jetty-dev mailing list
>> jetty-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>
>
>
> _______________________________________________
> jetty-dev mailing list
> jetty-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/jetty-dev