Shall TLS_EMPTY_RENEGOTIATION_INFO_SCSV really be disabled via jdk.tls.disabledAlgorithms=...,NULL or is it an unwanted side effect of JDK-8211883?
christoph.langer at sap.com
Tue Jan 22 19:57:55 UTC 2019
Hi security experts,
one of our customers is running into an issue with a Tomcat application after JDK-8211883 . 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 , 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 , 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 . Since it is not present, the handshake is stopped by removing all ciphers .
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”
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the security-dev