Hi Daniel,
Was extended master secret extension used when legacy resumption is
expected? I did not get the point from JDK-8219568 and this
description. It would be helpful if there is a test code to reproduce
the behavior.
Thanks,
Xuelei
On 4/6/2019 11:36 AM, Daniel Jeliński wrote:
Hi all,
Ever since upgrading to Java 8u161 we are running into performance
problems that were caused by the implementation of extended master secret.
First problem was described in 8219568; server does not allow resuming
legacy sessions even when jdk.tls.allowLegacyResumption is set to true.
Based on the mail archives of the original discussion [1] and the
release notes [2] I think this was not what was intended. Should the
setting (jdk.tls.allowLegacyResumption) on the server side work like
this instead?
allow = true -> proceed with abbreviated handshake
allow = false -> proceed with full handshake
Documentation is ambiguous enough that we would probably not even need
to change it. Today it states that setting allowLegacyResumption to
false rejects abbreviated handshakes, without clarifying what the
default does.
Second problem is that while the server rejects the abbreviated
handshake, it generates and caches a new session ID on every client
reconnect, effectively thrashing the session cache. These IDs are never
used. Should we stop generating session IDs when legacy resumption is
disabled?
Regards,
Daniel
[1]
http://openjdk.5641.n7.nabble.com/Code-Review-Request-JDK-8148421-Extended-Master-Secret-TLS-extension-td311192.html
[2] https://bugs.openjdk.java.net/browse/JDK-8192045
