JDK-8219568 extended master secret performance problems

Xuelei Fan xuelei.fan at oracle.com
Tue Apr 9 21:43:16 UTC 2019


On 4/9/2019 1:04 PM, Daniel Jeliński wrote:
> Hi Xuelei,
> What's the verdict on allowing legacy resumption on server even when EMS 
> is enabled?
> 
If EMS is used, no legacy resumption any more. Otherwise, the problem of 
the legacy resumption comes.

> I was thinking of repurposing the current allowLegacyResumption flag for 
> this; its name looks appropriate. However, it would be a change of 
> behavior: currently we do not allow legacy resumption, and default value 
> of allowLegacyResumption is true; we would either need to change the 
> default, or change the default behavior. Would that be acceptable?
Currently, if no EMS, the behavior in server side may look like:
1. close the connection if allowLegacyResumption is false;
2. perform full handshake if allowLegacyResumption true;

Default allowLegacyResumption is true for compatibility reasons.

Does it sound reasonable to you?

Xuelei

> Regards,
> Daniel
> 
> pon., 8 kwi 2019 o 21:00 Xuelei Fan <xuelei.fan at oracle.com 
> <mailto:xuelei.fan at oracle.com>> napisał(a):
> 
>     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>
>      > <mailto: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