Hi Sean, to me this looks fine. +1
The test should be really valuable in the future. Thanks & Best regards Christoph > -----Original Message----- > From: security-dev <[email protected]> On Behalf Of > Sean Mullan > Sent: Montag, 28. Januar 2019 22:25 > To: [email protected] > Subject: Re: 8217579: TLS_EMPTY_RENEGOTIATION_INFO_SCSV is gone after > 8211883 > > Updated webrev: > http://cr.openjdk.java.net/~mullan/webrevs/8217579/webrev.01/ > > Comments inline ... > > On 1/28/19 2:54 PM, Bernd Eckenfels wrote: > > Hello Sean, > > > > Maybe you also want to change comment and name of the > SUPPORTE_DDEFAULT > > Array to „SUPPORTED_LIMITED“ since Unlimited is now Default? > > > > private final static String[] ENABLED_DEFAULT > > > > …. > > > > // supported ciphersuites using default JCE policy jurisdiction files > > > > // AES/256 unavailable > > > > private final static String[] SUPPORTED_DEFAULT = { > > > > 230 – remove „Default > > Good point. I have renamed the *_UNLIMITED constants to *_DEFAULT and > renamed the *_DEFAULT constants to *_LIMITED. > > > Is the test already run with all available policies? With the new System > > property it should be easy to run it with other/vm twice? > > Good point. I have changed the test to use the crypto.policy security > property to test the suites with the default and limited policies. > > > Is Oracle considering pushing a emergency public update for this? > > We are planning to backport it to all affected releases. > > > The change Looks otherwise fine (I was first wondering if checking for a > > _SVCS Family makes more sense but I guess that can be done once we > have > > more of those ciphers. > > Ok, thanks for the review. > > --Sean > > > > > Gruss > > > > Bernd > > > > -- > > http://bernd.eckenfels.net > > > > *Von: *Sean Mullan <mailto:[email protected]> > > *Gesendet: *Montag, 28. Januar 2019 20:26 > > *An: *security Dev OpenJDK <mailto:[email protected]> > > *Betreff: *RFR: 8217579: TLS_EMPTY_RENEGOTIATION_INFO_SCSV is gone > after > > 8211883 > > > > This fixes a regression introduced by the recent change to disable the > > > > TLS NULL cipher suites [1]. This accidentally also disabled the > > > > TLS_EMPTY_RENEGOTIATION_INFO_SCSV cipher suite because when the > name is > > > > decomposed by the algorithm constraints checking code it has NULL for > > > > its different parts (key exchange, etc). But this cipher suite is not > > > > negotiable and is only used for renegotiation purposes as defined in RFC > > > > 5746. It should not have been disabled. > > > > I also resurrected the CheckCipherSuites test which had an @ignore label > > > > on it. This is a good test because it checks what the expected > > > > enabled/supported suites should be, and will help catch issues like this > > > > in the future. > > > > webrev: > http://cr.openjdk.java.net/~mullan/webrevs/8217579/webrev.00/ > > > > bug: https://bugs.openjdk.java.net/browse/JDK-8217579 > > > > Thanks, > > > > Sean > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8211883 > >
