Hi Daniel,
Thanks for the quick feedback. It helps me a lot.
On 4/8/2019 9:59 AM, Daniel Jeliński wrote:
Hi Xuelei,
Thanks for your response!
My understanding is that legacy resumption = resumption of a session
that was established without extended master secret extension.
Our Java application is a web server that is communicating with a large
number of clients, majority of which are built on top of OpenSSL 1.0.2,
which does not implement extended master secret. The clients send data
to server using frequent short-lived connections.
When we use Java pre-8u161 or disable extended master secret
(/jdk/./tls/.useExtendedMasterSecret=false), the usual workflow is as
follows:
- client connects to server for the first time
- Full handshake happens, server creates a session ID and caches it
- session is established, data is transferred, connection is closed.
Later:
- subsequent client connection sends the cached session ID
- server resumes session using abbreviated handshake
- data is transferred, connection is closed.
The same workflow with extended master secret enabled is as follows:
- client connects to server for the first time
- Full handshake happens, server creates a session ID and caches it
- session is established, data is transferred, connection is closed.
Later:
- subsequent client connection sends the cached session ID
- server checks that the session ID was established without extended
master secret and rejects it. Full handshake happens, server creates a
session ID and caches it
- session is established, data is transferred, connection is closed.
It sounds like a reasonable use case if applications want to take the
risks. I will think more about if we can make an enhancement to allow
legacy resumption again if the extended master secret extension is not used.
Full handshake is much more expensive than abbreviated handshake, and
caching thousands of session IDs that are never reused creates a burden
on GC.
My understanding of RFC 7627 is that rejecting abbreviated handshake
when extended master secret is not used makes sense only when we are
using client certificates for authentication. We are not using client
certificates in our communication, so we would prefer to resume sessions
whether extended master secret is used or not.
TLS specification does not require the server to assign a session ID
when it knows it will not allow the client to resume session. We should
take advantage of that and not assign a session ID when the user does
not want to resume legacy sessions.
Good idea!
Thanks,
Xuelei
Let me know if that makes sense now.
Thanks,
Daniel
pon., 8 kwi 2019 o 17:43 Xuelei Fan <[email protected]
<mailto:[email protected]>> napisał(a):
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
