Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-63323

Active Directory with "Trust all certificates" allows silent fallback to plain-text LDAP

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Labels:
      None
    • Environment:
      Jenkins 2.235.3
      Active Directory 2.1.6
    • Similar Issues:

      Description

      Enabling the "Trust all certificates" option does not have the expected behaviour for some forms of SSL failure, specifically a hostname mismatch.

      For example for a domain with the following settings:

      • Domain name: ad.company.com
      • Domain controller: dc.ad.company.com:3268 (with a self-signed certificate)
      • Bind DN: user@ad.company.com
      • Bind Password: whatever
      • TLS Configuration: Trust all certificates
      • StartTLS: checked

      This results in StartTLS succeeding even though the certificate is self-signed and not trusted:

      Aug 06, 2020 12:36:41 PM FINE hudson.plugins.active_directory.ActiveDirectorySecurityRealm
      Connecting to ldap://dc.ad.company.com:3268/
      Aug 06, 2020 12:36:41 PM FINE hudson.plugins.active_directory.ActiveDirectorySecurityRealm
      Connection upgraded to TLS
      Aug 06, 2020 12:36:41 PM FINE hudson.plugins.active_directory.ActiveDirectorySecurityRealm
      Binding as user@ad.company.com to ldap://dc.ad.company.com:3268/
      Aug 06, 2020 12:36:41 PM FINE hudson.plugins.active_directory.ActiveDirectorySecurityRealm
      Bound to dc.ad.company.com:3268

      However if the domain controller entry is changed to be the IP address of dc.ad.company.com (or any other alternate IP/hostname for that server which does not appear in the TLS certificate) then this still causes an SSL exception even though "Trust all certificates" is selected

      Aug 06, 2020 12:37:01 PM FINE hudson.plugins.active_directory.ActiveDirectorySecurityRealm
      Aug 06, 2020 12:37:01 PM FINE hudson.plugins.active_directory.ActiveDirectorySecurityRealm
      Connecting to ldap://10.0.0.2:3268/
      Aug 06, 2020 12:37:01 PM FINE hudson.plugins.active_directory.ActiveDirectorySecurityRealm
      Failed to start TLS. Authentication will be done via plain-text LDAP
      java.security.cert.CertificateException: No subject alternative names matching IP address 10.0.0.2 found at sun.security.util.HostnameChecker.matchIP(HostnameChecker.java:168) at sun.security.util.HostnameChecker.match(HostnameChecker.java:94) at com.sun.jndi.ldap.ext.StartTlsResponseImpl.verify(StartTlsResponseImpl.java:426)
      Caused: javax.net.ssl.SSLPeerUnverifiedException: hostname of the server '10.0.0.2' does not match the hostname in the server's certificate. at com.sun.jndi.ldap.ext.StartTlsResponseImpl.verify(StartTlsResponseImpl.java:447) at com.sun.jndi.ldap.ext.StartTlsResponseImpl.negotiate(StartTlsResponseImpl.java:225) at hudson.plugins.active_directory.ActiveDirectorySecurityRealm$DescriptorImpl.bind(ActiveDirectorySecurityRealm.java:684) at hudson.plugins.active_directory.ActiveDirectorySecurityRealm$DescriptorImpl.bind(ActiveDirectorySecurityRealm.java:599) at hudson.plugins.active_directory.ActiveDirectoryDomain$DescriptorImpl.doValidateTest(ActiveDirectoryDomain.java:336) 

      Expected result:

      Since "Trust all certificates" is enabled, Jenkins should not care that the Subject/SAN/IP don't match - since it does receive a usable certificate, it should use it and encrypt the traffic anyway. Alternatively, if this is not possible for some reason, then the "Test Domain" button should show some kind of warning to indicate that even though you have STARTTLS enabled, it was not used for the test (so that the fallback is no longer silent and it at least alerts the adminstrative user to a potential issue to investigate)

      Actual result:

      The certificate is rejected and the connection silently falls back to plain text without notifying any administrative user to alert them to a problem

      Justification:

      Encrypting to an untrusted certificate is still encrypting, so offers some (limited) protection against sniffing of credentials off the wire even if you can't guarantee complete end-to-end security. If an administrative user has enabled the "trust all certificates" option they are explicitly saying that they want the traffic to be encrypted even if trust cannot be established, so falling back to plain text seems the wrong thing to do. In my company, somehow the IT team have got some domain controllers serving up certificates with incorrect subjects in response to STARTTLS requests, so my Jenkins server has been silently sending credentials in plain text rather than at least encrypting them with something.

        Attachments

          Activity

          There are no comments yet on this issue.

            People

            Assignee:
            fbelzunc Félix Belzunce Arcos
            Reporter:
            gchappell99 Gavin Chappell
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Dates

              Created:
              Updated: