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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>
> <mailto:[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
>
