TLS ALPN Proposal v5
Simone Bordet
simone.bordet at gmail.com
Fri Sep 25 17:13:53 UTC 2015
Hi,
On Fri, Sep 25, 2015 at 6:49 PM, David M. Lloyd <david.lloyd at 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.
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 ?
> 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.
> 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).
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).
Thanks !
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
More information about the security-dev
mailing list