You guys (David/Simone/Bernd/Jason) are more on the front lines in
server development and how functional this API will be, so I'll trust
your judgement here. If you are ok with:
1. potentially being blind during renegotiations in the existing
TLSv1/v1.1/v1.2, and,
2. not having an SSLExplorer as part of the JDK (i.e. you parsing the
ClientHellos ala SSLExplorer),
3. requiring all ALPN logic be in the application and none in the JDK,
I'm willing to go with this approach. It doesn't seem optimal for what I
would call casual users, but it does solve the ugly issues with the
matches() API.
(BTW, I did consider adding a
ClientHelloCallback/ClientHello/ServerHelloCallback/ServerHello class
that would handle callbacks, but that was getting complicated also.)
For current renegotiations, the big use case is adding client
authentication, so it seems likely that the same ciphersuite will be
offered/chosen, so it's likely moot.
For the existing URL code, do you think we need:
1. to provide a "https.alpn" System Property for the existing
URLConnections?
2. a getApplicationProtocol() for HttpsURLConnection?
Michael (net-dev) says H2 will not be backported into the URL mechanism
and doesn't see a need for it yet, so I'm inclined to say no.
More inline:
On 9/29/2015 8:07 AM, David M. Lloyd wrote:
Hi Brad, thanks for replying; comments are inline:
On 09/28/2015 08:40 PM, Bradford Wetmore wrote:
1. Only the initial ClientHellos are parsable.
===============================================
The biggest problem I have with an Explorer-based design is that only
the initial ClientHello on a connection is passed in the clear.
Subsequent negotiations on this connection will be completely missed, as
the ClientHellos are now encrypted.
This seems like a deal breaker for me.
You are right, I cannot come up with a good solution for this, so that
might mean the idea is shot - *however* - I would point out that the
latest draft of TLS 1.3 [1] completely kills off the capability of the
client to renegotiate a connection, meaning that this will no longer be
possible anyway, and given it's a 1% kind of use case, that might be
enough to let it slide. Combine this with what I consider to be the
unlikelihood of this working with HTTP/2.0, and I would feel very safe
assuming that nobody will ever actually do this.
Thanks for pointing this out, I thought PSK+tickets were a replacement
for a renegotiation (Section 6.2.3), but it's apparently only for
session resumption.
BTW, the WG is up to a Sept 29, 2015 version (draft-09).
[1] https://tlswg.github.io/tls13-spec/
I would also note that, as you state later on, it would be possible to
combine this solution with any other solution (including the proposed
one) to cover both cases. And given that this is still (in my
estimation) a "99%" solution, in my opinion it is still a viable
candidate for adding this functionality to Java 8 as a first pass or
stopgap as I described in my emails, particularly if the method(s) to
establish/query the protocol names are a strict subset of the proposed
Java 9 API (given that we cannot really overhaul the Java SE 8 API at
this point).
[...]
2. "SSLExplorer" or something similar is needed.
=================================================
This approach depends on "examining SSLClientHello"s, but there isn't a
class for this other than some sample code from a previous attempt. I
am assuming that this approach would make such an external API a
necessity? Being able to parse possible ClientHello formats is not a
straightforward/easy job. This will add a fair amount of complexity,
and likely not an easy job in the remaining few weeks. It could be
added later for JDK 10 but that means apps would likely need to roll
their own for 9.
And 8, yes, you definitely would need to roll your own, though Xuelei
Fan already has a nice example up on his blog that was built for SNI
(but uses the same principle).
If you are referring to:
http://simsmi.blogspot.com/2014/01/jep-114-tls-sni-extension-virtual.html
This is just describing the general approach for the sample
SSLExplorer/SSLCapabilities code in the JSSE Reference Guide. The
actual code can be found here:
http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#CodeExamples
My hope is to expand it to include parsing the ciphersuites and ALPN
extensions. I've moved/added some helper functions from
ApplicationProtocol to StandardConstants.
If it were me, I wouldn't even bother
adding it even in JDK 10, since (a) it applies only to the server side
and (b) there are a plethora of third-party server-side network I/O and
security libraries which are natural candidates to host this type of logic.
Ok.
3. "no_application_protocol"
=============================
If the server doesn't support the protocols that the client advertises,
the "no_application_protocol" must be thrown. We could add a
"no_application_protocol" protocol String that would flag such a
condition internally.
Sure, though if you use the same method on both the client and server to
specify the matched protocol, then the method necessarily accepts an
array, in which case a null/unset could mean "no ALPN response" and an
empty array could mean "no acceptable protocols". But yeah I agree
otherwise.
I meant if this value is set, then when the ALPN extensions are
selected, it will send the alert to the peer and return an Exception to
the local code.
The latest webrev is at:
http://cr.openjdk.java.net/~wetmore/8051498/webrev.16
This will be the final version as far as major architectural design
goes, but minor things like parameter types/wording can still be tweaked.
Major changes:
1. ApplicationProtocols is gone. The H2 black list and comparator were
moved to StandardConstants.
2. StandardConstants. Strings for "h2" and "http/1.1" are back. And
now that you are parsing the raw network bytes, I added a convenience
mapping between the two byte ciphersuite IANA-assigned value and the
Java Standard Name.
3. SSLParameter (set/get) are moved to SSLSocket/SSLEngine. Even
though these could go into SSLParameters, this change makes backporting
much easier. The helper code simply has to reflectively look for the
four methods in the implementation classes, and call if they are there.
Otherwise, there would have to be reflection both in the user code
(above) and implementation (to see if the passed SSLParameters had the
new methods via a subclass).
Thanks,
Brad
