Hello Java Security Developers
We had a discussion a year and a bit ago about the TlsRsaPremasterSecretParameterSpec being used in a way that doesn’t seem to make sense. I’ve attached the email from 2015, but the same question has arisen.
It seems that the JSSE is expecting RSA Ciphers to be able to handle TlsRsaPremasterSecretParameterSpec. Is the TlsRsaPremasterSecretParameterSpec class going to move out of the status of “@deprecated Sun JDK internal use only --- WILL BE REMOVED in a future release” towards something that will be expected of RSA cipher instances to interoperate with the JSSE?
This is a blocking issue currently with at least one large customer. We could add some code in our provider to inspect if the parameter spec sent is of the offending type, but I’d really rather not have to handle a deprecated class that was never intended to be used outside of the Sun code base.
My current advice to this customer is:
1. Roll back to a previous version of Java that’s not affected by this behaviour change
2. Ensure the use of PFS cipher suites so the RSA key is used only for identity and not key exchange
But both of those pieces of advice may not be practical in their situation.
Systems Security Architect
Thanks for reporting this issue to us. We have a fix that we are testing
which should address the issue and revert back to the old behavior.
Would your company be willing to become a CAP member and help test this
fix and give use more confidence it will address the issue before it
goes to production? Here is some more information on the CAP program:
I have also copied Ingrid Yao who leads the program and can help answer
any more questions.
Again, thanks for reporting the issue and we hope to get a fix out for
On 09/08/2015 04:48 PM, Gardiner, Mike wrote:
> Hello all,
> This recently came up with a customer of ours and I wanted to get some
> answers from the horse’s mouth if I could. ;)
> I work for SafeNet (Now Gemalto) and we provide a JCA/JCE provider to
> use our Luna brand of HSMs. We recommend using our provider rather than
> the PKCS11 wrapper/provider as we take advantage of custom extension
> functions and take care to avoid usage which is not allowed in our
> modules (EG: no private/secret key may transit the FIPS boundary in the
> We don’t provide our own JSSE implementation and instead have
> historically relied on the Sun/IBM implementation to properly use the
> java provider list. There are always little gotchas that pop up but
> it’s generally resolved through configuration changes.
> The changes to RSAClientKeyExchange in regards to requiring the RSA
> Cipher to support TlsRsaPremasterSecretParameterSpec have thrown us for
> a bit of a loop though. Given that we support multiple JVMs I really
> don’t want to start handling parameter spec objects from the sun
> namespace. Especially when marked “@deprecated Sun JDK internal use
> only --- WILL BE REMOVED in a future release.” ;)
> Is there any chance this parameter spec would be moved to be more
> official? Or to go back to the old behaviour if the RSA Cipher instance
> doesn’t support it? (We throw an InvalidAlgorithmParameterException
> when given an unsupported parameter spec)
> The information contained in this electronic mail transmission
> may be privileged and confidential, and therefore, protected
> from disclosure. If you have received this communication in
> error, please notify us immediately by replying to this
> message and deleting it from your computer without copying
> or disclosing it.
smime.p7s (9K) Download Attachment
What version of JDK 8u are you running with ? There's been a few
tweaks in this code area which might help you.
If you can reproduce with 8u121, please log an issue via
http://bugreport.java.com/ (or JBS if you have an account) - We
need to be aware of such issues.
On 07/02/17 21:29, Gardiner Michael wrote:
I am using 8u121 and I have raised a bug at http://bugreport.java.com/. I haven’t received any response but the internal review ID was: 9047607.
Senior Software Developer
What version of JDK 8u are you running with ? There's been a few tweaks in this code area which might help you.
If you can reproduce with 8u121, please log an issue via http://bugreport.java.com/ (or JBS if you have an account) - We need to be aware of such issues.
On 07/02/17 21:29, Gardiner Michael wrote:
This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.
Thanks Jonathan. This is now tracked as https://bugs.openjdk.java.net/browse/JDK-8174690
We hope to triage this bug and keep updates in the bug report (including proposed fix version goals). You can also contact Oracle support if necessary.
On 09/02/2017 21:14, Patchell Jonathan wrote:
|Free forum by Nabble||Edit this page|