TLS ALPN Proposal v5
Simone Bordet
simone.bordet at gmail.com
Tue Sep 22 07:56:32 UTC 2015
Hi,
On Sat, Sep 19, 2015 at 7:15 AM, Bradford Wetmore
<bradford.wetmore at oracle.com> wrote:
> Here is the new webrev:
>
> http://cr.openjdk.java.net/~wetmore/8051498/webrev.12/
>
> Unless there are major objections, we need to get ALPN into JDK very soon to
> make JDK 9. We can still tweak the APIs if something is found later.
>
> Major changes:
>
> 1. ApplicationProtocols interface + H2 + HTTP/1.1 impls
>
> Both client/server call SSLParameters.setApplicationProtocols(List<>) to set
> their preferences.
>
> The matches method can be used for:
>
> . During server handshaking to determine an acceptable ALPN value.
>
> . potentially during client preparation to eliminate known bad
> ciphersuites/protocols combos. If you are going to only request TLSv1.1 and
> earlier, you can disable H2 because it won't match.
>
> In this second case, you may not have a SSLSocket/SSLEngine yet, but you
> still want to do the checks based on ciphersuite/protocol, so the second
> parameters can be null.
>
> 2. ApplicationProtocolSelector gone.
>
> 3. SSLParameters AP_HTTP_1_1/AP_H2 effectively moved to
> ApplicationProtocol. Selection logic added to ApplicationProtocol.
>
> 4. Moved ALPN values from SSLSession to SSLSocket/SSLSEngine. Added a
> "handshaking in progress" variant.
>
> 5. SSLSession.getPeerApplicationProtocols() and
> getHandshakeCipherSuiteList() are gone. These are all handled internally.
This new proposal still requires that ciphers are sorted in a way that
matches the ApplicationProtocol order.
Would be nice if, along with the HTTP/2 blacklist, there is a HTTP/2
comparator that sorts ciphers putting the blacklisted ones at the end.
I don't like the first parameter of ApplicationProtocol.match() to be
a Map<String, String>; I would prefer a full blown class at this
point, that contains all the parameters, for example:
inner class ApplicationProtocol.Info
{
tlsProtocol
cipher
sslEngine
sessionIsResuming
etc.
}
I also don't understand why there are 2 methods for the protocol name
? What value does it bring to have 2 methods for the same thing ?
I would just use:
class ApplicationProtocol
{
public String getName()
}
RFC 7301 hints that the bytes to send over the network are the UTF-8
bytes from that string.
There are still a lot of details missing, such as where is the chosen
ALPN value stored (and how it can be retrieved by the KeyManager, for
example), as well as the webrev not showing any real implementation,
and how exactly the ApplicationProtocol instances are called, etc.
For example, client sends ["h2"], server has ["http/1.1", "h2"]. Will
the instance of ApplicationProtocol corresponding to "http/1.1" be
invoked at all ?
If not, there is a missing step in your algorithm above, where the
implementation intersects the ALPN values from both peers.
Finally, I think this API may be suitable for the server, but not much
for the client, which is equally important.
I don't see how a client application can figure out what protocol has
been chosen by the server, because there is no final notification
about that and the API seems totally geared towards server "matching"
more than client notification. For me this is a blocker.
Can you please provide an example of how a client application would
use this new API to be notified that the server has chosen protocol
"foo" ?
I still remain convinced that - so far - the Jetty API proposal (or
the similar version that was proposed here 2-3 proposals ago) is
superior to the latest ones.
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