hg: jdk8/tl/jdk: 4759491: method ZipEntry.setTime(long) works incorrectly; ...

[xueming . shen]

Changeset: 90df6756406f
Author:sherman
Date:  2013-05-29 19:50 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/90df6756406f

4759491: method ZipEntry.setTime(long) works incorrectly
6303183: Support NTFS and Unix-style timestamps for entries in Zip files
7012856: (zipfs) Newly created entry in zip file system should set all file 
times non-null values.
7012868: (zipfs) file times of entry in zipfs should always be the same 
regardless of TimeZone.
Summary: to add suuport of Info-ZIP extended timestamp in extra data fields
Reviewed-by: martin, alanb

! src/share/classes/java/util/zip/ZipConstants.java
! src/share/classes/java/util/zip/ZipEntry.java
! src/share/classes/java/util/zip/ZipFile.java
! src/share/classes/java/util/zip/ZipInputStream.java
! src/share/classes/java/util/zip/ZipOutputStream.java
+ src/share/classes/java/util/zip/ZipUtils.java
! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java
! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipInfo.java
! test/demo/zipfs/ZipFSTester.java
! test/demo/zipfs/basic.sh
! test/java/util/jar/TestExtra.java
! test/java/util/zip/StoredCRC.java
+ test/java/util/zip/TestExtraTime.java
! test/java/util/zip/ZipFile/Assortment.java

Re: Code review request, 7188658 Add possibility to disable client initiated renegotiation

[Xuelei Fan]

Got it. Yes, this fix is addressing a different issue from you mentioned
below.

Thanks,
Xuelei

On 5/30/2013 9:53 AM, Bernd Eckenfels wrote:
> Am 30.05.2013, 02:18 Uhr, schrieb Xuelei Fan :
>>> 2381456
>> Would you mind send me the link of the bug, or the code review request
>> mail?  I may miss some mails about this direction.
> 
> I am afraid I cant sent the link, the Bug is in review state and
> therefore not visible for me. It was acknowledged 2012-11-12, see
> attached. I guess the link would be
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=2381456 (not sure if
> the numbers are the same in the new bug tool).
> 
>> Good suggestion.  Oracle provider of JSSE had addressed the TLS
>> renegotiation issue in JDK 1.4.2 update 26, JDK 1.5.0 update 24 and JDK
>> 6u 19 around the end of 2009 and the beginning of 2010.  Here is the
>> readme of the fix:
>> http://www.oracle.com/technetwork/java/javase/documentation/tlsreadme2-176330.html.
>>
> 
> Thats a different problem, I was thinking about preventing execessive
> client initiated renegotiations. This is for example CVE-2011-1473 from
> THC.
> 
>>> You mentioned industry will move to a secure handshake - are you
>>> aware of any initiative in that direction?
>>>
>> See http://www.rfc.org/rfc/rfc5746.txt.  As far as I know, nearly all
>> major vendors of SSL protocols has support RFC5746.
> 
> Ok, but thats a different issue. I was expecting 7188658 to address
> another point, but I might be wrong.
> 
> I understand that as of Oracle policy we cannot discuss it. Even if this
> is a very well known issue. :-/
> 
> Greetings
> Bernd

Re: Code review request, 7188658 Add possibility to disable client initiated renegotiation

[Bernd Eckenfels]

Am 30.05.2013, 02:18 Uhr, schrieb Xuelei Fan :

2381456

Would you mind send me the link of the bug, or the code review request
mail?  I may miss some mails about this direction.


I am afraid I cant sent the link, the Bug is in review state and therefore
not visible for me. It was acknowledged 2012-11-12, see attached. I guess
the link would be
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=2381456 (not sure if
the numbers are the same in the new bug tool).


Good suggestion.  Oracle provider of JSSE had addressed the TLS
renegotiation issue in JDK 1.4.2 update 26, JDK 1.5.0 update 24 and JDK
6u 19 around the end of 2009 and the beginning of 2010.  Here is the
readme of the fix:
http://www.oracle.com/technetwork/java/javase/documentation/tlsreadme2-176330.html.


Thats a different problem, I was thinking about preventing execessive
client initiated renegotiations. This is for example CVE-2011-1473 from
THC.

You mentioned industry will move to a secure handshake - are you aware  
of any initiative in that direction?



See http://www.rfc.org/rfc/rfc5746.txt.  As far as I know, nearly all
major vendors of SSL protocols has support RFC5746.


Ok, but thats a different issue. I was expecting 7188658 to address
another point, but I might be wrong.

I understand that as of Oracle policy we cannot discuss it. Even if this
is a very well known issue. :-/

Greetings
Bernd
--
http://bernd.eckenfels.net

Date Created: Mon Nov 12 12:13:08 MST 2012
Type:bug
Customer Name:   Bernd Eckenfels
SDN ID:
status:  Waiting
Category:jsse
Subcategory: runtime
release: 7
hardware:x64
OSversion:   linux_sles11
priority:4
Synopsis:Excessive SSL renegotiation possible
Description:
   FULL PRODUCT VERSION :
java version "1.7.0_09"
Java(TM) SE Runtime Environment (build 1.7.0_09-b05)
Java HotSpot(TM) 64-Bit Server VM (build 23.5-b02, mixed mode)



ADDITIONAL OS VERSION INFORMATION :
Various Versions

A DESCRIPTION OF THE PROBLEM :
The SSL/TLS Server Socket (and SSLEngine) of JSSE seems not to protect
itself from excessive handshake requests and renegotiations. This leads to
a high CPU load. For other products this is filed as CVE-2011-1473 or
CVE-2011-5094.

A minimum solution would be to actually turn the renegotiation support
off, IBM JDK for example offers the option "com.ibm.jsse2.renegotiate"

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
- set up a JSSE ServerSocket
- connect with openssl s_client (use "R" command) or thc tool

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
after a small number of consecutive renegotiates the server should ignore
them
ACTUAL -
server-cpu is fully used

REPRODUCIBILITY :
This bug can be reproduced always.

Re: Code review request, 7188658 Add possibility to disable client initiated renegotiation

[Xuelei Fan]

On 5/30/2013 1:06 AM, Bernd Eckenfels wrote:
> Hello Xuelei,
> 
> This is nice to hear. BTW: my own Bug in that direction never made it through 
> review, maybe you want to reference ist a well. Not Public: 2381456
> 
Would you mind send me the link of the bug, or the code review request
mail?  I may miss some mails about this direction.

> There is a number of Security Advisories for this weakness (generic ones, 
> mainly mentioning other implementations). It might be worth to acknowlege one 
> of the CVEs or Issue your own one (I certainly have customers which noticed 
> lack of it).
> 
Good suggestion.  Oracle provider of JSSE had addressed the TLS
renegotiation issue in JDK 1.4.2 update 26, JDK 1.5.0 update 24 and JDK
6u 19 around the end of 2009 and the beginning of 2010.  Here is the
readme of the fix:
http://www.oracle.com/technetwork/java/javase/documentation/tlsreadme2-176330.html.

> As I understand the spec you could, instead of rejecting also ignore the 
> request. Did you consider making it a 3-state? (you can currently force the 
> Same terminating behaviour with an empty cipher suite).
> 
I did consider to ignore or warning the request instead of a fatal
closure.  But it bring in extra complexity, and hard to handle in both
client and server.

> You mentioned industry will move to a secure handshake - are you aware of any 
> initiative in that direction?
> 
See http://www.rfc.org/rfc/rfc5746.txt.  As far as I know, nearly all
major vendors of SSL protocols has support RFC5746.

Xuelei

> PS: i still would prefer to allow applications deal with this by having a 
> syncronous handshake listener (would could then count handshake frequency and 
> close the socket).
> 
> Bernd
> 

hg: jdk8/tl/langtools: 8015641: genstubs needs to cope with static interface methods

[jonathan . gibbons]

Changeset: d685b12b62a4
Author:jjg
Date:  2013-05-29 15:34 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d685b12b62a4

8015641: genstubs needs to cope with static interface methods
Reviewed-by: ksrini

! make/tools/genstubs/GenStubs.java

hg: jdk8/tl/jdk: 8015440: java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails with RuntimeException

[staffan . larsen]

Changeset: bd6d3801347b
Author:sla
Date:  2013-05-29 09:42 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bd6d3801347b

8015440: java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails with 
RuntimeException
Summary: Make sure serial gc compacts heap every time
Reviewed-by: mchung, brutisso, nloodin

! test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java

Re: PATCH: possible bug in OCSP check

[Ricardo Martin Camarero]

Hi Xuelei,

I suppose my company had, cos I also work for Oracle. :-)

But I'm not related with openjdk and this issue was discovered outside
my work (I was asked by an ex-colleague about the ocsp responder I
commented previously).

Regards!


On 05/29/2013 03:16 AM, Xuelei Fan wrote:
> Hi Ricardo,
>
> Have you or your organization signed the signed the Oracle Contributor
> Agreement (OCA) per the request of OpenJDK bylaws?
>
> http://openjdk.java.net/bylaws#_2
>
> Thanks,
> Xuelei
>
> On 5/24/2013 5:31 PM, Ricardo Martin Camarero wrote:
>> Hi everybody,
>>
>> I have been struggling for some months with a weird issue about how Java
>> validates OCSP responses. Following the RFC2560 standard the responses
>> sent by the responder should be signed following one of these three
>> possibilities:
>>
>>> All definitive response messages SHALL be digitally signed. The key
>>>used to sign the response MUST belong to one of the following:
>>>
>>>-- the CA who issued the certificate in question
>>>-- a Trusted Responder whose public key is trusted by the requester
>>>-- a CA Designated Responder (Authorized Responder) who holds a
>>>   specially marked certificate issued directly by the CA, indicating
>>>   that the responder may issue OCSP responses for that CA
>> In current java implementation (openjdk 6, 7 and 8) the case (1) and (3)
>> are considered by default and case (2) can be configured using some
>> properties ("ocsp.responderCertSubjectName" for example). But the
>> problem is that both configurations are exclusive, if your application
>> accepts responses for the cases (1) and (3) it fails with the case (2)
>> and vice-versa.
>>
>> I faced an OCSP responder that in some cases it answered using the case
>> (1) and in others using the case (2). The case (1) was used to sign
>> responses for their own certificates and the case (2) was used to sign
>> responses for foreign certificates (spanish national id certificates
>> specifically). I'm not completely sure if the standard admits this
>> situation but I haven't read anything against that. Besides why not to
>> take the configured certificate ("ocsp.responderCertSubjectName" or any
>> of the other properties) as a failback and not as the unique valid signer.
>>
>> Looking at the code the problem is that only one certificate is passed
>> as the valid signer for responses (the one configured via properties or
>> the issuer cert). Following Andrew advise I have made a little patch
>> against current openjdk-8 that just considers both of them (OCSPResponse
>> class receives both certs and this way can check the three cases).
>>
>> Thanks in advance!
>>

hg: jdk8/tl/nashorn: 9 new changesets

[james . laskey]

Changeset: 0bf451c0678d
Author:hannesw
Date:  2013-05-27 12:26 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/0bf451c0678d

8015348: RegExp("[") results in StackOverflowError
Reviewed-by: sundar, attila

! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java
+ test/script/basic/JDK-8015348.js
+ test/script/basic/JDK-8015348.js.EXPECTED

Changeset: 1f57afd14cc1
Author:lagergren
Date:  2013-05-27 13:11 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1f57afd14cc1

8014219: Make the run-octane harness more deterministic by not measuring 
elapsed time every iteration. Also got rid of most of the run logic in base.js 
and call benchmarks directly for the same purpose
Reviewed-by: jlaskey, attila

! make/build-benchmark.xml
! src/jdk/nashorn/internal/runtime/AccessorProperty.java
! src/jdk/nashorn/internal/runtime/Property.java
! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java
! test/script/basic/compile-octane.js.EXPECTED
! test/script/basic/run-octane.js

Changeset: 910fd2849c4c
Author:lagergren
Date:  2013-05-27 13:12 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/910fd2849c4c

Merge


Changeset: 343fd0450802
Author:sundar
Date:  2013-05-27 20:41 +0530
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/343fd0450802

8015352: "i".toUpperCase() => currently returns "Ä°", but should be "I" (with 
Turkish locale)
Reviewed-by: jlaskey, lagergren

! src/jdk/nashorn/internal/objects/NativeString.java
! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java
! src/jdk/nashorn/internal/runtime/options/OptionTemplate.java
! src/jdk/nashorn/internal/runtime/options/Options.java
! src/jdk/nashorn/internal/runtime/resources/Options.properties
+ test/script/basic/JDK-8015352.js

Changeset: e6193dcfe36c
Author:lagergren
Date:  2013-05-27 17:57 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e6193dcfe36c

8015447: Octane harness fixes for rhino and entire test runs: ant octane, ant 
octane-v8, ant octane-rhino
Reviewed-by: sundar, jlaskey

! make/build-benchmark.xml
! test/script/basic/run-octane.js

Changeset: d56168970de1
Author:sundar
Date:  2013-05-28 16:37 +0530
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d56168970de1

8015459: Octane test run fails on Turkish locale
Reviewed-by: lagergren, attila

! src/jdk/nashorn/internal/codegen/CodeGenerator.java
! src/jdk/nashorn/internal/objects/DateParser.java
! src/jdk/nashorn/internal/parser/TokenType.java
! src/jdk/nashorn/internal/runtime/GlobalFunctions.java
! src/jdk/nashorn/internal/runtime/JSType.java
! src/jdk/nashorn/internal/runtime/Logging.java
! src/jdk/nashorn/internal/runtime/ScriptRuntime.java
! src/jdk/nashorn/internal/runtime/options/OptionTemplate.java

Changeset: f472f7046ec9
Author:sundar
Date:  2013-05-29 15:41 +0530
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f472f7046ec9

8005979: A lot of tests are named "runTest" in reports
Reviewed-by: jlaskey

! make/project.properties

Changeset: f69e76417211
Author:lagergren
Date:  2013-05-29 14:08 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f69e76417211

8011023: Math round didn't conform to ECMAScript 5 spec
Reviewed-by: jlaskey, attila

! src/jdk/nashorn/internal/objects/NativeMath.java
+ test/script/basic/JDK-8011023.js
+ test/script/basic/JDK-8011023.js.EXPECTED

Changeset: a2e2797392b3
Author:sundar
Date:  2013-05-29 21:27 +0530
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a2e2797392b3

8015349: "abc".lastIndexOf("a",-1) should evaluate to 0 and not -1
Reviewed-by: lagergren, attila, jlaskey

! src/jdk/nashorn/internal/objects/NativeString.java
+ test/script/basic/JDK-8015349.js
+ test/script/basic/JDK-8015349.js.EXPECTED

Re: Code review request, 7188658 Add possibility to disable client initiated renegotiation

[Matthew Hall]

On Wed, May 29, 2013 at 07:06:41PM +0200, Bernd Eckenfels wrote:
> PS: i still would prefer to allow applications deal with this by having a 
> syncronous handshake listener (would could then count handshake frequency 
> and close the socket).

Expecting applications to do this would not be secure by default, and would 
result in a lot of cut-and-paste code. At minimum there should be a reasonable 
default implementation which does something sane, that an app could choose to 
manually override if there was a good reason for it.

Matthew.

Re: Code review request, 7188658 Add possibility to disable client initiated renegotiation

[Bernd Eckenfels]

Hello Xuelei,

This is nice to hear. BTW: my own Bug in that direction never made it through 
review, maybe you want to reference ist a well. Not Public: 2381456

