On 09/25/2015 12:13 PM, Simone Bordet wrote:
Hi,
On Fri, Sep 25, 2015 at 6:49 PM, David M. Lloyd <david.ll...@redhat.com> wrote:
A: receive raw SSL packet on Socket or SocketChannel
A: examine SSL ClientHello, extract SNI, ALPN, cipher suite info
This requires the application to write a TLS parser. This is currently
not necessary, nor provided.
It is already necessary to make many non-trivial SNI decisions. I don't
see ALPN as deserving higher treatment than SNI.
You think this could be provided via a JDK utility class ?
And if so, how can it be extended in the future when more TLS
Extensions are defined ?
I don't think it's necessary, no.
A: use whatever algorithm(s) you want to analyze SNI/ALPN/cipher suite info
The application must intersect the ciphers, application protocols...
perhaps again this can be done by some JDK utility class.
The point of the approach is that it is unlikely that any JDK-driven
logic will be adequate for all use cases. It's better to let the
application be a black box: ALPN+SNI+Ciphers -> app logic -> one ALPN
protocol, one SNI name, only valid ciphers.
A: either proxy the connection, or obtain or create the relevant SSLContext
from the desired provider
A: construct server-side SSLSocket/SSLEngine from SSLContext
A: setApplicationProtocol(H2)
A: setEnabledCipherSuites(only allowed suites in desired order)
A: start handshake
J: receive ClientHello (buffered from A)
J: verify SNI is matched, fail otherwise (as today)
J: verify ALPN is matched, fail otherwise (new)
There is a missing step here which is to verify the cipher
(trySetCipherSuite() logic).
The application protocol implementation chooses only valid cipher suites
for the protocol. Why would it choose one that is not valid,
considering that the protocol implementation itself is the only thing
that "knows" what is valid or not?
If that fails then we must try another application protocol.
We cannot just fail the connection.
How do we go from here to the top again to choose another protocol ?
J: send ServerHello (with the single, user-selected protocol)
...
This is very simple from the JDK perspective, and also much more flexible.
Well, I kinda like it, but I have strong reservations that it cannot
really "negotiate" the application protocol, meaning that if one
application protocol fails, try the next, and then the next and so
forth until one succeeds (or they all fail).
This validation should have happened before the JDK ever has a chance to
be involved.
--
- DML
