JDK-8219568 extended master secret performance problems

Daniel Jeliński djelinski1 at gmail.com
Tue Apr 9 20:04:23 UTC 2019


Hi Xuelei,
What's the verdict on allowing legacy resumption on server even when EMS is
enabled?

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?
Regards,
Daniel

pon., 8 kwi 2019 o 21:00 Xuelei Fan <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>> 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20190409/ab3182e5/attachment.htm>


More information about the security-dev mailing list