There is a number of Security Advisories for this weakness (generic ones, 
mainly mentioning other implementations). It might be worth to acknowlege one 
of the CVEs or Issue your own one (I certainly have customers which noticed 
lack of it).

As I understand the spec you could, instead of rejecting also ignore the 
request. Did you consider making it a 3-state? (you can currently force the 
Same terminating behaviour with an empty cipher suite).

You mentioned industry will move to a secure handshake - are you aware of any 
initiative in that direction?

PS: i still would prefer to allow applications deal with this by having a 
syncronous handshake listener (would could then count handshake frequency and 
close the socket).

Bernd
-- 
bernd.eckenfels.net

Am 29.05.2013 um 17:39 schrieb Xuelei Fan :

> Hi,
> 
> This fix is an enhancement to add the ability in JSSE server side to
> reject client initialized renegotiation.
> 
> webrev: http://cr.openjdk.java.net/~xuelei/7188658/webrev.00/
> 
> Thanks,
> Xuelei

Re: Code review request, 7188658 Add possibility to disable client initiated renegotiation

[Xuelei Fan]

A new system property, "jsse.rejectClientInitializedRenego", is
introduced to reject client initialized renegotiation in server side.
If the system property is set to "true", server side should not accept
client initialized renegotiation, and is expected to fail with a fatal
handshake_failure alert if receiving client initialized renegotiation
request.

The default value of the system property is "false".

It is expected that other JSSE providers also comply to this
specification. The usage of the system property in client side is not
defined.

>From the long run, the industry should move forward to secure
renegotiation.  So we will not consider to support this enhancement with
new Java class or method.

Xuelei

On 5/29/2013 11:39 PM, Xuelei Fan wrote:
> Hi,
> 
> This fix is an enhancement to add the ability in JSSE server side to
> reject client initialized renegotiation.
> 
> webrev: http://cr.openjdk.java.net/~xuelei/7188658/webrev.00/
> 
> Thanks,
> Xuelei
> 

Code review request, 7188658 Add possibility to disable client initiated renegotiation

[Xuelei Fan]

Hi,

This fix is an enhancement to add the ability in JSSE server side to
reject client initialized renegotiation.

webrev: http://cr.openjdk.java.net/~xuelei/7188658/webrev.00/

Thanks,
Xuelei

Re: [8] 7174966: With OCSP enabled on Java 7 get error 'Wrong key usage' with Comodo certificate

[Vincent Ryan]

Right. The Comodo cert is certainly valid. I've modified the OCSP client to 
avoid the strict check.

On 29 May 2013, at 15:55, Matthew Hall wrote:

> Comodo used the root cert to sign the responses, which the RFC allows. I 
> think Java is getting carried away with strictness on this.
> -- 
> Sent from my mobile device.
> 
> Xuelei Fan  wrote:
> 
>> What's the key usage of the OCSP responder?  I think it is more like a
>> problem of Comodo CA.  This fix may loosen the checking of the validity
>> of the OCSP responder's certificate.
>> 
>> Xuelei
>> 
>> On 5/28/2013 7:30 PM, Vincent Ryan wrote:
>>> Please review the fix for:
>> http://bugs.sun.com/view_bug.do?bug_id=7174966
>>> 
>>> The problem occurs when validating the signature of an OCSP response
>> from the Comodo CA.
>>> The Signature class tests for the presence of the digitalSignature
>> keyUsage setting when examining
>>> a signer's certificate. One solution is for the
>> sun.security.provider.certpath.OCSPResponse class to
>>> pass the signer's public key rather than the signer's certificate.
>>> 
>>> Webrev: http://cr.openjdk.java.net/~vinnie/7174966/webrev.00/
>>> 
>>> Thanks.
>>> 
> 

Re: [8] 7174966: With OCSP enabled on Java 7 get error 'Wrong key usage' with Comodo certificate

[Matthew Hall]

Comodo used the root cert to sign the responses, which the RFC allows. I think 
Java is getting carried away with strictness on this.
-- 
Sent from my mobile device.

Xuelei Fan  wrote:

>What's the key usage of the OCSP responder?  I think it is more like a
>problem of Comodo CA.  This fix may loosen the checking of the validity
>of the OCSP responder's certificate.
>
>Xuelei
>
>On 5/28/2013 7:30 PM, Vincent Ryan wrote:
>> Please review the fix for:
>http://bugs.sun.com/view_bug.do?bug_id=7174966
>> 
>> The problem occurs when validating the signature of an OCSP response
>from the Comodo CA.
>> The Signature class tests for the presence of the digitalSignature
>keyUsage setting when examining
>> a signer's certificate. One solution is for the
>sun.security.provider.certpath.OCSPResponse class to
>> pass the signer's public key rather than the signer's certificate.
>> 
>> Webrev: http://cr.openjdk.java.net/~vinnie/7174966/webrev.00/
>> 
>> Thanks.
>> 

hg: jdk8/tl/jdk: 7174966: With OCSP enabled on Java 7 get error 'Wrong key usage' with Comodo certificate

[vincent . x . ryan]

Changeset: 00ad19610e75
Author:vinnie
Date:  2013-05-29 14:57 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/00ad19610e75

7174966: With OCSP enabled on Java 7 get error 'Wrong key usage' with Comodo 
certificate
Reviewed-by: xuelei

