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 <[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]>> 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 > > >
