Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-dev] State of HTTP/2 in 9.3.0-SNAPSHOT
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>
Expert advice, services and support from from the Jetty & CometD experts

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

Back to the top