[9] RFR 8056026 Debug security logging should print Provider used for each crypto operation

[Vincent Ryan]

On 17 Sep 2014, at 16:00, Seán Coffey <sean.coffey at oracle.com> wrote:

> Thanks for tackling this one Vinnie. It'll certainly help better debug environments
> where several providers are available to perform similar crypto operations.
> 
> One minor suggestion might be to use a simple boolean to control whether
> the engine provider info gets printed.
> 
> i.e. change "private static final boolean skipDebug = Debug.isOn("engine=") && !Debug.isOn(“XXX”);"
> to "private static final boolean printProviderEngine = 
>           pdebug != null && Debug.isOn("engine=") && Debug.isOn(“XXX”);

This requires an engine to be explicitly listed in order to get traced.
I’d also like to support tracing for 'java.security.debug=all' and 'java.security.debug=provider'.


> 
> Might read better but minor like I say.
> 
> regards,
> Sean.
> 
> On 17/09/14 11:33, Vincent Ryan wrote:
>> I’ve renamed that boolean flag and inverted its logic:
>> 
>> -    private static final boolean doDebug = !(Debug.isOn("engine=") && !Debug.isOn(“XXX"));
>> +    private static final boolean skipDebug = Debug.isOn("engine=") && !Debug.isOn(“XXX”);
>> 
>> 
>> Updated webrev: http://cr.openjdk.java.net/~vinnie/8056026/webrev.02/
>> 
>> Docs bug: https://bugs.openjdk.java.net/browse/JDK-8058624
>> 
>> 
>> On 16 Sep 2014, at 22:07, Sean Mullan <sean.mullan at oracle.com> wrote:
>> 
>>> On 09/16/2014 11:27 AM, Vincent Ryan wrote:
>>>> Here's an updated webrev that supports including/excluding specific
>>>> JCA engines:
>>>> 
>>>> Webrev: http://cr.openjdk.java.net/~vinnie/8056026/webrev.01/
>>> 
>>> Looks good, although the doDebug boolean is making my head spin, is there an easier way to specify that?
>>> 
>>> Also, can you open a corresponding docs bug to update the troubleshooting guide: http://docs.oracle.com/javase/8/docs/technotes/guides/security/troubleshooting-security.html
>>> 
>>> --Sean
>>> 
>>>> 
>>>> 
>>>> For example, use the following to trace only MessageDigest and
>>>> Signature engines:
>>>> 
>>>>     -Djava.security.debug=provider:engine=MessageDigest,Signature
>>>> 
>>>> and use the following to trace all supported engines:
>>>> 
>>>>     -Djava.security.debug=provider
>>>> or
>>>>     -Djava.security.debug=all
>>>> 
>>>> 
>>>> 
>>>> On 15/09/2014 16:57, Vincent Ryan wrote:
>>>>> 
>>>>> On 15 Sep 2014, at 16:50, Sean Mullan <sean.mullan at oracle.com> wrote:
>>>>> 
>>>>>> On 09/15/2014 11:34 AM, Vincent Ryan wrote:
>>>>>>> Originally I did support tracing for MessageDigest but removed it
>>>>>>> because of the huge quantity of log messages that were generated.
>>>>>>> Hashes are very widely used before an application even starts.
>>>>>>> SecureRandom is similar.
>>>>>> 
>>>>>> Hmm, it would be nice to specify the engine classes you want to see.
>>>>>> Maybe that's too much work right now, but something like:
>>>>>> 
>>>>>> java -Djava.security.debug="provider engine=MessageDigest,Signature" …
>>>>> 
>>>>> We can log the JCE provider for all engine classes by default and also
>>>>> support a filtering mechanism using the ‘engine' sub-option as you
>>>>> suggest above.
>>>>> 
>>>>> 
>>>>>> 
>>>>>>> Also I omitted KeyStore log messages because there is usually only a
>>>>>>> single implementation for a given keystore type so the
>>>>>>> JCE provider which has been selected is obvious. I’ll add support
>>>>>>> for KeyStore.
>>>>>> 
>>>>>> Ok. I think it would be primarily useful to see the KeyStore when
>>>>>> PKCS11 is used with unextractable keys to help debug any subsequent
>>>>>> delayed provider selection.
>>>>>> 
>>>>>> --Sean
>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On 15 Sep 2014, at 16:12, Sean Mullan <sean.mullan at oracle.com> wrote:
>>>>>>> 
>>>>>>>> Can you also add similar log messages for MessageDigest,
>>>>>>>> SecureRandom, and KeyStore?
>>>>>>>> 
>>>>>>>> Otherwise looks good. Please add a noreg label. Also the fix is
>>>>>>>> helpful to any platform and not just solaris/sparc so you should
>>>>>>>> change those fields to be generic.
>>>>>>>> 
>>>>>>>> --Sean
>>>>>>>> 
>>>>>>>> On 09/12/2014 11:11 AM, Vincent Ryan wrote:
>>>>>>>>> 
>>>>>>>>> Please review this change to display the JCE provider that has been
>>>>>>>>> selected for common crypto operations.
>>>>>>>>> This aids troubleshooting crypto applications when a given crypto
>>>>>>>>> algorithm is supported by several JCE providers.
>>>>>>>>> Some crypto operations delay selecting a provider until they
>>>>>>>>> examine the
>>>>>>>>> key supplied in the init() method.
>>>>>>>>> This fix also accommodates that behaviour.
>>>>>>>>> 
>>>>>>>>> The following crypto operations are supported: Cipher, KeyAgreement,
>>>>>>>>> KeyGenerator, KeyPairGenerator, Mac and Signature.
>>>>>>>>> To see these new messages, activate JCE provider debugging as normal.
>>>>>>>>> For example,
>>>>>>>>> 
>>>>>>>>> % java -Djava.security.debug=provider MySSLClientApp
>>>>>>>>>  :
>>>>>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign
>>>>>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign
>>>>>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign
>>>>>>>>> Provider: Signature.SHA1withDSA verification from: SunPKCS11-Solaris
>>>>>>>>> Provider: Signature.SHA1withDSA verification from: SunPKCS11-Solaris
>>>>>>>>> Provider: Signature.MD5withRSA verification from: SunPKCS11-Solaris
>>>>>>>>> Provider: Signature.MD5withRSA verification from: SunPKCS11-Solaris
>>>>>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign
>>>>>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign
>>>>>>>>> Provider: KeyPairGenerator.EC from: SunPKCS11-Solaris
>>>>>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign
>>>>>>>>> Provider: Signature.SHA256withRSA verification from: SunRsaSign
>>>>>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE
>>>>>>>>> Provider: KeyGenerator.SunTls12RsaPremasterSecret from: SunJCE
>>>>>>>>> Provider: Cipher.RSA/ECB/PKCS1Padding key wrapping from:
>>>>>>>>> SunPKCS11-Solaris
>>>>>>>>> Provider: KeyGenerator.SunTls12MasterSecret from: SunJCE
>>>>>>>>> Provider: KeyGenerator.SunTls12KeyMaterial from: SunJCE
>>>>>>>>> Provider: Signature.SHA512withRSA signing from: SunPKCS11-Solaris
>>>>>>>>> Provider: KeyGenerator.SunTls12Prf from: SunJCE
>>>>>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE
>>>>>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE
>>>>>>>>> Provider: KeyGenerator.SunTls12Prf from: SunJCE
>>>>>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE
>>>>>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE
>>>>>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE
>>>>>>>>> Provider: KeyGenerator.SunTls12KeyMaterial from: SunJCE
>>>>>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE
>>>>>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE
>>>>>>>>> Provider: KeyGenerator.SunTls12Prf from: SunJCE
>>>>>>>>> Provider: KeyGenerator.SunTls12Prf from: SunJCE
>>>>>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE
>>>>>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE
>>>>>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE
>>>>>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE
>>>>>>>>> Provider: Cipher.AES/GCM/NoPadding decryption from: SunJCE
>>>>>>>>> Provider: Cipher.AES/GCM/NoPadding encryption from: SunJCE
>>>>>>>>>  :
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Thanks.
>>>>>>>>> 
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8056026
>>>>>>>>> Webrev: http://cr.openjdk.java.net/~vinnie/8056026/webrev.00/
>>>>>>> 
>>>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20140917/adfe7832/attachment.htm>