• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Blocker Blocker
    • core

      Too many encoding issues with JNLP3 protocol. We should stop A/B testing it for HEAD and LTS

          [JENKINS-37315] Make JNLP3 opt-in for all

          Merged to Head

          Stephen Connolly added a comment - Merged to Head

          Oliver Gondža added a comment - - edited

          What is the impact of the bug? As I understand it, the negotiation can fail and then JNLPv2 will be used without users even noticing.

          Oliver Gondža added a comment - - edited What is the impact of the bug? As I understand it, the negotiation can fail and then JNLPv2 will be used without users even noticing.

          If it falls back to JNLP2 then the secret is exposed over the wire and thus the encryption can be broken.

          There are approx 28% of connection attempts that will fail due to the cookie and about 5-10% that will fail due to challenge-response encoding issues... the cookie one should have been fixed if you use the latest remoting.jar on your agents...

          If an admin has enabled JNLP3 on the master because they want to keep transport encrypted, this is a bad thing. For the 10% who are opted in to the A/B testing, they will get slower connection establishment.

          Given all the issues I have identified with JNLP3 I am now of the opinion that we drop it and go straight for JNLP4 (subject to an A/B test on JNLP4), so there is no value - to my mind - in continuing with the JNLP3 A/B testing and consequently no value in exposing users to it (obviously JNLP3 is more encrypted than JNLP2, so we cannot disable it until JNLP4 is merged into Jenkins core... and even then we should not disable it until after the A/B testing on JNLP4)

          Stephen Connolly added a comment - If it falls back to JNLP2 then the secret is exposed over the wire and thus the encryption can be broken. There are approx 28% of connection attempts that will fail due to the cookie and about 5-10% that will fail due to challenge-response encoding issues... the cookie one should have been fixed if you use the latest remoting.jar on your agents... If an admin has enabled JNLP3 on the master because they want to keep transport encrypted, this is a bad thing. For the 10% who are opted in to the A/B testing, they will get slower connection establishment. Given all the issues I have identified with JNLP3 I am now of the opinion that we drop it and go straight for JNLP4 (subject to an A/B test on JNLP4), so there is no value - to my mind - in continuing with the JNLP3 A/B testing and consequently no value in exposing users to it (obviously JNLP3 is more encrypted than JNLP2, so we cannot disable it until JNLP4 is merged into Jenkins core... and even then we should not disable it until after the A/B testing on JNLP4)

          Oleg Nenashev added a comment -

          It has been backported to the 2.7.3 branch. The fix is available in the release candidate.
          https://github.com/jenkinsci/jenkins/commit/97c1cbd753d963e947c085c040667b1b98e06ba1

          Oleg Nenashev added a comment - It has been backported to the 2.7.3 branch. The fix is available in the release candidate. https://github.com/jenkinsci/jenkins/commit/97c1cbd753d963e947c085c040667b1b98e06ba1

            stephenconnolly Stephen Connolly
            stephenconnolly Stephen Connolly
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: