Proposal - Disabling JNLP1/2 and CLI1 protocols by default in new Installations

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Proposal - Disabling JNLP1/2 and CLI1 protocols by default in new Installations

Oleg Nenashev
Hi all,

It is almost one year since the release of JNLP4 protocol in Remoting 3.0. This protocol is available in Jenkins LTS since 2.32.1, and so far it demonstrates good stability being compared to JNLP2 and especially to JNLP3. The protocol was enabled by default in 2.46.x, and we do not have confirmed JNLP4 issues since that.

I propose to disable the previous protocols. I have created JENKINS-45841 for it.

Why?

  • JNLP2 stability concerns
  • JNLP1/JNLP2/CLI1 are known to be unencrypted
    • Sam Gleske also made it explicit in UI, Jenkins 2.41+ (pull request)
    • It is not a security issue, they have been never claimed to be encrypted
    • Jenkins CERT team agreed that disabling protocols is reasonable from the security hardening standpoint

How?

  • UPD: When installation wizard is enabled && it runs in the new installation mode, disable the old protocols during the instance initialization
    • It is similar to what we do for Remoting CLI disabling and the default security initialization in Jenkins 2.0
  • ADD: administrative monitor, which warns about obsolete Remoting protocols and points to the errata documents (like this one)
  • ADD: Explicit deprecation notice to the built-in HTML documentation

Compatibility concerns

  • Old instances won't be affected, protocols will be still enabled for them
  • "New" Jenkins instances installed via setup wizard may be affected in age cases. Examples:
    • Agents with Remoting older than 3.0 will be unable to connect.
      • One may bundle old Remoting in his custom Docker images, AMIs, etc.
    • Swarm Plugin: old versions of Swarm Client (before 3.3) will be unable to connect, because Remoting 2.x is bundled
    • **Very** old jenkins-cli.jar without CLI2 support will be unable to connect

Not affected:

  • Newly installed instances created from scratch
  • Instances using the "-Djenkins.install.runSetupWizard=false" flag (all configuration-as-code instances)
  • SSH Slaves Plugin, any newly installed agent type, community-provided Docker packages for agents, etc.

Announcement

  • It's a potentially breaking change, hence it should be announced in blog posts
  • The change and the corner cases should be addressed in the upgrade guide, which should be published within the blogpost

I think it's a good time to finally do this change. WDYT?


Thanks in advance,

Oleg Nenashev

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/7a7e2b81-8795-48bd-b1c2-d0ee31123df3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal - Disabling JNLP1/2 and CLI1 protocols by default in new Installations

stephenconnolly
+1

On Fri 28 Jul 2017 at 08:53, Oleg Nenashev <[hidden email]> wrote:
Hi all,

It is almost one year since the release of JNLP4 protocol in Remoting 3.0. This protocol is available in Jenkins LTS since 2.32.1, and so far it demonstrates good stability being compared to JNLP2 and especially to JNLP3. The protocol was enabled by default in 2.46.x, and we do not have confirmed JNLP4 issues since that.

I propose to disable the previous protocols. I have created JENKINS-45841 for it.

Why?

  • JNLP2 stability concerns
  • JNLP1/JNLP2/CLI1 are known to be unencrypted
    • Sam Gleske also made it explicit in UI, Jenkins 2.41+ (pull request)
    • It is not a security issue, they have been never claimed to be encrypted
    • Jenkins CERT team agreed that disabling protocols is reasonable from the security hardening standpoint

How?

  • UPD: When installation wizard is enabled && it runs in the new installation mode, disable the old protocols during the instance initialization
    • It is similar to what we do for Remoting CLI disabling and the default security initialization in Jenkins 2.0
  • ADD: administrative monitor, which warns about obsolete Remoting protocols and points to the errata documents (like this one)
  • ADD: Explicit deprecation notice to the built-in HTML documentation

Compatibility concerns

  • Old instances won't be affected, protocols will be still enabled for them
  • "New" Jenkins instances installed via setup wizard may be affected in age cases. Examples:
    • Agents with Remoting older than 3.0 will be unable to connect.
      • One may bundle old Remoting in his custom Docker images, AMIs, etc.
    • Swarm Plugin: old versions of Swarm Client (before 3.3) will be unable to connect, because Remoting 2.x is bundled
    • **Very** old jenkins-cli.jar without CLI2 support will be unable to connect

Not affected:

  • Newly installed instances created from scratch
  • Instances using the "-Djenkins.install.runSetupWizard=false" flag (all configuration-as-code instances)
  • SSH Slaves Plugin, any newly installed agent type, community-provided Docker packages for agents, etc.

Announcement

  • It's a potentially breaking change, hence it should be announced in blog posts
  • The change and the corner cases should be addressed in the upgrade guide, which should be published within the blogpost

I think it's a good time to finally do this change. WDYT?


Thanks in advance,

Oleg Nenashev

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/7a7e2b81-8795-48bd-b1c2-d0ee31123df3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Sent from my phone

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMw-mrET-X9xO4Y2B%3Dy2MfQ%3DyduKedp9wLiFL-Xk_eKYjQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal - Disabling JNLP1/2 and CLI1 protocols by default in new Installations

