JDK-8219568 extended master secret performance problems

[Daniel Jeliński]

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.

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.

Let me know if that makes sense now.
Thanks,
Daniel


pon., 8 kwi 2019 o 17:43 Xuelei Fan <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/20190408/e3d16afa/attachment.htm>