! src/share/classes/sun/security/provider/certpath/OCSPResponse.java

Re: [8] 7174966: With OCSP enabled on Java 7 get error 'Wrong key usage' with Comodo certificate

[Xuelei Fan]

You are welcome.

BTW, would you like to add a comment in the update so that we won't
tighten the check in the future unintentionally?

Xuelei

On 5/29/2013 9:52 PM, Vincent Ryan wrote:
> Thanks for your review.
> 
> On 29 May 2013, at 14:27, Xuelei Fan wrote:
> 
>> It's OK to me.
>>
>> At present. there is no risk I can see to loosen the check.  I just
>> worried that if we want to tighten the check again in the future, we may
>> run into compatibility issues.  But for now, it is fine to me.
>>
>> Thanks,
>> Xuelei
>>
>> On 5/29/2013 8:59 PM, Vincent Ryan wrote:
>>> The Comodo cert has the 'keyCertSign' and 'cRLSign' keyUsage bits set.
>>> That's unusual but permitted by RFC 5280.
>>>
>>> I could have changed the Signature.initVerify method to also accept that 
>>> combination of
>>> keyUsage bits but that would affect all signatures. Sean suggested the 
>>> approach where
>>> the OCSP client supplies the signer's public key rather than the signer's 
>>> cert.
>>>
>>> It does mean that the signer's 'digitalSignature' keyUsage bit is no longer 
>>> checked but
>>> since the RFC allows other bit combinations to be set then I think that 
>>> skipping that
>>> check is acceptable.
>>>
>>>
>>>
>>> On 29 May 2013, at 13:42, Xuelei Fan wrote:
>>>
 What's the key usage of the OCSP responder?  I think it is more like a
 problem of Comodo CA.  This fix may loosen the checking of the validity
 of the OCSP responder's certificate.

 Xuelei

 On 5/28/2013 7:30 PM, Vincent Ryan wrote:
> Please review the fix for: http://bugs.sun.com/view_bug.do?bug_id=7174966
>
> The problem occurs when validating the signature of an OCSP response from 
> the Comodo CA.
> The Signature class tests for the presence of the digitalSignature 
> keyUsage setting when examining
> a signer's certificate. One solution is for the 
> sun.security.provider.certpath.OCSPResponse class to
> pass the signer's public key rather than the signer's certificate.
>
> Webrev: http://cr.openjdk.java.net/~vinnie/7174966/webrev.00/
>
> Thanks.
>

>>>
>>
> 

Re: [8] 7174966: With OCSP enabled on Java 7 get error 'Wrong key usage' with Comodo certificate

[Vincent Ryan]

Thanks for your review.

On 29 May 2013, at 14:27, Xuelei Fan wrote:

> It's OK to me.
> 
> At present. there is no risk I can see to loosen the check.  I just
> worried that if we want to tighten the check again in the future, we may
> run into compatibility issues.  But for now, it is fine to me.
> 
> Thanks,
> Xuelei
> 
> On 5/29/2013 8:59 PM, Vincent Ryan wrote:
>> The Comodo cert has the 'keyCertSign' and 'cRLSign' keyUsage bits set.
>> That's unusual but permitted by RFC 5280.
>> 
>> I could have changed the Signature.initVerify method to also accept that 
>> combination of
>> keyUsage bits but that would affect all signatures. Sean suggested the 
>> approach where
>> the OCSP client supplies the signer's public key rather than the signer's 
>> cert.
>> 
>> It does mean that the signer's 'digitalSignature' keyUsage bit is no longer 
>> checked but
>> since the RFC allows other bit combinations to be set then I think that 
>> skipping that
>> check is acceptable.
>> 
>> 
>> 
>> On 29 May 2013, at 13:42, Xuelei Fan wrote:
>> 
>>> What's the key usage of the OCSP responder?  I think it is more like a
>>> problem of Comodo CA.  This fix may loosen the checking of the validity
>>> of the OCSP responder's certificate.
>>> 
>>> Xuelei
>>> 
>>> On 5/28/2013 7:30 PM, Vincent Ryan wrote:
 Please review the fix for: http://bugs.sun.com/view_bug.do?bug_id=7174966
 
 The problem occurs when validating the signature of an OCSP response from 
 the Comodo CA.
 The Signature class tests for the presence of the digitalSignature 
 keyUsage setting when examining
 a signer's certificate. One solution is for the 
 sun.security.provider.certpath.OCSPResponse class to
 pass the signer's public key rather than the signer's certificate.
 
 Webrev: http://cr.openjdk.java.net/~vinnie/7174966/webrev.00/
 
 Thanks.
 
>>> 
>> 
> 

Re: [8] 7174966: With OCSP enabled on Java 7 get error 'Wrong key usage' with Comodo certificate

[Xuelei Fan]

It's OK to me.

At present. there is no risk I can see to loosen the check.  I just
worried that if we want to tighten the check again in the future, we may
run into compatibility issues.  But for now, it is fine to me.

Thanks,
Xuelei

