JDK-8219568 extended master secret performance problems

Xuelei Fan xuelei.fan at oracle.com
Mon Apr 8 19:00:00 UTC 2019


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 <xuelei.fan at oracle.com 
> <mailto:xuelei.fan at oracle.com>> 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
> 



More information about the security-dev mailing list