TLS ALPN Proposal v2
Simone Bordet
simone.bordet at gmail.com
Thu Jun 4 12:11:05 UTC 2015
Hi,
On Wed, Jun 3, 2015 at 2:56 AM, Bradford Wetmore
<bradford.wetmore at oracle.com> wrote:
> Hi,
>
> I have just posted the second iteration of the ALPN proposal which hopefully
> addresses all of the comments raised here. It is in javadoc format, but
> things can certainly be adjusted:
>
> http://cr.openjdk.java.net/~wetmore/8051498/webrev.00/
>
> Please see the archive [1] for previous design discussion. I will be
> writing up usage examples in the next few days.
>
> The significant changes:
>
> ExtendedSSLSession
> public List<String> getReceivedApplicationProtocols() {
>
> This will allow applications to examine which protocol names were
> sent.
This is a constant once the application protocols are received, so it
can be surely retrieved from SSLParameters.
I don't understand why it is replicated here ?
> SSLParameters
> mentions both ALPN/NPN as possible protocols. I removed the
> discussion about "server" and "client" since ALPN/NPN essentially
> reverse the roles.
>
> mentions "appropriate character sets" for String-byte[] conversions
> such as UTF-8 for ALPN.
>
> The application protocol selector is now a @FunctionalInterface
> (i.e. lambda-ready) called SSLFunction. It is to throw an
> SSLException if no values are supported, or null if you want to
> treat as an unknown extension.
>
> Defined constants for HTTP/1.1 and HTTP/2.
>
> SSLSession
>
> Called out that getHandshakeSession's ciphersuite may vary until
> selected.
>
> SSLBase
>
> A new marker interface that SSLEngine/SSLSocket will implement.
> This will allow for a single SSLFunction instead of having
> SSLFunctionSSLEngine and SSLFunctionSSLSocket. It does require
> that the lambda do a instanceof, unless we were to move the common
> Socket/Engine APIs into this class.
I'm not sure about this one being a marker interface.
I could understand if it extracted the common functionality of
SSLEngine and SSLSocket, but a marker interface does not really add
much, and perhaps I would prefer it entirely gone.
On the same note, why is SSLFunction generic at all ?
Also, it is critical to detail how the mechanism work.
Will SSLFunction be invoked multiple times, or only once ? When,
exactly, with respect to cipher selection and alias selection ?
Example implementations for SSLFunction would be great to have: the
typical HTTP/2 case is to select the application protocol based on the
TLS protocol and the already negotiated cipher.
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