RE: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd party JCE provider

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd party JCE provider

Langer, Christoph
Hi Tony et. al.,

I'm wondering why in the commit for 8174849 (http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d911fe42d2da) this line sneaked in:

--- a/src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java Wed Feb 15 12:11:03 2017 -0800
+++ b/src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java Wed Feb 15 12:55:20 2017 -0800
@@ -276,7 +276,7 @@
         AlgorithmParameters currSigAlgParams = algorithmId.getParameters();
         PublicKey currPubKey = cert.getPublicKey();
-        String currSigAlg = x509Cert.getSigAlgName();
+        String currSigAlg = ((X509Certificate)cert).getSigAlgName();

         // Check the signature algorithm and parameters against constraints.
         if (!constraints.permits(SIGNATURE_PRIMITIVE_SET, currSigAlg,

The proposed webrev only contains the change to java.security and there is no other hint on that anywhere public.

I'm asking because I'm seeing an issue with a 3rd party JCE provider at the moment. There is an "SHA1withRSA" certificate involved but the provider in use at my customer returns the String "SHA1/RSA" as SigAlgName. Don't know how much this conforms with the spec, but it is as it is. So the permits check will fail with that String. I believe, if the SigAlgName would be taken from the converted x509Cert as before, we'd get SHA1withRSA and would be fine, though I didn't test that yet. So, what speaks against that line being reverted?

Thanks & Best regards
Christoph

> -----Original Message-----
> From: security-dev [mailto:[hidden email]] On
> Behalf Of Anthony Scarpino
> Sent: Montag, 13. Februar 2017 22:48
> To: OpenJDK Security <[hidden email]>
> Subject: [RFR] 8174849: Change SHA1 certpath restrictions
>
> Hi,
>
> I need a quick review on a simple certpath config change.
>
> http://cr.openjdk.java.net/~ascarpino/8174849/webrev/
>
> thanks
>
> Tony
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd party JCE provider

Langer, Christoph
Hi,

I'd like to ping you again upon that question. In the meanwhile I have produced a standalone test case and could verify that changing to x509Cert vs. the original cert for obtaining the SigAlgName would be a fix. I can share the test with you, however, you'll need the security provider 'IAIK' which is not OpenSource but can be obtained for free for educational/research purposes here [1].

Shall I open a Bug for that and propose a fix? Or is using the x509Cert at this place the wrong thing to do here for reasons? I'd appreciate some feedback.

Thanks & Best regards
Christoph


[1] http://jcewww.iaik.tu-graz.ac.at/sic/Products/Core_Crypto_Toolkits/JCA_JCE
 

> -----Original Message-----
> From: Langer, Christoph
> Sent: Sonntag, 9. Juli 2017 07:57
> To: 'Anthony Scarpino' <[hidden email]>; 'Sean Mullan'
> <[hidden email]>
> Cc: OpenJDK Security <[hidden email]>; 'Dieter Bratko'
> <[hidden email]>
> Subject: RE: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd
> party JCE provider
>
> Hi Tony et. al.,
>
> I'm wondering why in the commit for 8174849
> (http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d911fe42d2da) this line
> sneaked in:
>
> ---
> a/src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChe
> cker.java Wed Feb 15 12:11:03 2017 -0800
> +++
> b/src/java.base/share/classes/sun/security/provider/certpath/AlgorithmCh
> ecker.java Wed Feb 15 12:55:20 2017 -0800
> @@ -276,7 +276,7 @@
>          AlgorithmParameters currSigAlgParams = algorithmId.getParameters();
>          PublicKey currPubKey = cert.getPublicKey();
> -        String currSigAlg = x509Cert.getSigAlgName();
> +        String currSigAlg = ((X509Certificate)cert).getSigAlgName();
>
>          // Check the signature algorithm and parameters against constraints.
>          if (!constraints.permits(SIGNATURE_PRIMITIVE_SET, currSigAlg,
>
> The proposed webrev only contains the change to java.security and there is
> no other hint on that anywhere public.
>
> I'm asking because I'm seeing an issue with a 3rd party JCE provider at the
> moment. There is an "SHA1withRSA" certificate involved but the provider in
> use at my customer returns the String "SHA1/RSA" as SigAlgName. Don't
> know how much this conforms with the spec, but it is as it is. So the permits
> check will fail with that String. I believe, if the SigAlgName would be taken
> from the converted x509Cert as before, we'd get SHA1withRSA and would be
> fine, though I didn't test that yet. So, what speaks against that line being
> reverted?
>
> Thanks & Best regards
> Christoph
>
> > -----Original Message-----
> > From: security-dev [mailto:[hidden email]] On
> > Behalf Of Anthony Scarpino
> > Sent: Montag, 13. Februar 2017 22:48
> > To: OpenJDK Security <[hidden email]>
> > Subject: [RFR] 8174849: Change SHA1 certpath restrictions
> >
> > Hi,
> >
> > I need a quick review on a simple certpath config change.
> >
> > http://cr.openjdk.java.net/~ascarpino/8174849/webrev/
> >
> > thanks
> >
> > Tony
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd party JCE provider

Sean Mullan
Hi Christoph,

On 7/11/17 5:43 AM, Langer, Christoph wrote:
> Hi,
>
> I'd like to ping you again upon that question. In the meanwhile I have produced a standalone test case and could verify that changing to x509Cert vs. the original cert for obtaining the SigAlgName would be a fix. I can share the test with you, however, you'll need the security provider 'IAIK' which is not OpenSource but can be obtained for free for educational/research purposes here [1].
>
> Shall I open a Bug for that and propose a fix? Or is using the x509Cert at this place the wrong thing to do here for reasons? I'd appreciate some feedback.

Technically, I don't think this is a bug. IAIK is using a non-standard
algorithm for the signature algorithm of the certificate. The Standard
Algorithm Names specification [1] says that "SHA1withRSA" is the correct
name.

The JDK algorithm constraints implementation should not have to
accommodate non-compliant certificates.

Tony and I don't quite recall why this change was made as part of
JDK-8174849, but in general the conversion to
sun.security.x509.X509CertImpl is done so that we can access parts of
the certificate in a more performance friendly manner or if they are not
accessible via the standard APIs. This is not one of those cases.
However, I can't think of any specific reason right now we could not use
X509CertImpl instead but would like to think about it some more.

Have you asked IAIK about their non-compliance?

Thanks,
Sean

[1]
http://download.java.net/java/jdk9/docs/specs/security/standard-names.html#signature-algorithms

>
> Thanks & Best regards
> Christoph
>
>
> [1] http://jcewww.iaik.tu-graz.ac.at/sic/Products/Core_Crypto_Toolkits/JCA_JCE
>  
>> -----Original Message-----
>> From: Langer, Christoph
>> Sent: Sonntag, 9. Juli 2017 07:57
>> To: 'Anthony Scarpino' <[hidden email]>; 'Sean Mullan'
>> <[hidden email]>
>> Cc: OpenJDK Security <[hidden email]>; 'Dieter Bratko'
>> <[hidden email]>
>> Subject: RE: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd
>> party JCE provider
>>
>> Hi Tony et. al.,
>>
>> I'm wondering why in the commit for 8174849
>> (http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d911fe42d2da) this line
>> sneaked in:
>>
>> ---
>> a/src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChe
>> cker.java Wed Feb 15 12:11:03 2017 -0800
>> +++
>> b/src/java.base/share/classes/sun/security/provider/certpath/AlgorithmCh
>> ecker.java Wed Feb 15 12:55:20 2017 -0800
>> @@ -276,7 +276,7 @@
>>           AlgorithmParameters currSigAlgParams = algorithmId.getParameters();
>>           PublicKey currPubKey = cert.getPublicKey();
>> -        String currSigAlg = x509Cert.getSigAlgName();
>> +        String currSigAlg = ((X509Certificate)cert).getSigAlgName();
>>
>>           // Check the signature algorithm and parameters against constraints.
>>           if (!constraints.permits(SIGNATURE_PRIMITIVE_SET, currSigAlg,
>>
>> The proposed webrev only contains the change to java.security and there is
>> no other hint on that anywhere public.
>>
>> I'm asking because I'm seeing an issue with a 3rd party JCE provider at the
>> moment. There is an "SHA1withRSA" certificate involved but the provider in
>> use at my customer returns the String "SHA1/RSA" as SigAlgName. Don't
>> know how much this conforms with the spec, but it is as it is. So the permits
>> check will fail with that String. I believe, if the SigAlgName would be taken
>> from the converted x509Cert as before, we'd get SHA1withRSA and would be
>> fine, though I didn't test that yet. So, what speaks against that line being
>> reverted?
>>
>> Thanks & Best regards
>> Christoph
>>
>>> -----Original Message-----
>>> From: security-dev [mailto:[hidden email]] On
>>> Behalf Of Anthony Scarpino
>>> Sent: Montag, 13. Februar 2017 22:48
>>> To: OpenJDK Security <[hidden email]>
>>> Subject: [RFR] 8174849: Change SHA1 certpath restrictions
>>>
>>> Hi,
>>>
>>> I need a quick review on a simple certpath config change.
>>>
>>> http://cr.openjdk.java.net/~ascarpino/8174849/webrev/
>>>
>>> thanks
>>>
>>> Tony
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd party JCE provider

Langer, Christoph
Hi Sean,

thanks for coming back on this.

> > I'd like to ping you again upon that question. In the meanwhile I have
> produced a standalone test case and could verify that changing to x509Cert
> vs. the original cert for obtaining the SigAlgName would be a fix. I can share
> the test with you, however, you'll need the security provider 'IAIK' which is
> not OpenSource but can be obtained for free for educational/research
> purposes here [1].
> >
> > Shall I open a Bug for that and propose a fix? Or is using the x509Cert at this
> place the wrong thing to do here for reasons? I'd appreciate some feedback.
>
> Technically, I don't think this is a bug. IAIK is using a non-standard
> algorithm for the signature algorithm of the certificate. The Standard
> Algorithm Names specification [1] says that "SHA1withRSA" is the correct
> name.
>
> The JDK algorithm constraints implementation should not have to
> accommodate non-compliant certificates.
>
> Tony and I don't quite recall why this change was made as part of
> JDK-8174849, but in general the conversion to
> sun.security.x509.X509CertImpl is done so that we can access parts of
> the certificate in a more performance friendly manner or if they are not
> accessible via the standard APIs. This is not one of those cases.
> However, I can't think of any specific reason right now we could not use
> X509CertImpl instead but would like to think about it some more.
>
> Have you asked IAIK about their non-compliance?
>
> [1]
> http://download.java.net/java/jdk9/docs/specs/security/standard-
> names.html#signature-algorithms

Well, probably you are right that it is not a bug - at least when you look at the documentation of Java9 (the link that you have cited).

However, if we look at the documentation of X509Certificate, it's not that clear, resp. it wasn't for pre JDK9 releases. JDK9 mentions in [1] an algorithm name example of "SHA256withRSA". However, the documentation for 8 [2] and probably all older JDKs talks about an example of "SHA-1/DSA". So this older type of algorithm names must have existed at some time - and it used to work with JDKs <= 8. However, the security standard names documentation already existed for JDK8 and probably earlier.

As for the reason why IAIK has not changed that (yet), maybe Dieter on cc can comment. He mentioned to me that some discussion about that had been done within IAIK but the change was never really dared.

So, I guess I would be fine if this could at least be changed for JDKs <= 8 for compatibility reasons. I can understand if for JDK >= 9 we say this is a new release and the standard algorithm names shall be enforced. Wouldn't that be a good compromise?

In any case, from what you are saying, I take that I can safely patch our JDK distribution with this change without doing a bad thing to security in general, wouldn't you agree?

Thanks & best regards
Christoph

[1] http://download.java.net/java/jdk9/docs/api/java/security/cert/X509Certificate.html#getSigAlgName--
[2] https://docs.oracle.com/javase/8/docs/api/javax/security/cert/X509Certificate.html#getSigAlgName--

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

AW: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd party JCE provider

Dieter Bratko
In reply to this post by Sean Mullan
Hello Sean, Christoph,

To explain the reason for our non-compliance to the JCA "<hash>withRSA" signature standard name notation I have to get back to the very beginning. Namely to JDK 1.1.8 which used the "<hash>/RSA" notation as standard names for RSA-PKCSv1.5 signature algorithms (see attachment; I have found a JCK1.1.8 CryptoSpec in our archives : -).
IAIK followed this recommendation and later - as SUN has changed to the <hash>withRSA notation we changed it too -- but then had to turn back since too many users already relied on the "/" slash in the signature algorithm name -- I think for parsing the hash algorithm from it. The problem was not the Signature engine (where getAlgorithm() returns what has been specified when calling Signature.getInstance()), but the names used for ASN.1 AlgorithmIdentifiers (as used by X.509 certificates). So we had to stay with the original JCA standard name notation for our AlgorithmID implementation (but added the possibility allowing users to change the name settings).
However, we again will check if we can change to the <hash>withRSA notation. Nevertheless, since the CertPath AlgorithmChecker already converts the X509CertImpl it might be more safe to call getSigAlgName() on it -- for Algorithms it knows of (and therefore also knows which names it expects).

Best Regards,
Dieter

-----Original Message-----
Von: Sean Mullan [mailto:[hidden email]]
Gesendet: Dienstag, 11. Juli 2017 19:21
An: Langer, Christoph <[hidden email]>; Anthony Scarpino <[hidden email]>
Cc: OpenJDK Security <[hidden email]>; Dieter Bratko <[hidden email]>
Betreff: Re: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd party JCE provider

Hi Christoph,

On 7/11/17 5:43 AM, Langer, Christoph wrote:
> Hi,
>
> I'd like to ping you again upon that question. In the meanwhile I have produced a standalone test case and could verify that changing to x509Cert vs. the original cert for obtaining the SigAlgName would be a fix. I can share the test with you, however, you'll need the security provider 'IAIK' which is not OpenSource but can be obtained for free for educational/research purposes here [1].
>
> Shall I open a Bug for that and propose a fix? Or is using the x509Cert at this place the wrong thing to do here for reasons? I'd appreciate some feedback.

Technically, I don't think this is a bug. IAIK is using a non-standard algorithm for the signature algorithm of the certificate. The Standard Algorithm Names specification [1] says that "SHA1withRSA" is the correct name.

The JDK algorithm constraints implementation should not have to accommodate non-compliant certificates.

Tony and I don't quite recall why this change was made as part of JDK-8174849, but in general the conversion to sun.security.x509.X509CertImpl is done so that we can access parts of the certificate in a more performance friendly manner or if they are not accessible via the standard APIs. This is not one of those cases.
However, I can't think of any specific reason right now we could not use X509CertImpl instead but would like to think about it some more.

Have you asked IAIK about their non-compliance?

Thanks,
Sean

[1]
http://download.java.net/java/jdk9/docs/specs/security/standard-names.html#signature-algorithms

>
> Thanks & Best regards
> Christoph
>
>
> [1]
> http://jcewww.iaik.tu-graz.ac.at/sic/Products/Core_Crypto_Toolkits/JCA
> _JCE
>  
>> -----Original Message-----
>> From: Langer, Christoph
>> Sent: Sonntag, 9. Juli 2017 07:57
>> To: 'Anthony Scarpino' <[hidden email]>; 'Sean Mullan'
>> <[hidden email]>
>> Cc: OpenJDK Security <[hidden email]>; 'Dieter Bratko'
>> <[hidden email]>
>> Subject: RE: [RFR] 8174849: Change SHA1 certpath restrictions - issue
>> with 3rd party JCE provider
>>
>> Hi Tony et. al.,
>>
>> I'm wondering why in the commit for 8174849
>> (http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d911fe42d2da) this line
>> sneaked in:
>>
>> ---
>> a/src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChe
>> cker.java Wed Feb 15 12:11:03 2017 -0800
>> +++
>> b/src/java.base/share/classes/sun/security/provider/certpath/AlgorithmCh
>> ecker.java Wed Feb 15 12:55:20 2017 -0800
>> @@ -276,7 +276,7 @@
>>           AlgorithmParameters currSigAlgParams = algorithmId.getParameters();
>>           PublicKey currPubKey = cert.getPublicKey();
>> -        String currSigAlg = x509Cert.getSigAlgName();
>> +        String currSigAlg = ((X509Certificate)cert).getSigAlgName();
>>
>>           // Check the signature algorithm and parameters against constraints.
>>           if (!constraints.permits(SIGNATURE_PRIMITIVE_SET,
>> currSigAlg,
>>
>> The proposed webrev only contains the change to java.security and
>> there is no other hint on that anywhere public.
>>
>> I'm asking because I'm seeing an issue with a 3rd party JCE provider
>> at the moment. There is an "SHA1withRSA" certificate involved but the
>> provider in use at my customer returns the String "SHA1/RSA" as
>> SigAlgName. Don't know how much this conforms with the spec, but it
>> is as it is. So the permits check will fail with that String. I
>> believe, if the SigAlgName would be taken from the converted x509Cert
>> as before, we'd get SHA1withRSA and would be fine, though I didn't
>> test that yet. So, what speaks against that line being reverted?
>>
>> Thanks & Best regards
>> Christoph
>>
>>> -----Original Message-----
>>> From: security-dev [mailto:[hidden email]] On
>>> Behalf Of Anthony Scarpino
>>> Sent: Montag, 13. Februar 2017 22:48
>>> To: OpenJDK Security <[hidden email]>
>>> Subject: [RFR] 8174849: Change SHA1 certpath restrictions
>>>
>>> Hi,
>>>
>>> I need a quick review on a simple certpath config change.
>>>
>>> http://cr.openjdk.java.net/~ascarpino/8174849/webrev/
>>>
>>> thanks
>>>
>>> Tony

CryptoSpec.html (90K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd party JCE provider

Sean Mullan
In reply to this post by Langer, Christoph
On 7/11/17 3:10 PM, Langer, Christoph wrote:
> Well, probably you are right that it is not a bug - at least when you look at the documentation of Java9 (the link that you have cited).
>
> However, if we look at the documentation of X509Certificate, it's not that clear, resp. it wasn't for pre JDK9 releases. JDK9 mentions in [1] an algorithm name example of "SHA256withRSA". However, the documentation for 8 [2] and probably all older JDKs talks about an example of "SHA-1/DSA". So this older type of algorithm names must have existed at some time - and it used to work with JDKs <= 8. However, the security standard names documentation already existed for JDK8 and probably earlier.

Right, as Dieter pointed out in his reply, this seems to go way back to
the early days of Java when the standard algorithm names were still
evolving.

> As for the reason why IAIK has not changed that (yet), maybe Dieter on cc can comment. He mentioned to me that some discussion about that had been done within IAIK but the change was never really dared.
>
> So, I guess I would be fine if this could at least be changed for JDKs <= 8 for compatibility reasons. I can understand if for JDK >= 9 we say this is a new release and the standard algorithm names shall be enforced. Wouldn't that be a good compromise?

Yes. In fact I think the most robust solution (even for 9 and later) is
to look at the encoded AlgorithmId in the X.509 certificate to determine
what signature algorithm is being used, and this would eliminate the
compatibility risk with third party providers using non-standard Java
names. This is exactly what X509CertImpl.getSigAlgName() is doing.
> In any case, from what you are saying, I take that I can safely patch our JDK distribution with this change without doing a bad thing to security in general, wouldn't you agree?

Yes, I agree.

Also, note that you can probably also workaround this issue by adding a
specific "SHA1/RSA" constraint to the jdk.certpath.disabledAlgorithms
security property.

--Sean

>
> Thanks & best regards
> Christoph
>
> [1]http://download.java.net/java/jdk9/docs/api/java/security/cert/X509Certificate.html#getSigAlgName--
> [2]https://docs.oracle.com/javase/8/docs/api/javax/security/cert/X509Certificate.html#getSigAlgName--
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd party JCE provider

Langer, Christoph
Hi Sean,

> > So, I guess I would be fine if this could at least be changed for JDKs <= 8 for
> compatibility reasons. I can understand if for JDK >= 9 we say this is a new
> release and the standard algorithm names shall be enforced. Wouldn't that
> be a good compromise?
>
> Yes. In fact I think the most robust solution (even for 9 and later) is
> to look at the encoded AlgorithmId in the X.509 certificate to determine
> what signature algorithm is being used, and this would eliminate the
> compatibility risk with third party providers using non-standard Java
> names. This is exactly what X509CertImpl.getSigAlgName() is doing.

OK, I will file a bug and post a change for review.

I then suggest to also revert JDK10 and 9 to use X509CertImpl.getSigAlgName() for the time being until some better check to go for the encoded AlgorithmId. Would you be fine with that?


> Also, note that you can probably also workaround this issue by adding a
> specific "SHA1/RSA" constraint to the jdk.certpath.disabledAlgorithms
> security property.

Hm, I thought with that property you would only define a negative list of algorithms that are not supported (out of the known ones). But is it possible to specify an unknown algorithm name to whitelist?

Thanks
Christoph

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd party JCE provider

Anthony Scarpino
On 07/12/2017 11:59 PM, Langer, Christoph wrote:

> Hi Sean,
>
>>> So, I guess I would be fine if this could at least be changed for JDKs <= 8 for
>> compatibility reasons. I can understand if for JDK >= 9 we say this is a new
>> release and the standard algorithm names shall be enforced. Wouldn't that
>> be a good compromise?
>>
>> Yes. In fact I think the most robust solution (even for 9 and later) is
>> to look at the encoded AlgorithmId in the X.509 certificate to determine
>> what signature algorithm is being used, and this would eliminate the
>> compatibility risk with third party providers using non-standard Java
>> names. This is exactly what X509CertImpl.getSigAlgName() is doing.
>
> OK, I will file a bug and post a change for review.
>
> I then suggest to also revert JDK10 and 9 to use
> X509CertImpl.getSigAlgName() forthe time being until some better
> check to go for the encoded AlgorithmId. Would you be fine with
> that
Looking back at the original code, before any of these changes were put
in, it was always "((X509Certificate)cert).getSigAlgName();". I would
guess I changed this in February to go back to the original method called.

>
>
>> Also, note that you can probably also workaround this issue by adding a
>> specific "SHA1/RSA" constraint to the jdk.certpath.disabledAlgorithms
>> security property.
>
> Hm, I thought with that property you would only define a negative
> list of algorithms that are not supported (out of the known ones).
> But is it possible to specify an unknown algorithm name to whitelist?

It is a negative list and it has to match the algorithm name.  There is
no unknown/catch-all.

>
> Thanks
> Christoph
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd party JCE provider

Anthony Scarpino
On 07/13/2017 11:26 AM, Anthony Scarpino wrote:
> On 07/12/2017 11:59 PM, Langer, Christoph wrote:
>> I then suggest to also revert JDK10 and 9 to use
>> X509CertImpl.getSigAlgName() forthe time being until some better
>> check to go for the encoded AlgorithmId. Would you be fine with
>> that
> Looking back at the original code, before any of these changes were put
> in, it was always "((X509Certificate)cert).getSigAlgName();". I would
> guess I changed this in February to go back to the original method called.

Ignore my comments above, I didn't go far enough back in the changeset
diffs to see it had used X509CertImpl originally.

Tony
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd party JCE provider

Anthony Scarpino
In reply to this post by Sean Mullan
On 07/12/2017 07:45 AM, Sean Mullan wrote:
> On 7/11/17 3:10 PM, Langer, Christoph wrote:

>> In any case, from what you are saying, I take that I can safely patch
>> our JDK distribution with this change without doing a bad thing to
>> security in general, wouldn't you agree?
>
> Yes, I agree.
>
> Also, note that you can probably also workaround this issue by adding a
> specific "SHA1/RSA" constraint to the jdk.certpath.disabledAlgorithms
> security property.
>
> --Sean

The problem cannot be resolved by jdk.certpath.disabledAlgorithms.
Without using X509CertImpl, the non-standard "SHA1/RSA" is not converted
to "SHA1withRSA" The failing call is in the
SSLAlgorithConstraints.permit() checks by matching the algorithm name
with a list of standard supported algorithm names, and therefore fails.

Tony

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd party JCE provider

Seán Coffey
Tony,

I think we should log a JDK 8u bug for this issue if one doesn't already
exist. If the buggy SigAlgName was allowed in 8u updates already, then
it should be continued to be allowed for compatibility reasons IMO.
There might be time to revert that change in 8u152.

For 9, then maybe we can document the minor behavioural change that'
been introduced.

Regards,
Sean.

On 14/07/17 05:25, Anthony Scarpino wrote:

> On 07/12/2017 07:45 AM, Sean Mullan wrote:
>> On 7/11/17 3:10 PM, Langer, Christoph wrote:
>
>>> In any case, from what you are saying, I take that I can safely
>>> patch our JDK distribution with this change without doing a bad
>>> thing to security in general, wouldn't you agree?
>>
>> Yes, I agree.
>>
>> Also, note that you can probably also workaround this issue by adding
>> a specific "SHA1/RSA" constraint to the
>> jdk.certpath.disabledAlgorithms security property.
>>
>> --Sean
>
> The problem cannot be resolved by jdk.certpath.disabledAlgorithms.
> Without using X509CertImpl, the non-standard "SHA1/RSA" is not
> converted to "SHA1withRSA" The failing call is in the
> SSLAlgorithConstraints.permit() checks by matching the algorithm name
> with a list of standard supported algorithm names, and therefore fails.
>
> Tony
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd party JCE provider

Langer, Christoph
Hi Sean(s), Tony,

I have created the bug https://bugs.openjdk.java.net/browse/JDK-8184673 and posted a change to revert the sigAlgName check. You had indicated that it should be ok to do this for JDK9 and 10 as well, so no behavioral change has to be documented.

If you give the ok, I would push it to JDK10 and I can also do the downport to jdk8u as well as jdk9u once it has opened. All the other backports you'll have to do yourself, e.g. for the Oracle JDKs and/or <8 and the upcoming update releases.

Thanks & Best regards
Christoph


> -----Original Message-----
> From: Seán Coffey [mailto:[hidden email]]
> Sent: Freitag, 14. Juli 2017 12:17
> To: Anthony Scarpino <[hidden email]>; Sean Mullan
> <[hidden email]>; Langer, Christoph <[hidden email]>
> Cc: OpenJDK Security <[hidden email]>
> Subject: Re: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd
> party JCE provider
>
> Tony,
>
> I think we should log a JDK 8u bug for this issue if one doesn't already
> exist. If the buggy SigAlgName was allowed in 8u updates already, then
> it should be continued to be allowed for compatibility reasons IMO.
> There might be time to revert that change in 8u152.
>
> For 9, then maybe we can document the minor behavioural change that'
> been introduced.
>
> Regards,
> Sean.
>
> On 14/07/17 05:25, Anthony Scarpino wrote:
> > On 07/12/2017 07:45 AM, Sean Mullan wrote:
> >> On 7/11/17 3:10 PM, Langer, Christoph wrote:
> >
> >>> In any case, from what you are saying, I take that I can safely
> >>> patch our JDK distribution with this change without doing a bad
> >>> thing to security in general, wouldn't you agree?
> >>
> >> Yes, I agree.
> >>
> >> Also, note that you can probably also workaround this issue by adding
> >> a specific "SHA1/RSA" constraint to the
> >> jdk.certpath.disabledAlgorithms security property.
> >>
> >> --Sean
> >
> > The problem cannot be resolved by jdk.certpath.disabledAlgorithms.
> > Without using X509CertImpl, the non-standard "SHA1/RSA" is not
> > converted to "SHA1withRSA" The failing call is in the
> > SSLAlgorithConstraints.permit() checks by matching the algorithm name
> > with a list of standard supported algorithm names, and therefore fails.
> >
> > Tony
> >

Loading...