On 6/3/2019 5:42 PM, Anthony Scarpino wrote:
http://cr.openjdk.java.net/~ascarpino/stateless/webrev.02
----------
381 if (chc.localSupportedSignAlgs == null) {
382 chc.localSupportedSignAlgs =
383 SignatureScheme.getSupportedAlgorithms(
384 chc.algorithmConstraints,
chc.activeProtocols);
385 }
386
387 // Make sure the list of supported signature
algorithms matches
388 Collection<SignatureScheme> sessionSigAlgs =
389 chc.resumingSession.getLocalSupportedSignatureSchemes();
390 if
(!chc.localSupportedSignAlgs.containsAll(sessionSigAlgs)) {
391 if (SSLLogger.isOn &&
SSLLogger.isOn("ssl,handshake")) {
392 SSLLogger.fine("Existing session uses
different " +
393 "signature algorithms");
394 }
395 return null;
396 }
I did not get the idea here. Does the session signature algorithms
impact the use of session ticket extension?
This was something I got from the 1.3 CHPreSharedKeyProducer.produce().
I can remove it, should I remove it from PSK as well?
I did not get the idea of the similar code in
CHPreSharedKeyProducer.produce() either. I'm fine if you want to remove
the block as well.
----------
426 // If no buffer or we are already using stateless
resumption
427 if (buffer == null || shc.statelessResumption) {
428 return;
429 }
I did not follow the idea of the checking. I think the buffer should
never be null. For the 'shc.statelessResumption', as this method is to
parse the session ticket in the ClientHello handshake message, there
might be no chance to set the shc.statelessResumption yet for initial
handshaking.
The ST extension runs twice. The CH consumer has resumption checking
before the extensions are consumed normally from getEnabledExtensions().
I wasn't able figure out how to remove ST from the consumption list,
so I used shc.statelessResumption. If shc.statelessResumption is set,
it skips the consumption. Because I already have the boolean, I used it
for this purpose.
I see where you were from now.
It is similar to provider_versions extension in ClientHello. Maybe, you
can use a similar block (at line 1077-1078?) as the one in
ClientHello.java, by exclude the ST extension for TLS 1.2:
1166 extTypes = shc.sslConfig.getExclusiveExtensions(
1167 SSLHandshake.CLIENT_HELLO,
1168 Arrays.asList(
1169 SSLExtension.PSK_KEY_EXCHANGE_MODES,
1170 SSLExtension.CH_PRE_SHARED_KEY,
1171 SSLExtension.CH_SUPPORTED_VERSIONS));
1172 clientHello.extensions.consumeOnLoad(shc, extTypes);
----------
509 // Skip if extension is not provided
510 if (!hc.sslConfig.isAvailable(SH_SESSION_TICKET)) {
511 return;
512 }
If the extension is not provided, but receive the NST handshake
message from server, is it expected to terminate the connection with
an unexpected_message" alert?
if shc.statelessResumption is false NST is not added as a consumer.
shc.statelessResumption is true when both sides sent their ST in the CH
& SH.
So, do you mean will the return value of
"hc.sslConfig.isAvailable(SH_SESSION_TICKET)" is always 'true'? If this
code block (510-512) is just for assurance, as if it is checked here, I
may just send back an alert. Silently dispose the extension does not
sound like a good logic here, although it should never happens as you
have already checked everything.
----------
514 // If the context does not allow stateless tickets,
exit
515 if (!((SSLSessionContextImpl)hc.sslContext.
516 engineGetClientSessionContext()).statelessEnabled()) {
517 return;
518 }
Similar to above comment.
----------
What's client behavior if the server response with ST in ServerHello,
but does not send the NewSessionTicket handshake message?
Then no ticket is stored and the next session is a full handshake.
Did we need the HandshakeAbsence handler for NewSessionTicket
handshake message?
I don't believe so.
If I read correctly, the NewSessionTicket is not an optional handshake
message. If the server sent the ST extension in ServerHello, the
NewSessionTicket must be present.
Besides the NewSessionTicket handshake message, there are also some
other server behavior changes. For example, the server may use empty
session ID in the SH message. These changes may lead to issues we are
not aware of yet. For safe, I would suggest to make sure the
NewSessionTicket is present as if ST is present in SH.
Xuelei