Baptiste MATHUS
Having seen recently a customer simply switch from JNLP2 to JNLP4 and get their instance back to working, after they had disabled JNLP4 after some mistake I'm +1 to help drive users more towards the "right"/recommended version.

2017-07-28 10:02 GMT+02:00 Stephen Connolly <[hidden email]>:
+1

On Fri 28 Jul 2017 at 08:53, Oleg Nenashev <[hidden email]> wrote:
Hi all,

It is almost one year since the release of JNLP4 protocol in Remoting 3.0. This protocol is available in Jenkins LTS since 2.32.1, and so far it demonstrates good stability being compared to JNLP2 and especially to JNLP3. The protocol was enabled by default in 2.46.x, and we do not have confirmed JNLP4 issues since that.

I propose to disable the previous protocols. I have created JENKINS-45841 for it.

Why?

  • JNLP2 stability concerns
  • JNLP1/JNLP2/CLI1 are known to be unencrypted
    • Sam Gleske also made it explicit in UI, Jenkins 2.41+ (pull request)
    • It is not a security issue, they have been never claimed to be encrypted
    • Jenkins CERT team agreed that disabling protocols is reasonable from the security hardening standpoint

How?

  • UPD: When installation wizard is enabled && it runs in the new installation mode, disable the old protocols during the instance initialization
    • It is similar to what we do for Remoting CLI disabling and the default security initialization in Jenkins 2.0
  • ADD: administrative monitor, which warns about obsolete Remoting protocols and points to the errata documents (like this one)
  • ADD: Explicit deprecation notice to the built-in HTML documentation

Compatibility concerns

  • Old instances won't be affected, protocols will be still enabled for them
  • "New" Jenkins instances installed via setup wizard may be affected in age cases. Examples:
    • Agents with Remoting older than 3.0 will be unable to connect.
      • One may bundle old Remoting in his custom Docker images, AMIs, etc.
    • Swarm Plugin: old versions of Swarm Client (before 3.3) will be unable to connect, because Remoting 2.x is bundled
    • **Very** old jenkins-cli.jar without CLI2 support will be unable to connect

Not affected:

  • Newly installed instances created from scratch
  • Instances using the "-Djenkins.install.runSetupWizard=false" flag (all configuration-as-code instances)
  • SSH Slaves Plugin, any newly installed agent type, community-provided Docker packages for agents, etc.

Announcement

  • It's a potentially breaking change, hence it should be announced in blog posts
  • The change and the corner cases should be addressed in the upgrade guide, which should be published within the blogpost

I think it's a good time to finally do this change. WDYT?


Thanks in advance,

Oleg Nenashev

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/7a7e2b81-8795-48bd-b1c2-d0ee31123df3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Sent from my phone

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMw-mrET-X9xO4Y2B%3Dy2MfQ%3DyduKedp9wLiFL-Xk_eKYjQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS4-GLOSOw%3DKo-rpeo_7T0VAmo2xE7oW%2BikMc61s4-P%3DyA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal - Disabling JNLP1/2 and CLI1 protocols by default in new Installations

Oleg Nenashev
Added the proposal sign-off to the today's Governance meeting agenda.
The pull requests are up and running: https://github.com/jenkinsci/jenkins/pull/2950

BR, Oleg

пятница, 28 июля 2017 г., 14:59:53 UTC+2 пользователь Baptiste Mathus написал:
Having seen recently a customer simply switch from JNLP2 to JNLP4 and get their instance back to working, after they had disabled JNLP4 after some mistake I'm +1 to help drive users more towards the "right"/recommended version.

2017-07-28 10:02 GMT+02:00 Stephen Connolly <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="kYOhmnMsCAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">stephen.al...@gmail.com>:
+1

On Fri 28 Jul 2017 at 08:53, Oleg Nenashev <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="kYOhmnMsCAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">o.v.ne...@...> wrote:
Hi all,

It is almost one year since the release of JNLP4 protocol in Remoting 3.0. This protocol is available in Jenkins LTS since 2.32.1, and so far it demonstrates good stability being compared to JNLP2 and especially to JNLP3. The protocol was enabled by default in 2.46.x, and we do not have confirmed JNLP4 issues since that.

I propose to disable the previous protocols. I have created <a href="https://issues.jenkins-ci.org/browse/JENKINS-45841" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fissues.jenkins-ci.org%2Fbrowse%2FJENKINS-45841\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGJWwBqDiCEossGU9cS9MQHwz0YSQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fissues.jenkins-ci.org%2Fbrowse%2FJENKINS-45841\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGJWwBqDiCEossGU9cS9MQHwz0YSQ&#39;;return true;">JENKINS-45841 for it.

