Hi Jeroen, Thanks for the report. The issue now is tracked as
https://bugs.openjdk.java.net/browse/JDK-8149017 Thanks, Xuelei On 2/10/2016 8:32 PM, Jeroen Cranendonk wrote: > Hi!____ > > __ __ > > This issue has already been reported under review ID: JI-9029195, but I > haven’t heard anything from it yet.____ > > So I thought I’d also try the mailing list. I would like to know at > least if my analysis is correct :)____ > > __ __ > > I’ve been investigating an issue we ran into after a Java update on one > of our products.____ > > I think it was introduced here:____ > > http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/fe1c420a8982 or > http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/3e9d6880f36f____ > > The latter is the same change, re-applied. JDK 7 and 9 have the same > change I think.____ > > This would be included in the JRE 'fix' #8081297: "Unable to process > PreMasterSecret Tomcat issue", first seen in Java SE 7u85 b34,____ > > __ __ > > I think the issue is caused in RSAClientKeyExchange, because of this > change:____ > > Cipher cipher = > JsseJce.getCipher(JsseJce.CIPHER_RSA_PKCS1);____ > > - cipher.init(Cipher.UNWRAP_MODE, privateKey,____ > > - new TlsRsaPremasterSecretParameterSpec(____ > > - maxVersion.v, currentVersion.v),____ > > - generator);____ > > - preMaster = (SecretKey)cipher.unwrap(encrypted,____ > > - "TlsRsaPremasterSecret", > Cipher.SECRET_KEY);____ > > + needFailover = !KeyUtil.isOracleJCEProvider(____ > > + > cipher.getProvider().getName());____ > > + if (needFailover) {____ > > + cipher.init(Cipher.DECRYPT_MODE, privateKey);____ > > __ __ > > If you condense it, this :____ > > Cipher cipher = JsseJce.getCipher(JsseJce.CIPHER_RSA_PKCS1);____ > > cipher.init(…);____ > > __ __ > > Has been changed to:____ > > Cipher cipher = JsseJce.getCipher(JsseJce.CIPHER_RSA_PKCS1);____ > > * cipher.getProvider();____* > > cipher.init(…);____ > > __ __ > > The problem is that calling getProvider, or any method on a Cipher > instance, forces it to skip the delayed provider selection which is > built into Cipher.____ > > __ __ > > For details on delayed provider selection see the source code of Cipher:____ > > http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/tip/src/share/classes/javax/crypto/Cipher.java____ > > Especially the chooseFirstProvider() method, which also has debug > logging for this specific case. (Using "-Djava.security.debug=jca" you > should get the message "Cipher: Cipher.init() not first method called").____ > > __ __ > > In many cases this won’t cause a problem, but when using a hardware > token based provider (e.g. PKCS11), this can cause SSL connections to > fail being set up, especially if it’s not the first provider in the list > of security providers. For my current customer this is a big problem, > because they use hardware tokens for everything :)____ > > __ __ > > For anyone not familiar with delayed provider selection:____ > > It means that when a Cipher instance is created, it doesn’t know yet > which provider it will be using, because we haven’t provided it with the > key it should use yet. Once we call it’s init method, with the key to > use, it is able to select a provider. It will try every available > provider implementing the selected algorithm, and will keep trying until > it find one which can use the key: It doesn’t throw a > InvalidKeyException.____ > > This is important for hardware based providers like PKCS11, because they > use key’s which are a handle to the key stored in hardware, and only > their own Cipher can handle this key.____ > > __ __ > > I would really like to know if my assessment is accurate. I would also > really like to know how to make sure this gets fixed in a timely manner > (I understand that the most optimistic ‘timely’ would be the next JRE > release, or the one after that) ;)____ > > __ __ > > I can readily provide more details, a self contained example is harder > because a hardware based provider is required :) > > > Thank you for your attention!____ > > > ____ > > Cheers,____ > > Jeroen Cranendonk > >
