Shall TLS_EMPTY_RENEGOTIATION_INFO_SCSV really be disabled via jdk.tls.disabledAlgorithms=...,NULL or is it an unwanted side effect of JDK-8211883?
Baesken, Matthias
matthias.baesken at sap.com
Wed Jan 23 07:47:18 UTC 2019
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.mullan at oracle.com>
> Sent: Dienstag, 22. Januar 2019 22:57
> To: Langer, Christoph <christoph.langer at sap.com>; Seán Coffey
> <sean.coffey at oracle.com>; OpenJDK Dev list <security-
> dev at openjdk.java.net>
> Cc: Baesken, Matthias <matthias.baesken at 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
> >>
> >>
More information about the security-dev
mailing list