Darn those Chicken/Eggs [1]!
Yes, you are correct. The steps for the current server code:
1. The ClientHello is parsed, and the SNI matcher callback is called.
It does not return which value was matched in the ServerHello, just
whether a SNI name was matched or not:
The "extension_data" field of this extension SHALL be
empty.
2. Begin generating the ServerHello, choose the Protocol Version.
3. Iterate through the list of client's ciphersuites and call the
Server's KeyManager (KM) callback until the KM returns key material we
can use. A return string selects the proposed ciphersuite.
So we currently don't know the selected ciphersuite until the KM has
been called (possibly multiple times).
If we choose the ALPN before the ciphersuite, the ciphersuite selection
may end up being inappropriate (HTTP/2 blacklist). If we choose the
ciphersuite first, then the ALPN value wasn't used to drive the
certificate selection.
Two suggestions in preferred order below.
In each of these cases, unfortunately there is currently no indication
of the proposed Ciphersuite, so we need to modify the behavior of
getHandshakeSession().getCipherSuite() to fill in the proposed
CipherSuite before the call to the KM. This seems ok with the current
wording, but we'd need to make that explicit. This value will change
for each ciphersuite/KM choice attempt.
Each suggestion below is followed by our previously proposed ALPN
callback to make the actual ALPN value selection:
1a. Add a parallel method to ExtendedSSLSession:
public List<String> getRequestedApplicationProtocolNames();
along with the previously proposed selected name:
public String getApplicationProtocol()
(I'll be changing these names. I'm open to suggestions).
When the KM is called, the TLS protocol (e.g. TLSv1.2) has already been
selected.
Both of the major selection parameters (protocol/proposed ciphersuite)
are now available, and applications have access to the ordered ALPN list
to see what the client's requested values were.
-or-
1b. Keep API as is, and make two callbacks. This first is an advisory
value, the TLS protocol version and proposed ciphersuite will be
available in getHandshakeSession(). The second callback sets the final
value that will be sent.
I think 1.a is my preference.
To answer some of the other questions.
On 5/25/2015 3:08 AM, Michael McMahon wrote:
2) The notion of client preference needs to be made explicit. This could
just be a matter
of javadoc given that List<String> is ordered. So, it could be
enough to say the same
order is used in the protocol.
Yes, I'll add that.
3) It's a shame that the RFC didn't mandate UTF8 encoded byte sequences
for the
protocol name, because it's theoretically possible that non UTF8
byte sequences
could get registered, but that's not a concern for HTTP/2 at least.
No. Not sure what we can do about that, short of going back to the
byte[] option. Given that IANA operates mainly in English, I would
expect the namespaces will probably be ASCII, but that is just conjecture.
> This would be possible, IIUC, using
> sslEngine.getHandshakeSession().getRequestedServerNames() in the
> ApplicationProtocolSelector implementation.
Yes.
> but I understand it's mentioned in RFC 7301.
Yes, see the last sentence section 1.
Brad
[1] https://www.youtube.com/watch?v=ixgf5SlvOB4&feature=youtu.be&t=27
