On 06/15/2016 07:36 AM, Simone Bordet wrote:
Hi,
On Wed, Jun 15, 2016 at 1:31 PM, David M. Lloyd <david.ll...@redhat.com> wrote:
The problem is that this is quite subjective. In my opinion the current
solution is both clean and precise:
1) Read the hello packet
2) Examine the protocols, host names, and cipher suites
3) Apply arbitrary user policy to select the enabled cipher suites and even
possibly the SSL context to use based on:
* The above information
* The supported cipher suites (for each SSL context, if multiple)
* The available host key types for each host and/or protocol
* Any user-driven factor that goes beyond *just* HTTP 2
Sure, that's the duplication of what the JDK does.
Change logic in the JDK, change logic above.
Sure, the JDK has the same logic but does it go beyond matching the key
type with the cipher suite? You can't avoid doing this in the user
handler AFAICT, so yes that duplication stands. What kind of change in
the JDK logic are you thinking of?
How do you avoid to run the application SNI logic twice, once by you,
and once by the JDK ?
You can't avoid it. But this is different logic: the user chooses which
host to use (and what SSL context, key, etc.) and the JDK simply
verifies that choice.
What if that SNI logic, provided by an external application, has side effects ?
Your bullets above are "precise" only under the assumption that those
bullets are exactly what the JDK does.
If it's not the case, then they're broken.
I understand for you is not a big deal to replicate the JDK logic and
keeping it up to date, and banning certain versions of your code to
run with certain versions of the JDK.
I hope you understand it's not the case for others; for example, we
don't control with what JDK versions people run Jetty.
If JDK 10 changes the logic, we will have to say: "Oh, sorry, you
cannot run Jetty 9 (the current version) with JDK 10".
And we won't be able to change the logic in Jetty 9, because we would
break previous JDKs.
We will be back to sniffing what JDK it is. Yuck.
No matter what the JDK does, it will not be able to encapsulate a completely
arbitrary user policy - certainly not precisely - during handshake, nor will
it be able to allow for the selection of different SSLContexts based on that
policy (let alone proxying the connection).
Can you detail a case ?
A very simple case: you have two completely different protocols
multiplexed on port 443. Each of these protocols has its own
SSLContext. You read the client hello and dispatch to the appropriate
downstream service based on protocol (and possibly other factors).
Another case is that you have a service running on a separate system.
If the protocol and/or host matches, the network connection is proxied
to the downstream system, otherwise it is handled locally.
The best that can be done in the
JDK, in my opinion, is to provide various utilities to simplify implementing
the above: a helpful SSL explorer style class, which includes mapping the
protocol and cipher suite list (which I believe we agree on) and perhaps
providing information about the key type(s) supported by each cipher suite,
so the user can compare this against the available key types.
Unfortunately this SSL Explorer class has not yet been provided.
If it was, it would be helpful. But I think it will just hit the same
problems I hit: logic duplication and running SNI twice.
Once you know what cipher suites are offered, and you have selected the
protocol, host, and enabled cipher suites, there isn't a great deal of
mystery left in the JDK: it simply carries out the negotiation that you
specified.
IFF your logic is the same as the JDK.
I don't want to check this every time a JDK release is made.
Why you enjoy doing this this check, it's a mystery to me :)
I agree with 1 and 2, at least in concept if not in specifics, but I think 3 is
a mistake:
if you've committed to an SSL context then it's already too late to make some
possibly important decisions, and SNI can play a factor here too.
We can make this easier but I think that trying to do this all inside of the
handshake process is going to cut off some important use cases.
Which use cases ?
Multiple SSLContext, network proxying.
BTW, the delay of handshaker.started=true would be irrelevant to the
TLS mechanism, it's just an implementation detail.
The information that needs to be reported in the ServerHello is only
needed when the ServerHello is being constructed.
Had the JDK implementation been written with a delayed
handshaker.started=true we would have the best of both worlds.
You could write your own solution, we could write our own.
Yours will have some restrictions, and so will ours (just different ones).
Fair enough.
--
- DML
