EB> Executive Summary: I'm working with the JDK team to get this
EB> resolvedusing the approach suggested by Greg: 1st make the Java SE 9
EB> approach work better, then see about exposing the feature in a JDK 8
EB> vehicle.
[...]
EB> Greg, can you please send a link to the JavaDocs you've been using
EB> to understand the latest state of the API?
I still would like to see this link. Is it just
<
http://download.java.net/java/jdk9/docs/api/javax/net/ssl/SSLEngine.html>?
[...]
GW> But ALPN/HTTP2 require us to consider the negotiated cipher when
GW> selecting a protocol. It may be that whilst h2 is on offer and
GW> acceptable, the SNI caused a particular certificate to be used that
GW> forced a cipher selection that was unacceptable to h2, and thus
GW> http1 needs to be selected.
GW> So in order to make the protocol selection, we need to know the
GW> selected cipher. But the problem is that with the current SslEngine
GW> implementation, if you allow it to select a cipher (by unwrapping
GW> the hello), then it is too late to set your protocol selection.
[...]
GW> The real solution is for Oracle to start listening and to make a
GW> small patch to SslEngine to allow the protocol to be change up until
GW> the Hello response is wrapped. Only then can we fully implement the
GW> h2 requirements to select a protocol considering which cipher is
GW> negotiated.
GW> Once we have that logic settled for 9, we can then see what we can
GW> do to implement in 8 - replacing our current partial solution.
SD> My question was basically why do you need to discard the first
SD> SslEngine if it comes up with an acceptable protocol+cipher combo
SD> (which should be the case the majority of the time).
GW> Sure, you can make a pretty good educated guess that the cipher will
GW> be h2 acceptable and set that on the SslEngine before doing the
GW> unwrap. If the selected cipher is indeed acceptable, then you can
GW> proceed with that SslEngine.
GW> But the edge case still exi ts where the negotiated cipher will not
GW> be h2 acceptable, so in that case the only current option is to
GW> discard the SslEngine and replay the hello to a new one.
EB> Is this edge case entirely due to the "TLS 1.2 Cipher Suite Black
EB> List" provision in HTTP/2 RFC 7540?
Ok, I've been working this with Vincent Ryan in the JDK team. If you
have a more efficient and responsive communication channel with him than
me, I don't insist on being the middle man. In any case, Vincent Ryan
asserts Greg's edge case can be addressed to reduce the set of candidate
cipher suites to the point where you can guarantee success, which is
much better than the educated guess approach:
VR> If the ClientHello advertises h2 and the server supports h2 then the
VR> set of cipher suites should be trimmed to only the ones that are
VR> acceptable for h2. In addition, by examining the SNI and the
VR> server's keystore it should be possible to predict which
VR> certificate, and therefore which key type, will be matched by
VR> SSLEngine. This should be used to further reduce the set of
VR> acceptable cipher suites. Finally the ServerHello should be started
VR> with those parameters that are known to be acceptable. There should
VR> be no need to extract which cipher suite was selected by SSLEngine
VR> during the handshake and no need make an adjustment to the
VR> application protocol setting.
Would this work? The sooner we get this nailed down, the sooner we can
help define the API of the JDK 8 backport.
Thanks,
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017