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]

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