Ed, Vincent & Simone,
see response below.
On 11 October 2016 at 07:31, Edward Burns <edward.burns_at_oracle.com> wrote:
> 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.
>
> 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.
>
>
We do not believe this is generally true without re-implementing the
matching algorithms of SslEngine.
Of course it is possible to predict the matching done by SslEngine, but
essentially this requires the matching done by SslEngine to be
reimplemented. More over the matching done by SslEngine is extensible and
new algorithms, cyphers, extensions and providers can be plugged in
transparently to our usage. We would thus have to predict behaviour based
on an opaque implementation and full knowledge of the specific details of
the certificates in the keystore.
Furthermore, order to predict the SslEngine behaviour we would need to
implement the matching of certificate to cipher, so we would need to know
if a cipher is acceptable for a certificate and SNI matching. Even if
this was a easy task to do (and maintain) it would mean that those
algorithms would be invoked twice, wasting CPU, with different
implementations that would always be at risk of diverging, specially when
we move to Java10 and beyond.
Our proposed fix is extremely simple and avoids duplicate algorithms and
the need to predict anything. We propose that we simply allow SslEngine
to do the matching and update the acceptable ciphers after the match is
complete.
> Would this work? The sooner we get this nailed down, the sooner we can
> help define the API of the JDK 8 backport.
>
>
This is not really workable for us. We would not even attempt to predict
the SslEngine algorithms (and its pluggable providers). We would be forced
to use two SslEngine instance, one for the prediction and another for the
connection. This is wasteful for no good reason that we can see.
regards
--
Greg Wilkins <gregw@webtide.com> CTO http://webtide.com