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

Can only connect one JNLP3 slave per IP address

XMLWordPrintable

      I'm running into an issue with JNLP3. I have three slaves communicating through a proxy, so by the time the traffic gets to the master, they are coming from the same IP address. The port numbers are unique; they are ephemeral ports. With JNLP3, I can't get more than one slave connected at a time. Other slaves connect, but then I get a message:

      WARNING: Making

      {slave name}

      offline because it’s not responding
      Mar 28, 2016 11:35:31 PM hudson.node_monitors.ResponseTimeMonitor$1 monitor

      If I remove the "-Djenkins.slaves.JnlpSlaveAgentProtocol3.enabled=true" switch (reverting to JNLP2), I can connect multiple slaves at the same time, no issues.

          [JENKINS-33886] Can only connect one JNLP3 slave per IP address

          Jeff Kayser created issue -

          Daniel Beck added a comment -

          Haven't investigated, from superficially this is more a bug related to a feature that 'adds security', rather than a security vulnerability.

          oleg_nenashev Did you intend for this to be filed here?

          Daniel Beck added a comment - Haven't investigated, from superficially this is more a bug related to a feature that 'adds security', rather than a security vulnerability. oleg_nenashev Did you intend for this to be filed here?

          Oleg Nenashev added a comment -

          I think it's rather a security implementation-related bug than a security issue.

          Oleg Nenashev added a comment - I think it's rather a security implementation-related bug than a security issue.

          Oleg Nenashev added a comment -

          The difference is that we could be able to process it as a common bug and to release a fix in remoting without syncing up with the next LTS release

          Oleg Nenashev added a comment - The difference is that we could be able to process it as a common bug and to release a fix in remoting without syncing up with the next LTS release

          Jeff Kayser added a comment -

          Sorry for mis-categorizing it. I'm not sure how to change the category (I'm a Jira newbie). Please feel free to change it as desired. My feelings won't be hurt.

          Jeff Kayser added a comment - Sorry for mis-categorizing it. I'm not sure how to change the category (I'm a Jira newbie). Please feel free to change it as desired. My feelings won't be hurt.

          Oleg Nenashev added a comment -

          No problem. We are having a SECURITY team meeting tomorrow, so we will agree on the action plan there
          .

          Oleg Nenashev added a comment - No problem. We are having a SECURITY team meeting tomorrow, so we will agree on the action plan there .

          Daniel Beck added a comment -

          If there is no way to exploit this, it's not a SECURITY issue. oleg_nenashev Do you see some possibility for that?

          Daniel Beck added a comment - If there is no way to exploit this, it's not a SECURITY issue. oleg_nenashev Do you see some possibility for that?

          James Nord added a comment -

          As long as we only disconnect the others after the security handshake of the latest, otherwise it could be a DOS attack vector.

          James Nord added a comment - As long as we only disconnect the others after the security handshake of the latest, otherwise it could be a DOS attack vector.

          Oleg Nenashev added a comment -

          My only concern is about the case when multiple slaves manage to connect:
          1) First slave gets JNLP3
          2) Others get decline from JNLP3 and get connected via JNLP2
          3) A user who knows the behavior may be able to retrieve the data from there

          The behavior does not seem to happen according to the description from Jeff.
          I think we should fix it as a common bug.

          Oleg Nenashev added a comment - My only concern is about the case when multiple slaves manage to connect: 1) First slave gets JNLP3 2) Others get decline from JNLP3 and get connected via JNLP2 3) A user who knows the behavior may be able to retrieve the data from there The behavior does not seem to happen according to the description from Jeff. I think we should fix it as a common bug.

          Oleg Nenashev added a comment -

          A common CRITICAL bug, of course

          Oleg Nenashev added a comment - A common CRITICAL bug, of course

            Unassigned Unassigned
            jeffkayser Jeff Kayser
            Votes:
            2 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved: