8259707: LDAP channel binding does not work with StartTLS extension #2085

alexeybakhtin · 2021-01-14T19:28:27Z

Please review a small patch to enable LDAP TLS Channel Binding with StartTLS Extension.
Test from the bug report and jtreg javax/naming tests are passed.

Progress

Change must not contain extraneous whitespace
Commit message must refer to an issue
Change must be properly reviewed

Issue

JDK-8259707: LDAP channel binding does not work with StartTLS extension

Reviewers

Sean Mullan (@seanjmullan - Reviewer) ⚠️ Review applies to d2f470e
Daniel Fuchs (@dfuch - Reviewer)
Aleksei Efimov (@AlekseiEfimov - Committer)

Download

$ git fetch https://git.openjdk.java.net/jdk pull/2085/head:pull/2085
$ git checkout pull/2085

bridgekeeper · 2021-01-14T19:28:41Z

👋 Welcome back abakhtin! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2021-01-14T19:29:41Z

@alexeybakhtin The following label will be automatically applied to this pull request:

core-libs

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

mlbridge · 2021-01-14T19:33:08Z

Webrevs

seanjmullan · 2021-01-19T20:24:21Z

Can you add a test for this or is it too hard? There are existing tests for StartTLS in the security/infra area -- could they be enhanced to test this case?

alexeybakhtin · 2021-01-20T07:21:22Z

Unfortunately, I can not find any LDAP StartTLS Extended Operation regression tests. security/infra area contains RevocationChecker tests. They can not be used for this scenario.

seanjmullan · 2021-01-20T14:01:16Z

Unfortunately, I can not find any LDAP StartTLS Extended Operation regression tests. security/infra area contains RevocationChecker tests. They can not be used for this scenario.

Ok, please add a noreg-hard label to the bug.

openjdk · 2021-01-20T14:02:53Z

@alexeybakhtin This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8259707: LDAP channel binding does not work with StartTLS extension

Reviewed-by: mullan, dfuchs, aefimov

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 112 new commits pushed to the master branch:

c5ad713: 8260250: Duplicate check in DebugInformationRecorder::recorders_frozen
bf5e801: 8259922: MethodHandles.collectArguments does not throw IAE if pos is outside the arity range
0ea5862: 8260053: Optimize Tokens' use of Names
18eb6d9: 8255348: NPE in PKIXCertPathValidator event logging code
a97f3c1: 8258853: Support separate function declaration and definition with ENABLE_IF-based SFINAE
154e1d6: 8259009: G1 heap summary should be shown in "Heap Parameters" window on HSDB
acbcde8: 8256111: Create implementation for NSAccessibilityStaticText protocol
f928265: 8260009: InstanceKlass::has_as_permitted_subclass() fails if subclass was redefined
7ed8ba1: 8256814: WeakProcessorPhases may be redundant
bfac3fb: 8260212: Shenandoah: resolve-only UpdateRefsMode is not used
... and 102 more: https://git.openjdk.java.net/jdk/compare/a6b2162f5400b4596afa5b88219c9cb55dcdb729...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@seanjmullan, @dfuch, @AlekseiEfimov) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

alexeybakhtin · 2021-01-20T14:19:32Z

Sean, Thank you for review

alexeybakhtin · 2021-01-20T14:25:06Z

/integrate

openjdk · 2021-01-20T14:25:36Z

@alexeybakhtin
Your change (at version d2f470e) is now ready to be sponsored by a Committer.

dfuch

That look reasonable to me. But what would happen if at some point after performing some LDAP operations, you called StartTLSResponse::close and then after some more time you tried to again create a StartTLSRequest on the same context? Would that work - or would you be using a possibly obsolete channel binding obtained from the first upgrade?

AlekseiEfimov · 2021-01-20T15:08:56Z

The change looks valid to me too.
I believe Daniel question could be illustrated with the following change to CBwithTLS reproducer attached to the bug report:

--- CBwithTLS_Original.java	2021-01-20 14:56:09.620844903 +0000
+++ CBwithTLS.java	2021-01-20 15:01:47.253982227 +0000
@@ -45,7 +45,7 @@
         System.out.println(ctxt.getAttributes("", new String[]{"defaultNamingContext"}).get("defaultNamingContext").get());
 
         // Switch to TLS
-
+        for (int i=0; i<2; i++) {
         StartTlsResponse tls = (StartTlsResponse) ctxt.extendedOperation(new StartTlsRequest());
         tls.negotiate();
 
@@ -64,6 +64,9 @@
         lc.login();
 
         Subject.doAs(lc.getSubject(), (PrivilegedAction<Void>) CBwithTLS::run);
+            lc.logout();
+            tls.close();
+        }
     }
 
     private static Void run() {

alexeybakhtin · 2021-01-20T15:34:24Z

New ChannelBinding Data will be recreated for every TLS connection and provided to SASL Client in the new environment properties set (cloned from the original).
LdapSasl.java lines 133 - 136:

                        TlsChannelBinding tlsCB =
                                TlsChannelBinding.create(cert);
                        envProps = (Hashtable<String, Object>) env.clone();
                        envProps.put(TlsChannelBinding.CHANNEL_BINDING, tlsCB.getData());

dfuch · 2021-01-20T15:54:41Z

New ChannelBinding Data will be recreated for every TLS connection and provided to SASL Client in the new environment properties set (cloned from the original).
LdapSasl.java lines 133 - 136:
                        TlsChannelBinding tlsCB =
                                TlsChannelBinding.create(cert);
                        envProps = (Hashtable<String, Object>) env.clone();

Hi Alexey,

Aleksei and I have concern because this code uses a cert that is obtained from a CompletableFuture, and the completable future can be completed only once. The second time around - you will therefore find the same cert that was set when the first StartTLSResponse was negotiated. This may - or may not matter - depending on whether the cert certificate returned by the server the second time around should be the same - or not.
Could you test this scenario?
It may be that it's a niche scenario that makes no sense or that we don't want to support - I'm not sure how STARTTLS is used in the wild. Do you have any insights on this?

best regards,

-- daniel

alexeybakhtin · 2021-01-21T13:22:07Z

Hi Daniel, Aleksei,

You are right, the second StartTLS request works incorrectly because of a single CompletableFuture. I do not know if several StartTLS sessions are used in the wild, but there are no such restrictions in the spec. I have updated the review to create new CompletableFuture for each TLS session. Updated test, suggested by Aleksei is passed. I have verified that the Channel Binding data is created on the base of a new cert object every TLS session.

AlekseiEfimov · 2021-01-21T18:19:10Z

src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java

    }