On 5/29/2013 8:59 PM, Vincent Ryan wrote:
> The Comodo cert has the 'keyCertSign' and 'cRLSign' keyUsage bits set.
> That's unusual but permitted by RFC 5280.
> 
> I could have changed the Signature.initVerify method to also accept that 
> combination of
> keyUsage bits but that would affect all signatures. Sean suggested the 
> approach where
> the OCSP client supplies the signer's public key rather than the signer's 
> cert.
> 
> It does mean that the signer's 'digitalSignature' keyUsage bit is no longer 
> checked but
> since the RFC allows other bit combinations to be set then I think that 
> skipping that
> check is acceptable.
> 
> 
> 
> On 29 May 2013, at 13:42, Xuelei Fan wrote:
> 
>> What's the key usage of the OCSP responder?  I think it is more like a
>> problem of Comodo CA.  This fix may loosen the checking of the validity
>> of the OCSP responder's certificate.
>>
>> Xuelei
>>
>> On 5/28/2013 7:30 PM, Vincent Ryan wrote:
>>> Please review the fix for: http://bugs.sun.com/view_bug.do?bug_id=7174966
>>>
>>> The problem occurs when validating the signature of an OCSP response from 
>>> the Comodo CA.
>>> The Signature class tests for the presence of the digitalSignature keyUsage 
>>> setting when examining
>>> a signer's certificate. One solution is for the 
>>> sun.security.provider.certpath.OCSPResponse class to
>>> pass the signer's public key rather than the signer's certificate.
>>>
>>> Webrev: http://cr.openjdk.java.net/~vinnie/7174966/webrev.00/
>>>
>>> Thanks.
>>>
>>
> 

Re: [8] 7174966: With OCSP enabled on Java 7 get error 'Wrong key usage' with Comodo certificate

[Vincent Ryan]

The Comodo cert has the 'keyCertSign' and 'cRLSign' keyUsage bits set.
That's unusual but permitted by RFC 5280.

I could have changed the Signature.initVerify method to also accept that 
combination of
keyUsage bits but that would affect all signatures. Sean suggested the approach 
where
the OCSP client supplies the signer's public key rather than the signer's cert.

It does mean that the signer's 'digitalSignature' keyUsage bit is no longer 
checked but
since the RFC allows other bit combinations to be set then I think that 
skipping that
check is acceptable.



On 29 May 2013, at 13:42, Xuelei Fan wrote:

> What's the key usage of the OCSP responder?  I think it is more like a
> problem of Comodo CA.  This fix may loosen the checking of the validity
> of the OCSP responder's certificate.
> 
> Xuelei
> 
> On 5/28/2013 7:30 PM, Vincent Ryan wrote:
>> Please review the fix for: http://bugs.sun.com/view_bug.do?bug_id=7174966
>> 
>> The problem occurs when validating the signature of an OCSP response from 
>> the Comodo CA.
>> The Signature class tests for the presence of the digitalSignature keyUsage 
>> setting when examining
>> a signer's certificate. One solution is for the 
>> sun.security.provider.certpath.OCSPResponse class to
>> pass the signer's public key rather than the signer's certificate.
>> 
>> Webrev: http://cr.openjdk.java.net/~vinnie/7174966/webrev.00/
>> 
>> Thanks.
>> 
> 

Re: Code Review Request: JEP 140 Limited doPrivileged

[Florian Weimer]

On 05/29/2013 07:56 AM, Jeff Nisewanger wrote:


The webrev is: http://cr.openjdk.java.net/~jdn/8014097/webrev.0/


The overloads make it cumbersome to use this feature with lambda 
expressions:


http://mail.openjdk.java.net/pipermail/security-dev/2013-May/007434.html

Could you rename the variant which take a PrivilegedExceptionAction 
argument to avoid this?


--
Florian Weimer / Red Hat Product Security Team

Re: [8] 7174966: With OCSP enabled on Java 7 get error 'Wrong key usage' with Comodo certificate

[Xuelei Fan]

What's the key usage of the OCSP responder?  I think it is more like a
problem of Comodo CA.  This fix may loosen the checking of the validity
of the OCSP responder's certificate.

Xuelei

On 5/28/2013 7:30 PM, Vincent Ryan wrote:
> Please review the fix for: http://bugs.sun.com/view_bug.do?bug_id=7174966
> 
> The problem occurs when validating the signature of an OCSP response from the 
> Comodo CA.
> The Signature class tests for the presence of the digitalSignature keyUsage 
> setting when examining
> a signer's certificate. One solution is for the 
> sun.security.provider.certpath.OCSPResponse class to
> pass the signer's public key rather than the signer's certificate.
> 
> Webrev: http://cr.openjdk.java.net/~vinnie/7174966/webrev.00/
> 
> Thanks.
> 

hg: jdk8/tl/langtools: 7053059: VerifyError with double Assignment using a Generic Member of a Superclass

[vicente . romero]

Changeset: 92e420e9807d
Author:vromero
Date:  2013-05-29 10:56 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/92e420e9807d

7053059: VerifyError with double Assignment using a Generic Member of a 
Superclass
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
+ test/tools/javac/T7053059/VerifyErrorWithDoubleAssignmentTest.java

hg: jdk8/tl/jdk: 8014928: (fs) Files.readAllBytes() copies content to new array when content completely read

[alan . bateman]

Changeset: 2b3242a69a44
Author:alanb
Date:  2013-05-29 10:24 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2b3242a69a44

8014928: (fs) Files.readAllBytes() copies content to new array when content 
completely read
Reviewed-by: martin

! src/share/classes/java/nio/file/Files.java

