RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos
Michael McMahon
michaelm at openjdk.java.net
Fri Jan 14 18:45:27 UTC 2022
On Fri, 14 Jan 2022 14:52:13 GMT, Daniel Fuchs <dfuchs at openjdk.org> 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
>
> src/java.base/share/classes/sun/net/www/http/HttpClient.java line 152:
>
>> 150: * If enabled (for a particular destination) then SPNEGO authentication requests will include
>> 151: * a channel binding token for the destination server. The default behavior and setting for the
>> 152: * property is "never"
>
> Maybe this description should be added to `src/java.base//share/classes/java/net/doc-files/net-properties.html` too?
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?
> src/java.security.jgss/share/classes/module-info.java line 36:
>
>> 34: module java.security.jgss {
>> 35: requires java.naming;
>> 36: requires java.security.sasl;
>
> Someone from security-dev should probably review this and validate that this is OK. I'm also a bit uncomfortable that we require a class from `com.sun.jndi.ldap.sasl` even though `java.naming` is already required by `java.security.jgss` - so maybe this is OK.
Yes. I would like the security team to validate this.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7065
More information about the core-libs-dev
mailing list