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

startTLS failure leaves connection unencrypted

      the AD plugin in LDAP mode can use startTLS to upgrade a plain text connection to a secure one.

      However if this upgrade fails the connection reverts to a plain text one.

      This is actually documented, however it is somewhat at odd with the flag from SECURITY-1389

      As an AD server may not be exposed on the SSL ports but only the plain text with upgrades, there may be no way for a user to configure the AD plugin to use an encrypted LDAP connection.
      (requireTLS forces the connection to use the ssl port)

      Rather if both startTLS and requireTLS are both set then the upgrade should be done with the START_TLS command and for any failure the connection should abort.

      Documentation would need to be changed accordingly.

          [JENKINS-67580] startTLS failure leaves connection unencrypted

          David Sainty added a comment -

          I don't really understand why this is Minor priority, this security hole makes MitM attacks trivial.  I had no idea that our AD connections were plaintext, because startTLS was on and certificates were set up.  But it only takes a certification issue to cause the AD connections to invisibly fall back to plaintext.  There will probably be a lot of people on the planet in the same situation that would be shocked to find this out.

          As the reporter says, the requireTLS meaning is really counter-intuitive.  requireTLS overriding startTLS makes no sense.

          For our situation, SECURITY-1389 was essentially unresolved.

          David Sainty added a comment - I don't really understand why this is Minor priority, this security hole makes MitM attacks trivial.  I had no idea that our AD connections were plaintext, because startTLS was on and certificates were set up.  But it only takes a certification issue to cause the AD connections to invisibly fall back to plaintext.  There will probably be a lot of people on the planet in the same situation that would be shocked to find this out. As the reporter says, the requireTLS meaning is really counter-intuitive.  requireTLS overriding startTLS makes no sense. For our situation, SECURITY-1389 was essentially unresolved.

          James Nord added a comment - - edited

          > I had no idea that our AD connections were plaintext,

          it is at least documented as such in the product (and has been since the introduction of the feature) as well as in the security announcement and the main plugin details.

          in product ->

          > "StartTLS will only tries to start in case the communication is started without encryption" (sic)

          Security announcement ->

          > Unlike the existing StartTLS option for the LDAP-based mode, it will not proceed using an insecure connection if establishing a TLS/SSL connection fails.

          plugin documentation ->

          > "Note : For upgrades from prior versions without the system property set, connections may still be performed with plain text (if using Enable StartTls and the StartTLS command fails, or the plugin is using ADSI), it is Strongly recommended that you enable the option."

          > why this is Minor priority

          Probably because it is doing exactly what it is documented to be doing, and the fix is to use SSL socket mode

          James Nord added a comment - - edited > I had no idea that our AD connections were plaintext, it is at least documented as such in the product (and has been since the introduction of the feature) as well as in the security announcement and the main plugin details. in product -> > "StartTLS will only tries to start in case the communication is started without encryption" (sic) Security announcement -> > Unlike the existing StartTLS option for the LDAP-based mode, it will not proceed using an insecure connection if establishing a TLS/SSL connection fails. plugin documentation -> > "Note : For upgrades from prior versions without the system property set, connections may still be performed with plain text (if using Enable StartTls and the StartTLS command fails, or the plugin is using ADSI), it is Strongly recommended that you enable the option." > why this is Minor priority Probably because it is doing exactly what it is documented to be doing, and the fix is to use SSL socket mode

          David Sainty added a comment -

          Having startTLS only available as an insecure option at the very least violates the principle of least surprise.   Why not just make startTLS secure?  Or at least, why not make it secure if requireTLS is set?

          If an organisation only supports AD on port 389 and thus only supports startTLS for security, AND Jenkins only supports startTLS with no authentication and failing back to plaintext - that creates a big, big problem.  That's my situation.

          David Sainty added a comment - Having startTLS only available as an insecure option at the very least violates the principle of least surprise.   Why not just make startTLS secure?  Or at least, why not make it secure if requireTLS is set? If an organisation only supports AD on port 389 and thus only supports startTLS for security, AND Jenkins only supports startTLS with no authentication and failing back to plaintext - that creates a big, big problem.  That's my situation.

            fbelzunc FĂ©lix Belzunce Arcos
            teilo James Nord
            Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: