On 6/4/19 10:02 AM, Xuelei Fan wrote:
On 6/4/2019 9:46 AM, Anthony Scarpino wrote:
125 if (secondSession.getCreationTime() > secondStartTime &&
126 !clientCache && !serverServerless) {
127 throw new RuntimeException("Session was not
reused");
128 }
If the session should be resumed via session ID, beside checking the
creation time, would it be better to compare the session IDs for
double-checking?
the client side in stateless mode sends no session id, as the spec
allows. So the session id has no more value.
I think it is a legacy problem introduced in the TLS 1.3 implementation.
Comparing creating time does not sound like a good idea to me. If I
remember correctly, we are trying to fix the problem in another RFE.
SSLSession.getId() returns the identifier assigned to this Session.
While for a session, it is normally refer to the session negotiated for
the full handshake. For resuming session, the identifier should be the
same. There are might be compatibility issues if we don't use session
id or use different session id for the resumed session.
Per RFC 5077, the full handshake uses a session ID, while resumption may
use a empty Session ID in the ServerHello. However, because of the
SSLSession.getId() spec, I would prefer to keep using it and use the
full handshake id for resumption.
Thanks,
Xuelei
An existing interop test, different from the test commented here, was
looking at session id's for tls 1.3 and failing before my changes. When
I made some changes to use the creation time, the test started working.
John's comment is added session id checking to this test. I'd rather
not add that because it was not their before, and it is not reliable.
If there is an RFE to change this all, that is fine. I'm just not going
to address it here.
Tony
