RFR[8u] JDK-8157035: Use stronger algorithms and keys for JSSE testing
Hi,
Please review this patch for "JDK-8157035: Use stronger algorithms and keys for
JSSE testing"
Issue:
https://bugs.openjdk.java.net/browse/JDK-8157035
Webrev:
HYPERLINK
"http://cr.openjdk.java.net/%7Ecoffeys/webrev.8157035.jdk8u/"http://cr.openjdk.java.net/~coffeys/webrev.8157035.jdk8u/
Changes:
sun/security/ssl/etc/truststore and truststore are having old certs with weaker
algorithms. Due to this, in some of the tests,
"jdk.certpath.disabledAlgorithms" property is hardcoded with empty string("").
It's not direct backport. Following changes are made in addition to JDK9
changes.
- Removed hardcoded value for jdk.certpath.disabledAlgorithms property
in bellow test files.
o test/javax/net/ssl/ciphersuites/DisabledAlgorithms.java
o test/sun/security/ssl/sanity/interop/ClientJSSEServerJSSE.java
Thanks,
Prasad.K
RE: [8u] RFR: 8074462: Handshake messages can be strictly ordered
Hi Xuelei,
Thanks for quick review. All the points are valid and implemented with your
suggestions.
Thanks,
Prasad.K
-Original Message-
From: Xuelei Fan
Sent: Friday, June 29, 2018 8:17 PM
To: Prasadrao Koppula ;
security-dev@openjdk.java.net
Subject: Re: [8u] RFR: 8074462: Handshake messages can be strictly ordered
Hi Prasad,
Thanks for take care of this issue.
SSLEngineImpl.java
--
1422 private HandshakeStatus finishHandshake() {
1423 handshaker = null;
1424 connectionState = cs_DATA;
1425 return HandshakeStatus.FINISHED;
1426}
This method are used in two places, for different purposes. It is a little bit
confusing, especially the code in line 1019. I may just remove this method,
and update the calling line accordingly.
@@ -1024,12 +1014,11 @@:
---
- handshaker = null;
- receivedCCS = false;
+ finishHandshake();
May be sufficient to remove the "receivedCCS = false" only:
handshaker = null;
- receivedCCS = false;
@@ -1040,15 +1029,14 @@
---
if (!writer.hasOutboundData()) {
- hsStatus = HandshakeStatus.FINISHED;
+ hsStatus = finishHandshake();
}
- handshaker = null;
connectionState = cs_DATA;
- receivedCCS = false;
+ handshaker = null;
May be sufficient to remove the "receivedCCS = false" only:
if (!writer.hasOutboundData()) {
hsStatus = HandshakeStatus.FINISHED;
}
handshaker = null;
connectionState = cs_DATA;
- receivedCCS = false;
Otherwise, looks fine to me.
Xuelei
On 6/29/2018 1:06 AM, Prasadrao Koppula wrote:
> Could you please review the changes
>
> Webrev: http://cr.openjdk.java.net/~pkoppula/8074462/webrev.00/
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8074462
>
> To fix handshake message out-of-order issues, we extracted required
> classes/ code from JEP 219 implementation.
>
> Contributed by: Sean Coffey and Prasadrao Koppula
>
> Thanks,
> Prasad.K
>
[11] RFR: 8187218: GSSCredential.getRemainingLifetime() returns negative value for TTL > 24 days.
Could you please review the changes Webrev: http://cr.openjdk.java.net/~pkoppula/8187218/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8187218 The tests was contributed by Weijun Wang. Thanks, Prasad.K
[8u] RFR: 8074462: Handshake messages can be strictly ordered
Could you please review the changes Webrev: http://cr.openjdk.java.net/~pkoppula/8074462/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8074462 To fix handshake message out-of-order issues, we extracted required classes/ code from JEP 219 implementation. Contributed by: Sean Coffey and Prasadrao Koppula Thanks, Prasad.K
RE: [8u-dev] RFR JDK-8187218 & JDK-8131051, two krb5 fixes on renewable
Thanks Max for review, corrected all the coding style changes. Thanks, Prasad.K -Original Message- From: Weijun Wang Sent: Wednesday, September 19, 2018 9:09 PM To: Prasadrao Koppula Cc: security-dev@openjdk.java.net Subject: Re: [8u-dev] RFR JDK-8187218 & JDK-8131051, two krb5 fixes on renewable Change looks fine, but the code style of lines 947-954 is quite different from normal, including, no space after keywords, wrong indentation of inner block and wrapped line, brace and else not on the same line, etc. --Max > On Sep 19, 2018, at 10:40 PM, Prasadrao Koppula > wrote: > > Could you please review the following fixes for 8u-dev? > > jbs: https://bugs.openjdk.java.net/browse/JDK-8187218, >https://bugs.openjdk.java.net/browse/JDK-8131051 > webrev: http://cr.openjdk.java.net/~pkoppula/8187218/webrev.00/ > > Thanks, > Prasad.K
RFR[jdk] 8237474: Default SSLEngine should create in server role
Hi, Could you please review this patch. Default server role mode was flipped in SSLEngine, to client role mode as part of SSL package code refactoring for TLSv1.3, this patch flips back default client role to server role in SSLEngine. webrev: http://cr.openjdk.java.net/~pkoppula/8237474/webrev.00/ issue: https://bugs.openjdk.java.net/browse/JDK-8237474 CSR: https://bugs.openjdk.java.net/browse/JDK-8238593 Thanks, Prasad.K
RE: RFR[jdk] 8237474: Default SSLEngine should create in server role
Thanks for review Sean, I will add test changes.
Thanks,
Prasad.K
From: Seán Coffey
Sent: Friday, February 7, 2020 6:20 PM
To: Prasadrao Koppula ;
security-dev@openjdk.java.net
Subject: Re: RFR[jdk] 8237474: Default SSLEngine should create in server role
Looks ok to me Prasad. This may also be worthy of highlighting via release
note. You might be able to expand test coverage to capture the TLSContext
scenario. Something like below patch might work ?
--- a/test/jdk/sun/security/ssl/SSLEngineImpl/EngineEnforceUseClientMode.java
+++ b/test/jdk/sun/security/ssl/SSLEngineImpl/EngineEnforceUseClientMode.java
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2004, 2018, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2004, 2020, Oracle and/or its affiliates. All rights reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -28,7 +28,7 @@
/*
* @test
- * @bug 4980882 8207250
+ * @bug 4980882 8207250 8237474
* @summary SSLEngine should enforce setUseClientMode
* @run main/othervm EngineEnforceUseClientMode
* @author Brad R. Wetmore
@@ -87,6 +87,9 @@
* Note, these are not initialized to client/server
*/
ssle3 = sslc.createSSLEngine();
+ if (ssle3.getUseClientMode()) {
+ throw new RuntimeException("Expected default role to be server");
+ }
ssle4 = sslc.createSSLEngine();
ssle5 = sslc.createSSLEngine();
}
Regards,
Sean.
On 07/02/20 11:32, Prasadrao Koppula wrote:
Hi,
Could you please review this patch. Default server role mode was flipped in
SSLEngine, to client role mode as part of SSL package code refactoring for
TLSv1.3, this patch flips back default client role to server role in SSLEngine.
webrev: HYPERLINK
"http://cr.openjdk.java.net/%7Epkoppula/8237474/webrev.00/"http://cr.openjdk.java.net/~pkoppula/8237474/webrev.00/
issue: https://bugs.openjdk.java.net/browse/JDK-8237474
CSR: https://bugs.openjdk.java.net/browse/JDK-8238593
Thanks,
Prasad.K
RE: RFR[jdk] 8237474: Default SSLEngine should create in server role
> -Original Message- > From: Daniel Fuchs > Sent: Friday, February 7, 2020 8:32 PM > To: Prasadrao Koppula ; Sean Coffey > ; security-dev@openjdk.java.net > Subject: Re: RFR[jdk] 8237474: Default SSLEngine should create in server role > > Hi Prasad, > > On 07/02/2020 14:28, Prasadrao Koppula wrote: > > Thanks for review Sean, I will add test changes. > > Not a review - but I just wanted to double check that you have run the > :jdk_net tests too - especially the httpclient tests (which are part of > :jdk_net) > as the httpclient is a heavy user of TLS 1.3 and SSLEngine :-) Hi Daniel, Yes, validated tier1, tier2, tier3 test groups, and jdk_net is part of tier2. Thanks for checking on this. Thanks, Prasad.K > > best regards, > > -- daniel >
RE: RFR[jdk] 8237474: Default SSLEngine should create in server role
Hi, Added @implnote and updated test changes, here is the new webrev, please review it. Webrev: http://cr.openjdk.java.net/~pkoppula/8237474/webrev.01/ issue: https://bugs.openjdk.java.net/browse/JDK-8237474 CSR: https://bugs.openjdk.java.net/browse/JDK-8238593 Thanks, Prasad.K From: Prasadrao Koppula Sent: Friday, February 7, 2020 5:03 PM To: security-dev@openjdk.java.net Subject: RFR[jdk] 8237474: Default SSLEngine should create in server role Hi, Could you please review this patch. Default server role mode was flipped in SSLEngine, to client role mode as part of SSL package code refactoring for TLSv1.3, this patch flips back default client role to server role in SSLEngine. webrev: http://cr.openjdk.java.net/~pkoppula/8237474/webrev.00/ issue: https://bugs.openjdk.java.net/browse/JDK-8237474 CSR: https://bugs.openjdk.java.net/browse/JDK-8238593 Thanks, Prasad.K
RE: RFR[jdk] 8237474: Default SSLEngine should create in server role
Gentle ping? Thanks, Prasad.K From: Prasadrao Koppula Sent: Monday, March 30, 2020 7:21 PM To: security-dev@openjdk.java.net Subject: RE: RFR[jdk] 8237474: Default SSLEngine should create in server role Hi, Added @implnote and updated test changes, here is the new webrev, please review it. Webrev: http://cr.openjdk.java.net/~pkoppula/8237474/webrev.01/ issue: https://bugs.openjdk.java.net/browse/JDK-8237474 CSR: https://bugs.openjdk.java.net/browse/JDK-8238593 Thanks, Prasad.K From: Prasadrao Koppula Sent: Friday, February 7, 2020 5:03 PM To: HYPERLINK "mailto:security-dev@openjdk.java.net"security-dev@openjdk.java.net Subject: RFR[jdk] 8237474: Default SSLEngine should create in server role Hi, Could you please review this patch. Default server role mode was flipped in SSLEngine, to client role mode as part of SSL package code refactoring for TLSv1.3, this patch flips back default client role to server role in SSLEngine. webrev: http://cr.openjdk.java.net/~pkoppula/8237474/webrev.00/ issue: https://bugs.openjdk.java.net/browse/JDK-8237474 CSR: https://bugs.openjdk.java.net/browse/JDK-8238593 Thanks, Prasad.K
RE: RFR[jdk] 8237474: Default SSLEngine should create in server role
Thanks for review Xuelei, I will incorporate your suggestions.
Thanks,
Prasad.K
> -Original Message-
> From: Xuelei Fan
> Sent: Thursday, April 2, 2020 9:12 PM
> To: security-dev@openjdk.java.net
> Subject: Re: RFR[jdk] 8237474: Default SSLEngine should create in server role
>
> Please update copyright year to 2020.
>
> SSLEngine.java
> --
> @@ -1109,10 +1115,14 @@
> + * @implNote
> + * The JDK SunJSSE provider implementation returns false unless
> {@link setUseClientMode}
> + * is used to change the mode to true.
>
> For the link, I may add parameter, and limit the line under 80 characters, and
> don't indent the lines.
>
> + * @implNote
> - * The JDK SunJSSE provider implementation returns false unless
> {@link setUseClientMode}
> - * is used to change the mode to true.
> + * The JDK SunJSSE provider implementation returns false unless
> + * {@link setUseClientMode(boolean)} is used to change the mode
> + * to true.
>
> It's fine to leave the CSR as it is.
>
> Otherwise, looks fine to me.
>
> Xuelei
>
> On 3/30/2020 6:50 AM, Prasadrao Koppula wrote:
> > Hi,
> >
> > Added @implnote and updated test changes, here is the new webrev,
> > please review it.
> >
> > Webrev: http://cr.openjdk.java.net/~pkoppula/8237474/webrev.01/
> >
> > issue: https://bugs.openjdk.java.net/browse/JDK-8237474
> >
> > CSR: https://bugs.openjdk.java.net/browse/JDK-8238593
> >
> > Thanks,
> >
> > Prasad.K
> >
> > *From:* Prasadrao Koppula
> > *Sent:* Friday, February 7, 2020 5:03 PM
> > *To:* security-dev@openjdk.java.net
> > *Subject:* RFR[jdk] 8237474: Default SSLEngine should create in server
> > role
> >
> > Hi,
> >
> > Could you please review this patch. Default server role mode was
> > flipped in SSLEngine, to client role mode as part of SSL package code
> > refactoring for TLSv1.3, this patch flips back default client role to
> > server role in SSLEngine.
> >
> > webrev: http://cr.openjdk.java.net/~pkoppula/8237474/webrev.00/
> >
> > issue: https://bugs.openjdk.java.net/browse/JDK-8237474
> >
> > CSR: https://bugs.openjdk.java.net/browse/JDK-8238593
> >
> > Thanks,
> >
> > Prasad.K
> >
RE: How to backports make it into openJDK?
Hi, HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8180834"JDK-8180834: Backported to Oracle JDK, 7u191. OpenJDK 7u maintainers are best to answer backport process and OpenJDK 7u porting discussions are best discussed on HYPERLINK "mailto:jdk7u-...@openjdk.java.net"jdk7u-...@openjdk.java.net Thanks, Prasad.K From: John Gray [mailto:john.g...@entrustdatacard.com] Sent: Saturday, August 22, 2020 1:42 AM To: OpenJDK Dev list Cc: Jonatan Guillén ; Carlos Ares Subject: How to backports make it into openJDK? Hello, I have a question on how the backport process works. Some of my colleagues at Entrust noted that HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8180834"JDK-8180834 was backported to the Oracle 7u191 b31 release (https://www.oracle.com/java/technologies/javase/7-support-relnotes.html#7u191-b31). Essentially it adds GCM Ciphersuite support into JDK 7. I was able to download 7u191 from Oracle’s support site and verified GCM cipher suites are working. However, they want to make use of OpenJDK 7, but it appears OpenJDK 7u191 (and later versions) do not contain the backport. We noticed a couple of things. The fix for HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8180834"JDK-8180834 says it is in “branch master” of openjdk 7 (HYPERLINK "https://hg.openjdk.java.net/jdk7u/jdk7u/jdk/file/tip/src/share/classes/sun/security/ssl/CipherSuite.java#l1316"CipherSuite.java). If you check the line referenced in this link it says (Unsupported cipher suites from RFC 5289) [HYPERLINK "https://tools.ietf.org/html/rfc5289"RFC5289]. This is the HYPERLINK "http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/def2e05299b7"changeset that openjdk made to support GCM in JDK8, If you look at the changes in HYPERLINK "http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/diff/def2e05299b7/src/share/classes/sun/security/ssl/CipherSuite.java"CipherSuite.java the unsupported GCM cipher suites are now implemented. In the comments of issue HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8180834"JDK-8180834 it says “Pushed changes to Master”, but what master? Is it a private master? The issue says it is resolved, but it is not closed. These things make us suspect that the changes are not in OpenJDK. Do changes made in master not get automatically picked up by OpenJDK? Does the ‘b31’ imply a special side branch or is it a build number? What is the process for getting changes added to OpenJDK? Thanks, John Gray Entrust Datacard
[15] RFR JDK-8246031: Hang observed with coherence SSLNIOServer test
Hi, Could you please review this patch. For timeout/interrupts, JDK11u+ releases, SSLSocket:getSession behavior is different, compare to JDK8u. i.e, connection is in open state for timeout/interrupts exception. For comparability reasons, this fix will close connection for getSession timeout/ interrupts. Bug: https://bugs.openjdk.java.net/browse/JDK-8246031 Webrev: http://cr.openjdk.java.net/~pkoppula/8246031/webrev.00/ Thanks, Prasad.K
RE: [15] RFR JDK-8246613: Choose the default SecureRandom algo based on registration ordering
Hi,
Looks good to me, one question
If first registered SecureRandom algo gets removed,
getDefaultSecureRandomAlgorithm return stale data, a refresh required in remove?
Thanks,
Prasad.K
>-Original Message-
>From: Valerie Peng
>Sent: Friday, June 5, 2020 2:52 AM
>To: security-dev@openjdk.java.net
>Subject: Re: [15] RFR JDK-8246613: Choose the default SecureRandom algo
>based on registration ordering
>
>Hi, Sean,
>
>Thanks for the review and feedback. Webrev updated:
>http://cr.openjdk.java.net/~valeriep/8246613/webrev.01/
>
>getTypeAndAlgorithm(...) was not static due to an instance variable used by
>debugging output. I have removed it and made both method static.
>
>I will wait for others' review comments also.
>
>Thanks,
>Valerie
>On 6/4/2020 2:01 PM, Sean Mullan wrote:
>> On 6/4/20 3:34 PM, Valerie Peng wrote:
>>> Hi,
>>>
>>> Could someone help reviewing this fix? This change keep tracks of the
>>> first registered SecureRandom algorithm and returns it upon the
>>> request of SecureRandom class.
>>
>> This looks good to me. I would recommend that Max or someone else
>> review it as well.
>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246613
>>>
>>> Webrev: http://cr.openjdk.java.net/~valeriep/8246613/webrev.00/
>>
>> A couple of minor comments, feel free to fix or ignore.
>>
>> * SecureRandom.java
>>
>> 879 // For SUN provider, we use
>> SunEntries.DEFF_SECURE_RANDOM_ALGO
>>
>> Might as well fix the typo while you are in there: s/DEFF/DEF/
>>
>> * Provider.java
>>
>> 1156 private String parseSecureRandomPut(String name, String
>> value) {
>>
>> Could be static if you also make getTypeAndAlgorithm static, I think.
>>
>> --Sean
RE: [15] RFR JDK-8246613: Choose the default SecureRandom algo based on registration ordering
>-Original Message-
>From: Weijun Wang
>Sent: Friday, June 5, 2020 8:24 PM
>To: Prasadrao Koppula
>Cc: Valerie Peng ; security-dev@openjdk.java.net
>Subject: Re: [15] RFR JDK-8246613: Choose the default SecureRandom algo
>based on registration ordering
>
>I don't know who in this world would want to do that, but Prasad's concern is
>technically possible. I tried 'p.remove("SecureRandom.a")' in the new test,
>and new SecureRandom() fails with
>"java.security.NoSuchAlgorithmException: a SecureRandom not available".
I too agree, users may not do this. But technically it causes exception in the
flow.
>
>And people can also remove one entry and add it back in order to move it to
>the end. One can even add new implementations this way.
>
>Unfortunately there is no ConcurrentLinkedHashMap.
Yes Max, I'm fine with current approach, if refresh at remove costs performance
hit.
Thanks,
Prasad.K
>
>--Max
>
>> On Jun 5, 2020, at 1:44 PM, Prasadrao Koppula
> wrote:
>>
>> Hi,
>>
>> Looks good to me, one question
>>
>> If first registered SecureRandom algo gets removed,
>getDefaultSecureRandomAlgorithm return stale data, a refresh required in
>remove?
>>
>> Thanks,
>> Prasad.K
>>
>>> -Original Message-
>>> From: Valerie Peng
>>> Sent: Friday, June 5, 2020 2:52 AM
>>> To: security-dev@openjdk.java.net
>>> Subject: Re: [15] RFR JDK-8246613: Choose the default SecureRandom
>>> algo based on registration ordering
>>>
>>> Hi, Sean,
>>>
>>> Thanks for the review and feedback. Webrev updated:
>>> http://cr.openjdk.java.net/~valeriep/8246613/webrev.01/
>>>
>>> getTypeAndAlgorithm(...) was not static due to an instance variable
>>> used by debugging output. I have removed it and made both method
>static.
>>>
>>> I will wait for others' review comments also.
>>>
>>> Thanks,
>>> Valerie
>>> On 6/4/2020 2:01 PM, Sean Mullan wrote:
>>>> On 6/4/20 3:34 PM, Valerie Peng wrote:
>>>>> Hi,
>>>>>
>>>>> Could someone help reviewing this fix? This change keep tracks of
>>>>> the first registered SecureRandom algorithm and returns it upon the
>>>>> request of SecureRandom class.
>>>>
>>>> This looks good to me. I would recommend that Max or someone else
>>>> review it as well.
>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246613
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8246613/webrev.00/
>>>>
>>>> A couple of minor comments, feel free to fix or ignore.
>>>>
>>>> * SecureRandom.java
>>>>
>>>> 879 // For SUN provider, we use
>>>> SunEntries.DEFF_SECURE_RANDOM_ALGO
>>>>
>>>> Might as well fix the typo while you are in there: s/DEFF/DEF/
>>>>
>>>> * Provider.java
>>>>
>>>> 1156 private String parseSecureRandomPut(String name, String
>>>> value) {
>>>>
>>>> Could be static if you also make getTypeAndAlgorithm static, I think.
>>>>
>>>> --Sean
>
RE: [15] RFR JDK-8246031: Hang observed with coherence SSLNIOServer test
Thanks for review Xuelei,
Removed handleException changes. Please review the change from latest webrev[1]
>+} else {
>+handleException(iioe);
handleException throws exception for InterruptedIOException without closing the
connection. A direct conContext.fatal call helps to close the connection.
Updated the code accordingly.
>+}
Thanks,
Prasad.K
[1] http://cr.openjdk.java.net/~pkoppula/8246031/webrev.01/
>-Original Message-
>From: Xuelei Fan
>Sent: Wednesday, June 10, 2020 10:13 PM
>To: security-dev@openjdk.java.net
>Subject: Re: [15] RFR JDK-8246031: Hang observed with coherence
>SSLNIOServer test
>
>It may be not needed to update the handleException() method.
>
>- 440handleException(iioe);
>+ 440if (resumable) {
>+throw iioe;
>+} else {
>+handleException(iioe);
handleException throws exception for InterruptedIOException without closing the
connection. A direct conContext.fatal call helps to close the connection.
Update the code accordingly.
>+}
>
>Otherwise, looks good to me.
>
>Xuelei
>
>On 6/4/2020 8:13 AM, Prasadrao Koppula wrote:
>> Hi,
>>
>> Could you please review this patch. For timeout/interrupts, JDK11u+
>> releases, SSLSocket:getSession behavior is different, compare to JDK8u.
>> i.e, connection is in open state for timeout/interrupts exception. For
>> comparability reasons, this fix will close connection for getSession
>> timeout/ interrupts.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246031
>>
>> Webrev: http://cr.openjdk.java.net/~pkoppula/8246031/webrev.00/
>>
>> Thanks,
>>
>> Prasad.K
>>
RE: [15] RFR JDK-8246031: Hang observed with coherence SSLNIOServer test
Thanks Xuelei, updated the code accordingly. Thanks, Prasad.K >-Original Message- >From: Xuelei Fan >Sent: Thursday, June 11, 2020 9:03 PM >To: Prasadrao Koppula ; security- >d...@openjdk.java.net >Subject: Re: [15] RFR JDK-8246031: Hang observed with coherence >SSLNIOServer test > >On 6/11/2020 1:50 AM, Prasadrao Koppula wrote: >> http://cr.openjdk.java.net/~pkoppula/8246031/webrev.01/ >I may have 8 more white spaces indent at line 449, and have 446 and 447 in >one line. > >Otherwise, looks good to me. Need no more review from me. > >Thanks, >Xuelei
Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
On Sat, 15 Jan 2022 00:44:08 GMT, Weijun Wang wrote: >> It's actually a purely system property rather than a Net property at the >> moment (same as the other spnego ones). Maybe, I should convert them all to >> net properties, so they can be documented/set in that file? > > This system property should only be used for TLS, and the CBT can be used in > both the SPNEGO mechanism and the Kerberos 5 mechanism. Therefore I suggest > the name should probably contain "tls" (or maybe "https") and "negotiate". > > BTW, will you reuse this system property if we decide to support CBT in NTLM > as well? I vote for "jdk.https.tls.cbt" - PR: https://git.openjdk.java.net/jdk/pull/7065
Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
On Thu, 13 Jan 2022 12:10:11 GMT, Michael McMahon wrote: > Hi, > > This change adds Channel Binding Token (CBT) support to HTTPS > (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) > authentication scheme. When enabled, the implementation preemptively includes > a CBT with authentication requests over Kerberos. The feature is enabled as > follows: > > A system property "jdk.spnego.cbt" is defined which can have the values > "never" (default), which means the feature is disabled, "always", which means > the CBT is included for all https Negotiate authentications, or it can take > the form "domain:a,b.c,*.d.com" which is a comma separated list of > domains/hosts where the feature is enabled, and disabled everywhere else. In > the given example, the CBT would be included in authentication requests for > hosts "a", "b.c" and all hosts under the domain "d.com" and all of its > sub-domains. > > A test will be added separately to the implementation. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 > > Thanks, > Michael Add Release note and Doc subtasks to the JBS - PR: https://git.openjdk.java.net/jdk/pull/7065