-    public boolean isTlsConnection() {
-        return sock instanceof SSLSocket;
+    private HandshakeListener tlsHandshakeListener;


I believe that volatile modifier should be added here. And it could be beneficial for future maintainers to have here a comment block with a brief description of when tlsHandshakeListener is used.

Agree. Added comments and volatile modifier.

AlekseiEfimov · 2021-01-21T18:19:30Z

src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java

+
+    private class HandshakeListener implements HandshakeCompletedListener {
+
+        private CompletableFuture<X509Certificate> tlsHandshakeCompleted =


tlsHandshakeCompleted could be made final

Thank you. Made it final

AlekseiEfimov

Hi Alexey,
The latest changes look good to me.
Thanks for handling a case of sequential StartTLS requests on one LDAP context and running the modified test. I've also checked that existing LDAP tests shows no failures with the proposed changes.
You might also want to update last modification years to 2021 in both files.

alexeybakhtin · 2021-01-22T17:24:10Z

/integrate

openjdk · 2021-01-22T17:24:50Z

@alexeybakhtin
Your change (at version 4044745) is now ready to be sponsored by a Committer.

dfuch

LGTM. Thanks for taking this on!

dfuch · 2021-01-22T18:21:12Z

I will sponsor this!

dfuch · 2021-01-22T18:21:21Z

/sponsor

openjdk · 2021-01-22T18:22:14Z

@dfuch @alexeybakhtin Since your change was applied there have been 112 commits pushed to the master branch:

c5ad713: 8260250: Duplicate check in DebugInformationRecorder::recorders_frozen
bf5e801: 8259922: MethodHandles.collectArguments does not throw IAE if pos is outside the arity range
0ea5862: 8260053: Optimize Tokens' use of Names
18eb6d9: 8255348: NPE in PKIXCertPathValidator event logging code
a97f3c1: 8258853: Support separate function declaration and definition with ENABLE_IF-based SFINAE
154e1d6: 8259009: G1 heap summary should be shown in "Heap Parameters" window on HSDB
acbcde8: 8256111: Create implementation for NSAccessibilityStaticText protocol
f928265: 8260009: InstanceKlass::has_as_permitted_subclass() fails if subclass was redefined
7ed8ba1: 8256814: WeakProcessorPhases may be redundant
bfac3fb: 8260212: Shenandoah: resolve-only UpdateRefsMode is not used
... and 102 more: https://git.openjdk.java.net/jdk/compare/a6b2162f5400b4596afa5b88219c9cb55dcdb729...master

Your commit was automatically rebased without conflicts.

Pushed as commit 874aef4.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

8259707: LDAP channel binding does not work with StartTLS extension

d2f470e

openjdk bot added the rfr Pull request is ready for review label Jan 14, 2021

openjdk bot added the core-libs core-libs-dev@openjdk.org label Jan 14, 2021

seanjmullan approved these changes Jan 20, 2021

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Jan 20, 2021

openjdk bot added the sponsor Pull request is ready to be sponsored label Jan 20, 2021

dfuch reviewed Jan 20, 2021

View reviewed changes

separate tlsHandshakeCompleted for every StartTLS connection

30a29e0

openjdk bot removed the sponsor Pull request is ready to be sponsored label Jan 21, 2021

AlekseiEfimov reviewed Jan 21, 2021

View reviewed changes

Add comments and volatile modifier for tlsHandshakeListener

e3bf8c3

AlekseiEfimov approved these changes Jan 22, 2021

View reviewed changes

Update copyright year

4044745

AlekseiEfimov approved these changes Jan 22, 2021

View reviewed changes

openjdk bot added the sponsor Pull request is ready to be sponsored label Jan 22, 2021

dfuch approved these changes Jan 22, 2021

View reviewed changes

openjdk bot closed this Jan 22, 2021

openjdk bot added integrated Pull request has been integrated and removed sponsor Pull request is ready to be sponsored ready Pull request is ready to be integrated labels Jan 22, 2021

openjdk bot removed the rfr Pull request is ready for review label Jan 22, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

8259707: LDAP channel binding does not work with StartTLS extension #2085

8259707: LDAP channel binding does not work with StartTLS extension #2085

alexeybakhtin commented Jan 14, 2021 •

edited by openjdk bot

Loading

bridgekeeper bot commented Jan 14, 2021

openjdk bot commented Jan 14, 2021

mlbridge bot commented Jan 14, 2021 •

edited

Loading

seanjmullan commented Jan 19, 2021

alexeybakhtin commented Jan 20, 2021

seanjmullan commented Jan 20, 2021

openjdk bot commented Jan 20, 2021 •

edited

Loading

alexeybakhtin commented Jan 20, 2021

alexeybakhtin commented Jan 20, 2021

openjdk bot commented Jan 20, 2021

dfuch left a comment

AlekseiEfimov commented Jan 20, 2021

alexeybakhtin commented Jan 20, 2021

dfuch commented Jan 20, 2021 •

edited

Loading

alexeybakhtin commented Jan 21, 2021

AlekseiEfimov Jan 21, 2021

alexeybakhtin Jan 21, 2021

AlekseiEfimov Jan 21, 2021

alexeybakhtin Jan 21, 2021

AlekseiEfimov left a comment •

edited

Loading

alexeybakhtin commented Jan 22, 2021

openjdk bot commented Jan 22, 2021

dfuch left a comment

dfuch commented Jan 22, 2021

dfuch commented Jan 22, 2021

openjdk bot commented Jan 22, 2021


		private class HandshakeListener implements HandshakeCompletedListener {

		private CompletableFuture<X509Certificate> tlsHandshakeCompleted =

8259707: LDAP channel binding does not work with StartTLS extension #2085

8259707: LDAP channel binding does not work with StartTLS extension #2085

Conversation

alexeybakhtin commented Jan 14, 2021 • edited by openjdk bot Loading

Progress

Issue

Reviewers

Download

bridgekeeper bot commented Jan 14, 2021

openjdk bot commented Jan 14, 2021

mlbridge bot commented Jan 14, 2021 • edited Loading

Webrevs

seanjmullan commented Jan 19, 2021

alexeybakhtin commented Jan 20, 2021

seanjmullan commented Jan 20, 2021

openjdk bot commented Jan 20, 2021 • edited Loading

alexeybakhtin commented Jan 20, 2021

alexeybakhtin commented Jan 20, 2021

openjdk bot commented Jan 20, 2021

dfuch left a comment

Choose a reason for hiding this comment

AlekseiEfimov commented Jan 20, 2021

alexeybakhtin commented Jan 20, 2021

dfuch commented Jan 20, 2021 • edited Loading

alexeybakhtin commented Jan 21, 2021

AlekseiEfimov Jan 21, 2021

Choose a reason for hiding this comment

alexeybakhtin Jan 21, 2021

Choose a reason for hiding this comment

AlekseiEfimov Jan 21, 2021

Choose a reason for hiding this comment

alexeybakhtin Jan 21, 2021

Choose a reason for hiding this comment

AlekseiEfimov left a comment • edited Loading

Choose a reason for hiding this comment

alexeybakhtin commented Jan 22, 2021

openjdk bot commented Jan 22, 2021

dfuch left a comment

Choose a reason for hiding this comment

dfuch commented Jan 22, 2021

dfuch commented Jan 22, 2021

openjdk bot commented Jan 22, 2021

alexeybakhtin commented Jan 14, 2021 •

edited by openjdk bot

Loading

mlbridge bot commented Jan 14, 2021 •

edited

Loading

openjdk bot commented Jan 20, 2021 •

edited

Loading

dfuch commented Jan 20, 2021 •

edited

Loading

AlekseiEfimov left a comment •

edited

Loading