Why?

  • JNLP2 stability concerns
    • There are known issues in JNLP2 connection management. The engine is complex and barely diagnosable
    • Examples: 
      • <a href="https://github.com/jenkinsci/remoting/pull/156" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fremoting%2Fpull%2F156\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFBU3nPi29KnDwBzkMU2VTuoQTiig&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fremoting%2Fpull%2F156\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFBU3nPi29KnDwBzkMU2VTuoQTiig&#39;;return true;">https://github.com/jenkinsci/remoting/pull/156 
      • <a href="https://issues.jenkins-ci.org/browse/JENKINS-31735" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fissues.jenkins-ci.org%2Fbrowse%2FJENKINS-31735\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFBj0Fb_pzJM6RlrUiGIOhFTw_LMg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fissues.jenkins-ci.org%2Fbrowse%2FJENKINS-31735\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFBj0Fb_pzJM6RlrUiGIOhFTw_LMg&#39;;return true;">JENKINS-31735 - NioChannelHub thread dies sometimes
      • <a href="https://issues.jenkins-ci.org/browse/JENKINS-24155" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fissues.jenkins-ci.org%2Fbrowse%2FJENKINS-24155\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG3GbfpHAIZOAe_k-AKRsD0WMWHqQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fissues.jenkins-ci.org%2Fbrowse%2FJENKINS-24155\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG3GbfpHAIZOAe_k-AKRsD0WMWHqQ&#39;;return true;">JENKINS-24155 - Slaves going offline in NIO mode
    • In many cases update to JNLP4 was a resolution
  • JNLP1/JNLP2/CLI1 are known to be unencrypted
    • Sam Gleske also made it explicit in UI, Jenkins 2.41+ (<a href="https://github.com/jenkinsci/jenkins/pull/2682" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fjenkins%2Fpull%2F2682\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHjXV5nBvV-Nirm1V4m07oVvwRBAw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fjenkins%2Fpull%2F2682\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHjXV5nBvV-Nirm1V4m07oVvwRBAw&#39;;return true;">pull request)
    • It is not a security issue, they have been never claimed to be encrypted
    • Jenkins CERT team agreed that disabling protocols is reasonable from the security hardening standpoint

How?

  • UPD: When installation wizard is enabled && it runs in the new installation mode, disable the old protocols during the instance initialization
    • It is similar to what we do for Remoting CLI disabling and the default security initialization in Jenkins 2.0
  • ADD: administrative monitor, which warns about obsolete Remoting protocols and points to the errata documents (like this one)
  • ADD: Explicit deprecation notice to the built-in HTML documentation

Compatibility concerns

  • Old instances won't be affected, protocols will be still enabled for them
  • "New" Jenkins instances installed via setup wizard may be affected in age cases. Examples:
    • Agents with Remoting older than 3.0 will be unable to connect.
      • One may bundle old Remoting in his custom Docker images, AMIs, etc.
    • <a href="https://wiki.jenkins.io/display/JENKINS/Swarm+Plugin" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwiki.jenkins.io%2Fdisplay%2FJENKINS%2FSwarm%2BPlugin\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHd8YFOc6jI32WBwGprMYXwqG6vIQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwiki.jenkins.io%2Fdisplay%2FJENKINS%2FSwarm%2BPlugin\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHd8YFOc6jI32WBwGprMYXwqG6vIQ&#39;;return true;">Swarm Plugin: old versions of Swarm Client (before 3.3) will be unable to connect, because Remoting 2.x is bundled
    • **Very** old jenkins-cli.jar without CLI2 support will be unable to connect

Not affected:

  • Newly installed instances created from scratch
  • Instances using the "-Djenkins.install.runSetupWizard=false" flag (all configuration-as-code instances)
  • SSH Slaves Plugin, any newly installed agent type, community-provided Docker packages for agents, etc.

Announcement

  • It's a potentially breaking change, hence it should be announced in blog posts
  • The change and the corner cases should be addressed in the upgrade guide, which should be published within the blogpost

I think it's a good time to finally do this change. WDYT?


Thanks in advance,

Oleg Nenashev

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="kYOhmnMsCAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-dev/7a7e2b81-8795-48bd-b1c2-d0ee31123df3%40googlegroups.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-dev/7a7e2b81-8795-48bd-b1c2-d0ee31123df3%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-dev/7a7e2b81-8795-48bd-b1c2-d0ee31123df3%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/jenkinsci-dev/7a7e2b81-8795-48bd-b1c2-d0ee31123df3%40googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.
--
Sent from my phone

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="kYOhmnMsCAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMw-mrET-X9xO4Y2B%3Dy2MfQ%3DyduKedp9wLiFL-Xk_eKYjQ%40mail.gmail.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMw-mrET-X9xO4Y2B%3Dy2MfQ%3DyduKedp9wLiFL-Xk_eKYjQ%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMw-mrET-X9xO4Y2B%3Dy2MfQ%3DyduKedp9wLiFL-Xk_eKYjQ%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMw-mrET-X9xO4Y2B%3Dy2MfQ%3DyduKedp9wLiFL-Xk_eKYjQ%40mail.gmail.com.

For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/601824cd-7a04-4d8c-8194-10f0db590926%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Loading...