Shall TLS_EMPTY_RENEGOTIATION_INFO_SCSV really be disabled via jdk.tls.disabledAlgorithms=...,NULL or is it an unwanted side effect of JDK-8211883?

[Sean Mullan]

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 
> 
>