Re: 9001039?: DHKeyAgreement calculates wrong TlsPremasterSecret 1 out of 256 times

[Xuelei Fan]

Thank you for considering this improvement.  I'm planing to integrate
the patch into OpenJDK workspace this week.

Thanks & Regards,
Xuelei

On 5/29/2013 3:33 PM, Pasi Eronen wrote:
> Hi Xuelei,
> 
> I did notice that P11Util has a trimZeroes() function, but I didn't call 
> it since I didn't want to add a new package dependency. But now that you 
> mention it, moving it to KeyUtil seems like the best solution. 
> 
> I have submitted a revised patch to the Bugzilla ticket which does
> just this:
> 
> https://bugs.openjdk.java.net/attachment.cgi?id=307&action=diff
> 
> Best regards,
> Pasi
> 
> 
> 
> On Thu, May 23, 2013 at 1:39 PM, Xuelei Fan  > wrote:
> 
> 
> On 5/23/2013 6:03 PM, Andrew Hughes wrote:
> > - Original Message -
> >> On 5/20/2013 5:28 PM, Pasi Eronen wrote:
> >>> Hi Xuelei,
> >>>
> >>> It seems the PKSC11 doesn't actually have this bug.
> >>>
> >>> P11KeyAgreement has a separate code path for the
> "TlsPremasterSecret"
> >>> algorithm, which strips leading zeroes if the key can be
> extracted from
> >>> the token. (And if the key cannot be extracted, then the token
> is doing
> >>> the premaster secret->master secret computation, and has to do the
> >>> stripping -- it can't be done from the Java PKSC11 provider.)
> >>>
> >> It makes sense to me.
> >>
> >>> To make sure this behavior doesn't change, I added a test case
> >>> for the PKSC11 provider to the Bugzilla (which passes with the
> >>> "SunPKCS11-NSS" provider without any changes).
> >>>
> >> That's great.  Would you mind to contribute the regression test for
> >> PKCS11 provider?
> >>
> >
> > It's been attached to the bug report:
> https://bugs.openjdk.java.net/show_bug.cgi?id=100316
> >
> Thanks Andrew!
> 
> > Is there any reason the original patch can't be committed?  I
> haven't seen any mentioned.
> >
> It is accepted.  The minor comment I mentioned in the previous mail is
> that we may want to merge the functions to trim leading zeros in one
> method.
> 
> There is a method sun.security.pkcs11.P11Util.trimZeroes(byte[] b) which
> is used to trim leading zeros.  I think it would be nice to move the
> method to sun.security.util.KeyUtil, and make use of this method in the
> patch of DHKeyAgreement.engineGenerateSecret(String algorithm) as well.
> 
> Pasi, what do you think?
> 
> Otherwise, the patch looks fine to me.
> 
> I can be the sponsor if you won't able to merge the changes into openJDk
> workspace.
> 
> Thanks,
> Xuelei
> 
> >> Thanks,
> >> Xuelei
> >>
> >>> Best regards,
> >>> Pasi
> >>>
> >>>
> >>>
> >>> On Thu, May 16, 2013 at 10:56 AM, Xuelei Fan
> mailto:xuelei@oracle.com>
> >>> >>
> wrote:
> >>>
> >>> Hi Pasi,
> >>>
> >>> Thank you for your patience, and contribution to OpenJDK.
>  The bug is
> >>> accepted, and you should be able to review it at:
> >>>
> >>>http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014618
> >>>
> >>> Let's use the above bug ID to track the issue.
> >>>
> >>> Your patch looks fine in general (I may have some very minor
> comments
> >>> later).  We also have similar problems in PKCS11 provider
> because of
> >>> the
> >>> update of P11KeyAgreement.java in changeset:
> >>>
> >>>
> http://hg.openjdk.java.net/jdk7u/jdk7u-gate/jdk/rev/e574e475c8a6
> >>>
> >>> Would you like to also fix it in your patch?
> >>>
> >>> Thanks again for your nice work.
> >>>
> >>> Regards,
> >>> Xuelei
> >>>
> >>>
> >>> On 5/10/2013 5:00 PM, Pasi Eronen wrote:
> >>> > AKA "1 out of 256 SSL/TLS handshakes fails with DHE cipher
> suites"
> >>> >
> >>> > I reported this bug over a month of ago, but for some
> reason, it's
> >>> > not
> >>> > yet visible at bugs.sun.com 
> 
> >>> . I've included the bug
> >>> > report below just in
> >>> > case.
> >>> >
> >>> > It seems this commit from March 2012 inadvertently broke
> SSL/TLS DHE
> >>> > cipher suites, causing the SSL/TLS handshake to fail
> approximately
> >>> > 1 out of 256 times:
> >>> >
> >>> >
> http://hg.openjdk.java.net/jdk7u/jdk7u-gate/jdk/rev/e574e475c8a6
> >>> >
> >>> > The commit was done to fix this bug:
> >>> >
> >>> > http://bugs.sun.com/view_bug.do?bug_id=7146728
> >>> >
> >>> > While generating a secret of the same length as modulus
> may be the
> >>> right
> >>> > choice generall

Re: 9001039?: DHKeyAgreement calculates wrong TlsPremasterSecret 1 out of 256 times

[Pasi Eronen]

Hi Xuelei,

I did notice that P11Util has a trimZeroes() function, but I didn't call
it since I didn't want to add a new package dependency. But now that you
mention it, moving it to KeyUtil seems like the best solution.

I have submitted a revised patch to the Bugzilla ticket which does
just this:

https://bugs.openjdk.java.net/attachment.cgi?id=307&action=diff

Best regards,
Pasi



On Thu, May 23, 2013 at 1:39 PM, Xuelei Fan  wrote:

>
> On 5/23/2013 6:03 PM, Andrew Hughes wrote:
> > - Original Message -
> >> On 5/20/2013 5:28 PM, Pasi Eronen wrote:
> >>> Hi Xuelei,
> >>>
> >>> It seems the PKSC11 doesn't actually have this bug.
> >>>
> >>> P11KeyAgreement has a separate code path for the "TlsPremasterSecret"
> >>> algorithm, which strips leading zeroes if the key can be extracted from
> >>> the token. (And if the key cannot be extracted, then the token is doing
> >>> the premaster secret->master secret computation, and has to do the
> >>> stripping -- it can't be done from the Java PKSC11 provider.)
> >>>
> >> It makes sense to me.
> >>
> >>> To make sure this behavior doesn't change, I added a test case
> >>> for the PKSC11 provider to the Bugzilla (which passes with the
> >>> "SunPKCS11-NSS" provider without any changes).
> >>>
> >> That's great.  Would you mind to contribute the regression test for
> >> PKCS11 provider?
> >>
> >
> > It's been attached to the bug report:
> https://bugs.openjdk.java.net/show_bug.cgi?id=100316
> >
> Thanks Andrew!
>
> > Is there any reason the original patch can't be committed?  I haven't
> seen any mentioned.
> >
> It is accepted.  The minor comment I mentioned in the previous mail is
> that we may want to merge the functions to trim leading zeros in one
> method.
>
> There is a method sun.security.pkcs11.P11Util.trimZeroes(byte[] b) which
> is used to trim leading zeros.  I think it would be nice to move the
> method to sun.security.util.KeyUtil, and make use of this method in the
> patch of DHKeyAgreement.engineGenerateSecret(String algorithm) as well.
>
> Pasi, what do you think?
>
> Otherwise, the patch looks fine to me.
>
> I can be the sponsor if you won't able to merge the changes into openJDk
> workspace.
>
> Thanks,
> Xuelei
>
> >> Thanks,
> >> Xuelei
> >>
> >>> Best regards,
> >>> Pasi
> >>>
> >>>
> >>>
> >>> On Thu, May 16, 2013 at 10:56 AM, Xuelei Fan  >>> > wrote:
> >>>
> >>> Hi Pasi,
> >>>
> >>> Thank you for your patience, and contribution to OpenJDK.  The bug
> is
> >>> accepted, and you should be able to review it at:
> >>>
> >>>http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014618
> >>>
> >>> Let's use the above bug ID to track the issue.
> >>>
> >>> Your patch looks fine in general (I may have some very minor
> comments
> >>> later).  We also have similar problems in PKCS11 provider because
> of
> >>> the
> >>> update of P11KeyAgreement.java in changeset:
> >>>
> >>>
> http://hg.openjdk.java.net/jdk7u/jdk7u-gate/jdk/rev/e574e475c8a6
> >>>
> >>> Would you like to also fix it in your patch?
> >>>
> >>> Thanks again for your nice work.
> >>>
> >>> Regards,
> >>> Xuelei
> >>>
> >>>
> >>> On 5/10/2013 5:00 PM, Pasi Eronen wrote:
> >>> > AKA "1 out of 256 SSL/TLS handshakes fails with DHE cipher
> suites"
> >>> >
> >>> > I reported this bug over a month of ago, but for some reason,
> it's
> >>> > not
> >>> > yet visible at bugs.sun.com 
> >>> . I've included the bug
> >>> > report below just in
> >>> > case.
> >>> >
> >>> > It seems this commit from March 2012 inadvertently broke SSL/TLS
> DHE
> >>> > cipher suites, causing the SSL/TLS handshake to fail
> approximately
> >>> > 1 out of 256 times:
> >>> >
> >>> > http://hg.openjdk.java.net/jdk7u/jdk7u-gate/jdk/rev/e574e475c8a6
> >>> >
> >>> > The commit was done to fix this bug:
> >>> >
> >>> > http://bugs.sun.com/view_bug.do?bug_id=7146728
> >>> >
> >>> > While generating a secret of the same length as modulus may be
> the
> >>> right
> >>> > choice generally speaking (and it's what e.g. IPsec uses),
> SSL/TLS
> >>> uses
> >>> > a different convention: leading zeroes must be stripped.
> >>> >
> >>> > This is currently blocking us from updating our production
> systems to
> >>> > Java 7, so although I have not contributed to OpenJDK before, I'd
> >>> > like
> >>> > to submit a patch and a test case for this (I've signed the OCA
> >>> > already). But before I do this, I'd like to check that the
> approach
> >>> > is
> >>> > agreeable.
> >>> >
> >>> > We have a separate "algorithm" value "TlsPremasterSecret", so
> >>> > behavior for other cases could stay the same. Would a patch
> >>> > like this:
> >>> >
> >>> > } else if (algorithm.equals("TlsPremasterSecret")) {
> >>> > // remove leading zero bytes