DSA with keylength > 1024 no longer accepted (jdk7u-dev Digest, Vol 43, Issue 8)

Seán Coffey sean.coffey at oracle.com
Mon Jan 19 15:50:13 UTC 2015


Peter,

the issue you reference isn't a problem in jdk7u. - for the Oracle JDK 
at least. The code snippet your refer to is from jdk8 source code. The 
key length restriction was initially introduced as a side effect of this 
fix in JDK 8 https://bugs.openjdk.java.net/browse/JDK-7044060

That said, the version string you pasted makes it look like you're 
running IcedTea from Redhat. My earlier assumptions were that you were 
running OpenJDK binary based on the jdk7u sources 
(http://hg.openjdk.java.net/jdk7u/jdk7u/jdk) - If IcedTea has ported 
JDK-7044060 to their code base, you might have to contact them. Best to 
follow up on distro-pkg-dev at openjdk.java.net

regards,
Sean.

On 19/01/15 15:21, Peter Haraldson wrote:
>
>
> Thanks, I have now subscribed to security-dev as well. To keep the 
> thread intact I still reply here.
>
> Our java version would be JDK 7 I suppose - reported java version 
> "1.7.0_65".
>
> I checked your link, and I can see this issue will be resolved in JDK 
> 8 & 9, but I could not find anything about this issue with JDK 7.
> If it's not to be fixed in JDK 7 then we will need to upgrade.
>
> Kind regards
> Peter
>
>
>>
>> Message: 3
>> Date: Thu, 15 Jan 2015 10:28:46 +0000
>> From: Se?n Coffey <sean.coffey at oracle.com>
>> To: Peter Haraldson <peter at certitrade.net>
>> Cc: Security OpenJDK <security-dev at openjdk.java.net>
>> Subject: Re: DSA with keylength > 1024 no longer accepted
>> Message-ID: <54B7965E.8010109 at oracle.com>
>> Content-Type: text/plain; charset=windows-1252; format=flowed
>>
>> Hi Peter,
>>
>> security-dev is best mailing list to discuss this issue, I'm cc'ing that
>> list and bcc'ing off jdk7u-dev.
>>
>> Are you hitting this issue with JDK 8 and later ? (I'll assume so) -
>> You've hit https://bugs.openjdk.java.net/browse/JDK-8039921
>> To aid compatibility, it's been decided to relax that restriction from
>> 8u60 and later. See comments in bug report around use of SHA1 and SHA2
>> and the length of keys that should be used in each operation.
>>
>> Hope that helps.
>> regards,
>> Sean.
>>
>> On 15/01/2015 10:10, Peter Haraldson wrote:
>>> Hi
>>> First, I'm not quite sure if this is the correct list for this issue,
>>> please excuse & correct me if it's not.
>>>
>>> Our problem is that in latest openjdk a check is added that makes our
>>> certificates with DSA & Keylength 2048 unusable. In file
>>> "sun.security.provider.DSA" line 484-489:
>>>       protected void checkKey(DSAParams params) throws
>>> InvalidKeyException {
>>>              int valueL = params.getP().bitLength();
>>>              if (valueL > 1024) {
>>>                  throw new InvalidKeyException("Key is too long for
>>> this algorithm");
>>>              }
>>>          }
>>> This is new, these certificates worked fine before. I don't know the
>>> reason for not accepting longer keys than 1024, not allowing too short
>>> keys would make sense to me but not allowing long keys?
>>>
>>> We need to find a permanent solution, as for now we can't update our
>>> production servers because of this. We have several certificates
>>> issued by MasterCard, it is a very tedious job to change them all.
>>> Is there a way we could bypass this, could this check be abandoned in
>>> next update?
>>>
>>> Our system:
>>> java version "1.7.0_65" (not affected)
>>> OpenJDK Runtime Environment (rhel-2.5.1.2.el6_5-x86_64 u65-b17)
>>> OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)
>>> OS: RedHat 6.6
>>>
>>> Regards Peter
>>
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Thu, 15 Jan 2015 11:02:48 +0000
>> From: kevin.walls at oracle.com
>> To: jdk7u-dev at openjdk.java.net
>> Subject: hg: jdk7u/jdk7u-dev/hotspot: 8042235: redefining method used
>>     by    multiple MethodHandles crashes VM
>> Message-ID: <201501151102.t0FB2mNa002494 at aojmv0008>
>>
>> Changeset: e99b6986875c
>> Author:    kevinw
>> Date:      2015-01-15 09:12 +0000
>> URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/e99b6986875c
>>
>> 8042235: redefining method used by multiple MethodHandles crashes VM
>> Reviewed-by: coleenp, sspitsyn
>>
>> ! src/share/vm/classfile/javaClasses.cpp
>> ! src/share/vm/classfile/javaClasses.hpp
>> ! src/share/vm/oops/cpCacheOop.cpp
>> ! src/share/vm/oops/instanceKlass.cpp
>> ! src/share/vm/oops/instanceKlass.hpp
>> ! src/share/vm/prims/jvm.cpp
>> ! src/share/vm/prims/methodHandles.cpp
>> ! src/share/vm/prims/methodHandles.hpp
>> + 
>> test/compiler/jsr292/RedefineMethodUsedByMultipleMethodHandlesNoASM.java
>>
>>
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Thu, 15 Jan 2015 12:09:30 +0000
>> From: Se?n Coffey <sean.coffey at oracle.com>
>> To: "Valery Kopylov (Akvelon)" <v-valkop at microsoft.com>,    "Martin
>>     Sawicki (MS OPEN TECH)" <marcins at microsoft.com>,
>>     "jdk7u-dev at openjdk.java.net" <jdk7u-dev at openjdk.java.net>
>> Cc: "Kirk Shoop \(MS OPEN TECH\)" <Kirk.Shoop at microsoft.com>
>> Subject: Re: Backporting the TCP loopback fast path (Windows)
>>     improvement    to OpenJDK v7
>> Message-ID: <54B7ADFA.4030906 at oracle.com>
>> Content-Type: text/plain; charset=windows-1252; format=flowed
>>
>> Valeriy,
>>
>> I used the jdk7u patch that was attached to the mail request. It applied
>> cleanly. I've posted webrev here for reference (patch there also):
>> http://cr.openjdk.java.net/~coffeys/webrev.8060170.7u/webrev/
>>
>> The new WSAIoctl call would appear to be failing with WSAEINVAL. The
>> NET_EnableFastTcpLoopback call already tests for WSAEOPNOTSUPP - maybe
>> we should test for WSAEINVAL also and perhaps return silently if windows
>> don't support the option. Or maybe - we state this as desired behaviour
>> - i.e this option is suitable for modern windows kernels - your note
>> below would contradict what I'm seeing though.
>>
>> The test passes for me on Windows 7 and fails on Windows XP.
>>
>> regards,
>> Sean.
>>
>> On 15/01/2015 11:15, Valery Kopylov (Akvelon) wrote:
>>> Hi Sean,
>>>
>>> Our TCP loopback implementation should process the option correctly 
>>> on older windows kernels. I tried to reproduce the issue, but it 
>>> works fine on my side. So I have an assumption that part of the code 
>>> present on jdk9 patch has been lost and this causes such errors.
>>> Did you use the patch for jdk7 sent by Martin or perform the 
>>> backporting from jdk8 or 9 by yourself?
>>> Could you please send me output of "hg diff" command in jdk folder?
>>>
>>>
>>> Best regards,
>>> Valeriy Kopylov
>>>
>>> -----Original Message-----
>>> From: Se?n Coffey [mailto:sean.coffey at oracle.com]
>>> Sent: Tuesday, January 13, 2015 22:31
>>> To: Martin Sawicki (MS OPEN TECH); jdk7u-dev at openjdk.java.net
>>> Cc: Valery Kopylov (Akvelon); Kirk Shoop (MS OPEN TECH); Alan Bateman
>>> Subject: Re: Backporting the TCP loopback fast path (Windows) 
>>> improvement to OpenJDK v7
>>>
>>> Hi Martin,
>>>
>>> I've run into a problem in backporting this to JDK 7u. The test 
>>> fails on our build/test systems. (windows XP) -
>>>> reason: User specified action: run main/othervm
>>>> -Djdk.net.useFastTcpLoopback StressLoopback elapsed time (seconds):
>>>> 0.64
>>>> STDOUT:
>>>> STDERR:
>>>> java.net.SocketException: Invalid argument: fastLoopback
>>>>     at sun.nio.ch.Net.socket0(Native Method)
>>>>     at sun.nio.ch.Net.serverSocket(Net.java:445)
>>>>     at 
>>>> sun.nio.ch.AsynchronousServerSocketChannelImpl.<init>(AsynchronousServerSocketChannelImpl.java:71)
>>>>     at 
>>>> sun.nio.ch.WindowsAsynchronousServerSocketChannelImpl.<init>(WindowsAsynchronousServerSocketChannelImpl.java:69)
>>>>     at 
>>>> sun.nio.ch.WindowsAsynchronousChannelProvider.openAsynchronousServerSocketChannel(WindowsAsynchronousChannelProvider.java:83)
>>>>     at 
>>>> java.nio.channels.AsynchronousServerSocketChannel.open(AsynchronousServerSocketChannel.java:140)
>>>>     at 
>>>> java.nio.channels.AsynchronousServerSocketChannel.open(AsynchronousServerSocketChannel.java:161)
>>>>     at StressLoopback.main(StressLoopback.java:42)
>>> This seems to be from the fact that the new SIO_LOOPBACK_FAST_PATH 
>>> IOCTL code is only supported on more modern windows systems. I'm 
>>> wondering if we should change the src code to not attempt to use 
>>> this option on older windows kernels or if I should just modify the 
>>> testcase to not run the test on older windows systems ?
>>>
>>> regards,
>>> Sean.
>>>
>>>
>>>
>>> On 09/01/2015 16:25, Martin Sawicki (MS OPEN TECH) wrote:
>>>> Sean, thank you for the update and your assistance. Looking forward.
>>>>
>>>> -----Original Message-----
>>>> From: Se?n Coffey [mailto:sean.coffey at oracle.com]
>>>> Sent: Friday, January 09, 2015 8:24 AM
>>>> To: Martin Sawicki (MS OPEN TECH); jdk7u-dev at openjdk.java.net
>>>> Cc: Valery Kopylov (Akvelon); Kirk Shoop (MS OPEN TECH)
>>>> Subject: Re: Backporting the TCP loopback fast path (Windows)
>>>> improvement to OpenJDK v7
>>>>
>>>> Hey Martin,
>>>>
>>>> I can help in getting this enhancement ported to jdk7u-dev. I'm 
>>>> just waiting on approval for use of new system property in jdk7u 
>>>> release.
>>>> Once I have that, I can get this in.
>>>>
>>>> regards,
>>>> Sean.
>>>>
>>>> On 08/01/15 20:01, Martin Sawicki (MS OPEN TECH) wrote:
>>>>> Hello again,
>>>>> We'd like to propose to back-port our TCP loopback fast path 
>>>>> performance improvement for Windows that was recently accepted 
>>>>> into OpenJDK v9 and v8 into v7.
>>>>> Just for reference, the original OpenJDK v9 fix just for reference 
>>>>> can be found here: 
>>>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/26e6402772c8.
>>>>>
>>>>> Our suggested webrev patch file for OpenJDK *v7* is attached to 
>>>>> this message, based on our understanding of the back-porting steps.
>>>>>
>>>>> Your review and acceptance of this contribution would be appreciated.
>>>>>
>>>>> Best regards,
>>>>> Martin Sawicki (and Kirk Shoop, and Valeriy Kopylov) Microsoft Open
>>>>> Technologies, Inc.
>>>>> A subsidiary of Microsoft Corp.
>>>>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 6
>> Date: Thu, 15 Jan 2015 11:25:25 -0600
>> From: Paul Nauman <paul.nauman at oracle.com>
>> To: jdk7u-dev at openjdk.java.net
>> Subject: [7u-dev] Request for approval: 8020829: NMT tests fail on
>>     platforms    if NMT detail is not supported
>> Message-ID: <54B7F805.1090802 at oracle.com>
>> Content-Type: text/plain; charset=UTF-8; format=flowed
>>
>> Would like to push this trivial backport to correct test failures.
>>
>> Bug: 8020829 (Confidential) - NMT tests fail on platforms if NMT detail
>> is not supported.
>> hs25 changeset:
>> http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5fd8e2fbafd4
>> Reviewed by: chris.plummer at oracle.com
>>
>> - Paul
>>
>>
>>
>> ------------------------------
>>
>> Message: 7
>> Date: Thu, 15 Jan 2015 19:33:19 +0100
>> From: dalibor topic <dalibor.topic at oracle.com>
>> To: "jdk7u-dev at openjdk.java.net" <jdk7u-dev at openjdk.java.net>
>> Subject: [7u communication] RDP2 milestone for 7u80 approaching
>> Message-ID: <54B807EF.8000809 at oracle.com>
>> Content-Type: text/plain; charset=utf-8; format=flowed
>>
>> As per earlier communication [1], RDP2 for jdk7u80 is approaching. It
>> looks like 7u80 b05 (planned for the week of January 21st) will be the
>> last 7u80 promotion built from the jdk7u repo.
>>
>> After January 21st, RDP2 will start.
>>
>> cheers,
>> dalibor topic
>>
>> [1]
>> http://mail.openjdk.java.net/pipermail/jdk7u-dev/2014-December/010126.html 
>>
>>
>



More information about the security-dev mailing list