JDK-8219568 extended master secret performance problems
Daniel Jeliński
djelinski1 at gmail.com
Sat Apr 6 18:36:16 UTC 2019
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20190406/e1578f41/attachment.htm>
More information about the security-dev
mailing list