Hi Sean, do you think it would be good to check in a jtreg test that TLS_EMPTY_RENEGOTIATION_INFO_SCSV
Is always in the lists returned by ssf.getDefaultCipherSuites() and ssf.getSupportedCipherSuites() ? Best regards, Matthias > -----Original Message----- > From: Sean Mullan <sean.mul...@oracle.com> > Sent: Dienstag, 22. Januar 2019 22:57 > To: Langer, Christoph <christoph.lan...@sap.com>; Seán Coffey > <sean.cof...@oracle.com>; OpenJDK Dev list <security- > d...@openjdk.java.net> > Cc: Baesken, Matthias <matthias.baes...@sap.com> > Subject: Re: Shall TLS_EMPTY_RENEGOTIATION_INFO_SCSV really be > disabled via jdk.tls.disabledAlgorithms=...,NULL or is it an unwanted side > effect of JDK-8211883? > > 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/600d5c81aafee7e95fe07c3b9182f > 37741e2d0d8/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java > #L145 > >> > >> > >> [5] > >> > https://github.com/apache/tomcat70/blob/600d5c81aafee7e95fe07c3b9182f > 37741e2d0d8/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java > #L293 > >> > >> > >> [6] > >> > https://www.oracle.com/technetwork/java/javase/overview/tlsreadme2- > 176330.html > >> > >>
