Hi Sean,

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.

Regards,

Jonathan Patchell
Senior Software Developer
Gemalto

From: Seán Coffey [mailto:sean.cof...@oracle.com]
Sent: February-08-17 8:21 AM
To: Gardiner Michael <michael.gardi...@gemalto.com>; Patchell Jonathan 
<jonathan.patch...@gemalto.com>; security-dev@openjdk.java.net
Subject: Re: TlsRsaPremasterSecretParameterSpec


What version of JDK 8u are you running with ? There's been a few tweaks in this 
code area which might help you.

https://bugs.openjdk.java.net/browse/JDK-8149017
https://bugs.openjdk.java.net/browse/JDK-8158111

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.

Regards,

Sean.
On 07/02/17 21:29, Gardiner Michael wrote:
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.

Regards,

Mike Gardiner
Systems Security Architect
Gemalto

________________________________
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.

Reply via email to