https://bz.apache.org/bugzilla/show_bug.cgi?id=64409
--- Comment #6 from Christopher Schultz <ch...@christopherschultz.net> --- (In reply to Md Mahir Asef Kabir from comment #5) > It shows in the installation documentation in RUNNING.txt file that, we need > to download a Java SE Runtime Environment (JRE), release version 8 or later > in order to run the application. > > Thing is, for JDK 8 TLS will be TLSv1.2. You can run Java 8 /or later/. But Tomcat must support vanilla Java 8 because of specification requirements. > According to this article here - > https://access.redhat.com/articles/2112261, TLSv1.2 is also not secure. False. There is an attack against TLSv1.2 in certain configurations. Oracle fixed this sometime in 2016 (I was unable to find the exact revision) by disabling the use of RSA-MD5 and ECDSA-MD5 signatures during TLS handshakes. If TLSv1.2 were universally and fatally broken since 2016, nobody would be using it. Instead, nearly 100% of the internet is using it [https://www.ssllabs.com/ssl-pulse/#chart-protocol-support]. > So I was wondering if that seems like a problem to you. A solution for that > would be to update the RUNNING.txt, to recommend users to run the > application in Java 11 or higher. While it may not be actually written in RUNNING.txt (or anywhere else, for that matter), the recommendation is *always* to run the latest version practical of *any* software. Finally, specifying SSLContext.getInstance("TLSv1.3") does not change the protocols that will be supported by the instance of SSLContext returned from that method: it only requires that the protocol requested is /one of/ the protocols supported by that instance. So requesting "TLSv1.3" will fail in many cases (e.g. < Java 11) and in Java 11 will *still support TLSv1.2*. The proper solution is to use the "sslEnabledProtocols" configuration setting which affects the /actual/ supported protocols which will be enabled. Users are responsible for protecting their own systems. We cannot make security decisions for them in ways that are opaque. It's *not* okay to simply disable everything and require the user to re-enable whatever they need. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
