JDK-8170813 TLS session cache access

[Daniel Jeliński]

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.perktold at 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