<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hi all,</div><div></div><div>Ever since upgrading to Java 8u161 we are running into performance problems that were caused by the implementation of extended master secret.</div><div><br></div><div>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?</div><div>allow = true -> proceed with abbreviated handshake</div><div>allow = false -> proceed with full handshake</div><div><br></div><div>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.<br></div><div><br></div><div>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?<br></div><div><br></div><div>Regards,</div><div>Daniel<br></div><br><div><br></div><div>[1] <a href="http://openjdk.5641.n7.nabble.com/Code-Review-Request-JDK-8148421-Extended-Master-Secret-TLS-extension-td311192.html">http://openjdk.5641.n7.nabble.com/Code-Review-Request-JDK-8148421-Extended-Master-Secret-TLS-extension-td311192.html</a></div><div>[2] <a href="https://bugs.openjdk.java.net/browse/JDK-8192045">https://bugs.openjdk.java.net/browse/JDK-8192045</a><br></div></div></div></div></div>