Actually a bug for this has just been filed by SAP:
https://bugs.openjdk.java.net/browse/JDK-8217579. Since it came in via
webbugs, it has been initially marked Confidential. We can probably just
use this bug. I'll copy in more details and open it up.
--Sean
On 1/22/19 4:46 PM, Sean Mullan wrote:
Hi Christoph,
Yes, this indeed looks like a bug. The jdk.tls.disabledAlgorithms
security property probably should not restrict suites that are not
negotiable like TLS_EMPTY_RENEGOTIATION_INFO_SCSV.
Please feel free to file a bug or else Sean Coffey or I can do that on
your behalf tomorrow. The information below should be enough details to
put in the bug.
Thanks,
Sean
On 1/22/19 2:57 PM, Langer, Christoph wrote:
Hi security experts,
one of our customers is running into an issue with a Tomcat
application after JDK-8211883 [1]. It seems that because of adding
NULL to jdk.tls.disabledAlgorithms, the pseudo cipher suite
TLS_EMPTY_RENEGOTIATION_INFO_SCSV is disabled. Seems like, according
to CipherSuite.java [2], it is considered a NULL cipher. The
tracing/reproducer shows that it’s definitely disabled via
jdk.tls.disabledAlgorithms=NULL.
However, with my limited knowledge of TLS and ciphersuites and
googling around, I understand that TLS_EMPTY_RENEGOTIATION_INFO_SCSV
is part of the RFC 5746 specification [3], which is still considered
secure and state of the art for renegotiation. Is that correct?
The effect now in the customer application is that the client sends
the SCSV and the Tomcat SSL Engine checks for the presence of the SCSV
cipher in the cipher suites [4]. Since it is not present, the
handshake is stopped by removing all ciphers [5].
I also understand the Oracle readme about the renegotiation topic,
that TLS_EMPTY_RENEGOTIATION_INFO_SCSV is a thing to have but not to
disable.
Please let me know, if you agree with my analysis. If so, could you
please file a bug or tell me to do so? Otherwise let me know what I’m
missing. The workaround for the customer is to remove the NULL entry
from jdk.tls.disabledAlgorithms for the time being. I guess that’s a
bit more secure than setting
“sun.security.ssl.allowUnsafeRenegotiation” 😉
Thanks
Christoph
[1] https://bugs.openjdk.java.net/browse/JDK-8211883
[2]
http://hg.openjdk.java.net/jdk/jdk/file/1ae823617395/src/java.base/share/classes/sun/security/ssl/CipherSuite.java#l312
[3] http://www.ietf.org/rfc/rfc5746.txt
[4]
https://github.com/apache/tomcat70/blob/600d5c81aafee7e95fe07c3b9182f37741e2d0d8/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java#L145
[5]
https://github.com/apache/tomcat70/blob/600d5c81aafee7e95fe07c3b9182f37741e2d0d8/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java#L293
[6]
https://www.oracle.com/technetwork/java/javase/overview/tlsreadme2-176330.html
