Re: PKCS11 generateKeyPair with alias
I would expect you can actually store the key on a PKCS11 backed Keystore, what would be the natural API (although it’s hard for the provider to implement it if it can’t use temporary handles like this) Gruss Bernd -- http://bernd.eckenfels.net Von: -989298816m Auftrag von Gesendet: Montag, August 27, 2018 2:01 AM An: security-dev@openjdk.java.net Betreff: PKCS11 generateKeyPair with alias Hi, There is a long standing issue (since the beginning) with keyPairGeneration in the Sun PKCS#11 provider, but I thought it's time to vent it. KeyPairGenerator.generateKeyPair() only generates a keyPair, and does not set any alias or ID on the key. You can set an alias by using a sun config file adding CKA_LABEL to it, but that oinly works for short running application, i.e. a single key generation. In a long running application that generates multiple keys this is not possible since one config file is used throughout the whole Provider lifetime. Did anyone solve this problem? I just played with a patch to Java/SunP11 to add a new method KeyPairGenerator.generateKeyPair(String alias). This does work, but it's really ugly, and nobody want to run a patched Java version. Did anyone else think about this? Kind regards, Tomas
PKCS11 generateKeyPair with alias
Hi, There is a long standing issue (since the beginning) with keyPairGeneration in the Sun PKCS#11 provider, but I thought it's time to vent it. KeyPairGenerator.generateKeyPair() only generates a keyPair, and does not set any alias or ID on the key. You can set an alias by using a sun config file adding CKA_LABEL to it, but that oinly works for short running application, i.e. a single key generation. In a long running application that generates multiple keys this is not possible since one config file is used throughout the whole Provider lifetime. Did anyone solve this problem? I just played with a patch to Java/SunP11 to add a new method KeyPairGenerator.generateKeyPair(String alias). This does work, but it's really ugly, and nobody want to run a patched Java version. Did anyone else think about this? Kind regards, Tomas
Re: Code Review Request JDK-8209965 : The "supported_groups" extension in ServerHellos
The change looks fine but I have a question about restricting it. This sounds like a problem with servers using 1.2 or before, does it make sense to throw an error for 1.3? I don’t like allowing buggy implementation to continue because we will never be able to undo this workaround. It would be nice if when someday 1.2 is removed, this change won’t persist in our code base. I realize this maybe a lot to ask given the decision of the protocol version hasn’t been made yet I believe. If it’s unreasonable, that is ok. I’m fine with the change as is. Tony > On Aug 26, 2018, at 7:39 AM, Xuelei Fan wrote: > > Hi, > > Please review a compatibility fix for SunJSSE provider: >http://cr.openjdk.java.net/~xuelei/8209965/webrev.00 > > There are servers that send the supported_groups extension in the ServerHello > handshake message. It does not comply to the specification. However, as > there are a few deployments already with the buggy implementation, we may > want to tolerate this behavior in JDK. > > Note that although this extension is allowed in the ServerHello, it should be > ignored and have no impact on the client behavior. > > The problem was reported and the fix was tested in OopenJDK: > http://mail.openjdk.java.net/pipermail/security-dev/2018-August/018005.html > > > Thanks, > Xuelei
Code Review Request JDK-8209965 : The "supported_groups" extension in ServerHellos
Hi, Please review a compatibility fix for SunJSSE provider: http://cr.openjdk.java.net/~xuelei/8209965/webrev.00 There are servers that send the supported_groups extension in the ServerHello handshake message. It does not comply to the specification. However, as there are a few deployments already with the buggy implementation, we may want to tolerate this behavior in JDK. Note that although this extension is allowed in the ServerHello, it should be ignored and have no impact on the client behavior. The problem was reported and the fix was tested in OopenJDK: http://mail.openjdk.java.net/pipermail/security-dev/2018-August/018005.html Thanks, Xuelei
Re: Java 11 RC build - HTTPS handshake failure against a previously working server
Thanks for the test!
Xuelei
On 8/26/2018 6:19 AM, Jaikiran Pai wrote:
I have now applied the patch to the JDK11 repo on top of:
hg sum
parent: 51151:1ddf9a99e4ad tip
Added tag jdk-11+28 for changeset 76072a077ee1
branch: default
and built the new images and run the testsuite against this version. The
tests passed without any issues. Ran the sample code from my original
mail, against this patched JDK 11 version and that too passed.
-Jaikiran
On 25/08/18 9:58 PM, Jaikiran Pai wrote:
Hi Xuelei,
I had the JDK 12 repo checked out already with the latest code as of today:
hg sum
parent: 51538:a716460217ed
8209911: More blob types in hs_err printout
branch: default
I applied the patch you had attached in this thread against this and
built it afresh.
With this new image, I was able to run the Apache Ant testsuite (the one
which was originally and still fails with JDK 11 RC build) without any
issues. I even ran the sample program that I had listed in this thread
against this patched 12.x build and that too went fine. I verified that
the patch has indeed taken effect by enabling javax.net.debug logging
and I do indeed see the new log:
javax.net.ssl|DEBUG|01|main|2018-08-25 21:20:57.860
IST|PreSharedKeyExtension.java:606|No session to resume.
javax.net.ssl|DEBUG|01|main|2018-08-25 21:20:57.860
IST|SSLExtensions.java:250|Ignore, context unavailable extension:
pre_shared_key
javax.net.ssl|DEBUG|01|main|2018-08-25 21:20:57.864
IST|ClientHello.java:633|Produced ClientHello handshake message (
"ClientHello": {
"client version" : "TLSv1.2",
}
)
javax.net.ssl|DEBUG|01|main|2018-08-25 21:20:57.865
IST|SSLSocketOutputRecord.java:241|WRITE: TLS13 handshake, length = 446
javax.net.ssl|DEBUG|01|main|2018-08-25 21:20:58.664
IST|SSLSocketInputRecord.java:213|READ: TLSv1.2 handshake, length = 99
javax.net.ssl|DEBUG|01|main|2018-08-25 21:20:58.664
IST|SSLSocketInputRecord.java:249|READ: TLSv1.2 handshake, length = 99
javax.net.ssl|WARNING|01|main|2018-08-25 21:20:58.665
IST|SSLExtensions.java:79|Buggy supported_groups in ServerHello
javax.net.ssl|DEBUG|01|main|2018-08-25 21:20:58.667
IST|ServerHello.java:862|Consuming ServerHello handshake message (
"ServerHello": {
"server version" : "TLSv1.2",
"random" : "4C 62 53 A1 56 4D 82 EE 3A 44 E3 25 0D 2F BD
CB 02 EE FD 3B 8E 4E D1 2B 52 5F AD 5B 0B B5 BC 98",
"session id" : "A9 BC 19 7D 36 84 25 F8 6B 77 3F 1D 93 5E B4
52 DE AE 41 90 67 2B F2 80 BB 85 3B BE 36 A1 F3 1C",
"cipher suite" : "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384(0xC030)",
"compression methods" : "00",
"extensions" : [
"renegotiation_info (65,281)": {
"renegotiated connection": []
},
"server_name (0)": {
},
"ec_point_formats (11)": {
"formats": [uncompressed]
}
]
}
)
As for trying this against the JDK 11 repo, I have initiated a clone,
but it's going to take a while (as expected). I don't expect it to
finish soon, so I'm going to let it clone overnight and I will apply
this patch against that repo too and run this same testsuite against it.
I don't expect it to fail but I just want to make sure there aren't any
surprises. I will send out a note once that's done tomorrow.
I'll anyway be running some more extensive testsuites, over the next few
days, with this patched version and see how it goes.
Thank you very much for the quick response and the patch.
-Jaikiran
On 25/08/18 8:18 PM, Xuelei Fan wrote:
Hi Jaikiran,
Thank you very much for the help!
JDK 12 repo (JDK repo):
http://hg.openjdk.java.net/jdk/jdk
JDK 11 repo:
http://hg.openjdk.java.net/jdk/jdk11
The patch should work for both repositories.
Thanks,
Xuelei
On 8/25/2018 7:44 AM, Jaikiran Pai wrote:
Hi Xuelei,
I can definitely build JDK 12 (jdk repo) from source and apply your
attached patch and give it a try. As for JDK 11, I haven't been
following the version control discussions/process, does it have a
separate repo now? Or is it some branch within jdk repo itself? Either
way, once I know the right repo location, I can (and in fact prefer)
building that repo with this patch to give it a try.
-Jaikiran
On 25/08/18 8:10 PM, Xuelei Fan wrote:
Hi Jaikiran,
Could you build JDK 11 or JDK 12 from source code? I had a patch to
tolerate the extension in ServerHello handshake message. Please let
me know if it works or not.
If there are any other JDK 11 TLS problems with Apache Ant project,
I'd like to know as well.
Thanks,
Xuelei
On 8/25/2018 7:04 AM, Jaikiran Pai wrote:
Hi Xuelei,
On 25/08/18 7:20 PM, Xuelei Fan wrote:
Sending "supported_groups" in ServerHello does not comply to the
extension specification.
Agreed. However, given that both the client and server are using
TLSv1.2
and this seems to be "working" before the newer TLSv1.3 changes,
even in
recent JDK versions, is there a way the implementation could
workaround
this so as to allow JDK 11 to communicate with such servers?
Is i
Re: Java 11 RC build - HTTPS handshake failure against a previously working server
I have now applied the patch to the JDK11 repo on top of:
hg sum
parent: 51151:1ddf9a99e4ad tip
Added tag jdk-11+28 for changeset 76072a077ee1
branch: default
and built the new images and run the testsuite against this version. The
tests passed without any issues. Ran the sample code from my original
mail, against this patched JDK 11 version and that too passed.
-Jaikiran
On 25/08/18 9:58 PM, Jaikiran Pai wrote:
> Hi Xuelei,
>
> I had the JDK 12 repo checked out already with the latest code as of today:
>
> hg sum
> parent: 51538:a716460217ed
> 8209911: More blob types in hs_err printout
> branch: default
>
> I applied the patch you had attached in this thread against this and
> built it afresh.
>
> With this new image, I was able to run the Apache Ant testsuite (the one
> which was originally and still fails with JDK 11 RC build) without any
> issues. I even ran the sample program that I had listed in this thread
> against this patched 12.x build and that too went fine. I verified that
> the patch has indeed taken effect by enabling javax.net.debug logging
> and I do indeed see the new log:
>
> javax.net.ssl|DEBUG|01|main|2018-08-25 21:20:57.860
> IST|PreSharedKeyExtension.java:606|No session to resume.
> javax.net.ssl|DEBUG|01|main|2018-08-25 21:20:57.860
> IST|SSLExtensions.java:250|Ignore, context unavailable extension:
> pre_shared_key
> javax.net.ssl|DEBUG|01|main|2018-08-25 21:20:57.864
> IST|ClientHello.java:633|Produced ClientHello handshake message (
> "ClientHello": {
> "client version" : "TLSv1.2",
>
> }
> )
>
> javax.net.ssl|DEBUG|01|main|2018-08-25 21:20:57.865
> IST|SSLSocketOutputRecord.java:241|WRITE: TLS13 handshake, length = 446
> javax.net.ssl|DEBUG|01|main|2018-08-25 21:20:58.664
> IST|SSLSocketInputRecord.java:213|READ: TLSv1.2 handshake, length = 99
> javax.net.ssl|DEBUG|01|main|2018-08-25 21:20:58.664
> IST|SSLSocketInputRecord.java:249|READ: TLSv1.2 handshake, length = 99
> javax.net.ssl|WARNING|01|main|2018-08-25 21:20:58.665
> IST|SSLExtensions.java:79|Buggy supported_groups in ServerHello
> javax.net.ssl|DEBUG|01|main|2018-08-25 21:20:58.667
> IST|ServerHello.java:862|Consuming ServerHello handshake message (
> "ServerHello": {
> "server version" : "TLSv1.2",
> "random" : "4C 62 53 A1 56 4D 82 EE 3A 44 E3 25 0D 2F BD
> CB 02 EE FD 3B 8E 4E D1 2B 52 5F AD 5B 0B B5 BC 98",
> "session id" : "A9 BC 19 7D 36 84 25 F8 6B 77 3F 1D 93 5E B4
> 52 DE AE 41 90 67 2B F2 80 BB 85 3B BE 36 A1 F3 1C",
> "cipher suite" : "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384(0xC030)",
> "compression methods" : "00",
> "extensions" : [
> "renegotiation_info (65,281)": {
> "renegotiated connection": []
> },
> "server_name (0)": {
>
> },
> "ec_point_formats (11)": {
> "formats": [uncompressed]
> }
> ]
> }
> )
>
>
> As for trying this against the JDK 11 repo, I have initiated a clone,
> but it's going to take a while (as expected). I don't expect it to
> finish soon, so I'm going to let it clone overnight and I will apply
> this patch against that repo too and run this same testsuite against it.
> I don't expect it to fail but I just want to make sure there aren't any
> surprises. I will send out a note once that's done tomorrow.
>
> I'll anyway be running some more extensive testsuites, over the next few
> days, with this patched version and see how it goes.
>
> Thank you very much for the quick response and the patch.
>
> -Jaikiran
>
> On 25/08/18 8:18 PM, Xuelei Fan wrote:
>> Hi Jaikiran,
>>
>> Thank you very much for the help!
>>
>> JDK 12 repo (JDK repo):
>> http://hg.openjdk.java.net/jdk/jdk
>>
>> JDK 11 repo:
>> http://hg.openjdk.java.net/jdk/jdk11
>>
>> The patch should work for both repositories.
>>
>> Thanks,
>> Xuelei
>>
>>
>> On 8/25/2018 7:44 AM, Jaikiran Pai wrote:
>>> Hi Xuelei,
>>>
>>> I can definitely build JDK 12 (jdk repo) from source and apply your
>>> attached patch and give it a try. As for JDK 11, I haven't been
>>> following the version control discussions/process, does it have a
>>> separate repo now? Or is it some branch within jdk repo itself? Either
>>> way, once I know the right repo location, I can (and in fact prefer)
>>> building that repo with this patch to give it a try.
>>>
>>> -Jaikiran
>>>
>>>
>>> On 25/08/18 8:10 PM, Xuelei Fan wrote:
Hi Jaikiran,
Could you build JDK 11 or JDK 12 from source code? I had a patch to
tolerate the extension in ServerHello handshake message. Please let
me know if it works or not.
If there are any other JDK 11 TLS problems with Apache Ant project,
I'd like to know as well.
Thanks,
Xuelei
On 8/25/2018 7:04 AM, Jaikiran Pai wrote:
> Hi Xuelei,
>
>
> On 25/08/18 7:20 PM, Xuelei Fan wrote:
>> Sending "supported_groups" in ServerHello does not comply to the
>> extension specification.
> Agreed. However, given that both the client
