I agree with this sentiment. As one who has argued for a decently secured agent to master protocol for years I think by even leaving an option to have them configured is just yet another checkbox in which a user can make a mistake. I've tried clarifying their function in the help text https://github.com/jenkinsci/jenkins/pull/2682 ; however, every company I join seems to have the worst configurations enabled. Even companies where Jenkins is secured with HTTPS it comes as a surprise to the owners that the protocols they selected have no bearing on the security of the web UI frontend.
I would personally propose removing the options of having them enabled at all. Though, if they can be disabled by default I guess that's a compromise I'd be willing to accept. Still think it would be better to remove them, though. If a user truly needs to have them enabled than we can provide a way to have them enabled via JVM properties. Not very user friendly, but then again if a user wants to lower the integrity of the security of their installation we shouldn't make it easy or user friendly (but still provide it as an option for those daring enough to do it). On Fri, Jul 28, 2017 at 12:53 AM, Oleg Nenashev <o.v.nenas...@gmail.com> 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 > <https://issues.jenkins-ci.org/browse/JENKINS-45841> for it. > > > *Why?* > > - JNLP2 stability concerns > - There are known issues in JNLP2 connection management. The engine > is complex and barely diagnosable > - Examples: > - https://github.com/jenkinsci/remoting/pull/156 > - JENKINS-31735 > <https://issues.jenkins-ci.org/browse/JENKINS-31735> - > NioChannelHub thread dies sometimes > - JENKINS-24155 > <https://issues.jenkins-ci.org/browse/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+ (pull > request <https://github.com/jenkinsci/jenkins/pull/2682>) > - 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 > <https://wiki.jenkins.io/display/JENKINS/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 jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAKtEXLAE2L1rt7i-iEP66SZP%3DL%2BdHtMnq4c4ZLMQBsdLtTYyfw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
