Hi Brad, thanks for replying; comments are inline: On 09/28/2015 08:40 PM, Bradford Wetmore wrote:
Several comments about David's proposal: 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.
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 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.
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.
4. Much of this is already possible. ===================================== If we were to go with the current API/internal and apps provided their own ClientHello scanner, many of the benefits of what was proposed are already available. Apps can ask for the desired SSLContext, get the SSLSocket/SSLengine, check the SNI/ALPN values, order/set the enabled protocols/ciphers/etc + single ALPN value, then wrap the raw socket using SSLSocketFactory.createSocket(Socket s, InputStream consumed, boolean autoClose), and start the handshake. The internal code would still call matches() but only once. If you want to be sure the internals select the ApplicationProtocol, just put in a permissive ApplicationProtocol. The API is still more complicated unfortunately as ApplicationProtocol is still present, but the overall behavior is quite similar.
+1 yep exactly. I would however turn it around and also say, a more complex API could later be added on top of this simpler proposed solution, especially after more real world data is acquired, which might lower the overall risk as well.
5. Other failure mode/fallback. ================================ In the new proposal, suppose you do set a single ALPN value in the application level, and the ServerHandshaker finds some other aspect of the handshake wasn't appropriate (creds were mentioned several times, but maybe a ciphersuite went dark due to new AlgorithmConstraints). This would cause the ServerHandshaker to fail and there's no way to go back to a different version unless you add a "for ALPN" loop into application.
Yeah all that validation would have to be done up front or manually in whatever server configuration is relevant. If a cipher suite suddenly stops working, in the very worst case, the administrator would have to manually reconfigure to exclude it.
6. "Only one new method on SSLSocket/SSLEngine to set the protocol list (client) or selected single protocol (server)" ============================================================== I think you would need two, "use this value on the next handshake" and "this was last negotiated/currently in effect."
Sure, whichever way works best. Thanks for the reply! [1] https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-1.2 -- - DML
