Hi Matthias, As I understand it, the problem is that you need to open a new connection to the same host on a different port, and reuse the TLS session that was established on the original port. Is that correct?
Normally I'd recommend creating a layered socket using SSLSocketFactory.html#createSocket(Socket,String,int,boolean) [1], but it's broken - the port parameter is unused, and the session is retrieved from cache using the port of the underlying socket. Still, it's much easier to fix this than to expose the TLS session cache. Regards, Daniel [1] https://docs.oracle.com/en/java/javase/17/docs/api/java.base/javax/net/ssl/SSLSocketFactory.html#createSocket(java.net.Socket,java.lang.String,int,boolean) śr., 9 sie 2023 o 08:10 Matthias Perktold - ASA <matthias.perkt...@asahotel.com> napisał(a): > > I would like to put some attention on JDK-8170813 "TLS session cache access". > > It has been open for almost seven years now, and there is still no good > solution. > > On the contrary, the workarounds provided in the linked issue from Apache > Commons NET are becoming more difficult with newer Java versions, as > reflective access is restricted more and more. > For the concrete workaround, see > https://issues.apache.org/jira/browse/NET-408?focusedCommentId=17316422&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17316422 > > First, the workarounds basically required "only" some reflection magic. > With JDK 8u161 or higher, the System property > "jdk.tls.useExtendedMasterSecret" must be set to false. > With JDK 11, you get a warning regarding illegal reflective access. > With JDK 14, the System "property > jdk.tls.client.enableSessionTicketExtension" must be set to false. > With JDK 17, that warning regarding illegal reflective access turns into an > error, unless is explicitely enabled via the --add-opens command line > parameter. > > I am not sure how the situation looks on newer JDK versions, but if anything, > it will only become more difficult. > > And by itself, making illegal access more difficult is a good thing. > But then we need to have a way to implement TLS session resumption in a clean > way without resorting to reflection hacks. > > Otherwise, at some point the only workaround left will be to not require TLS > session resumption on the FTP server. > And that is worse for security, and often not even under our control. > > Regards, > Matthias Perktold
