[JIRA] [core] (JENKINS-34121) IBM Java doesn't support AES/CTR/PKCS5Padding, required for JNLP3

117 views
Skip to first unread message

gabarmas@ie.ibm.com (JIRA)

unread,
Apr 8, 2016, 7:08:01 AM4/8/16
to jenkinsc...@googlegroups.com
Gabriel Lopez created an issue
 
Jenkins / Bug JENKINS-34121
IBM Java doesn't support AES/CTR/PKCS5Padding, required for JNLP3
Issue Type: Bug Bug
Assignee: Unassigned
Components: core
Created: 2016/Apr/08 11:07 AM
Priority: Major Major
Reporter: Gabriel Lopez

It is not possible to run slaves anymore using IBM Java.

This is due to the new encrypted communication introduced in Jenkins 1.653, where the handshake is done using "AES/CTR/PKCS5Padding".

I couldn't find what ciphers IBM Java does or doesn't support (maybe nothing else than the default ones), but I created a quick test to check. See below.

Would it be possible to switch to a cipher supported by IBM Java?

Test:
import java.security.NoSuchAlgorithmException;
import javax.crypto.Cipher;
import javax.crypto.NoSuchPaddingException;

public class PaddingIssue {
private static final String CIPHER = "AES/CTR/PKCS5Padding";

public static void main(String[] args) throws NoSuchAlgorithmException, NoSuchPaddingException

{ Cipher encryptCipher = Cipher.getInstance(CIPHER); System.out.println("Fine!"); }

}

Executions:
IBM JAVA 1.6
/usr/lib/j2re1.6-ibm/jre/bin/java PaddingIssue
Exception in thread "main" java.security.NoSuchAlgorithmException: Cannot find any provider supporting AES/CTR/PKCS5Padding
at javax.crypto.Cipher.getInstance(Unknown Source)
at PaddingIssue.main(PaddingIssue.java:10)
Caused by: javax.crypto.NoSuchPaddingException: CTR mode must be used with ISO10126Padding or NoPadding
at com.ibm.crypto.provider.AESCipher.engineSetPadding(Unknown Source)
at javax.crypto.Cipher$a.a(Unknown Source)
... 2 more

IBM JAVA 1.7
/usr/lib/j2re1.7-ibm/jre/bin/java PaddingIssue
Exception in thread "main" java.security.NoSuchAlgorithmException: Cannot find any provider supporting AES/CTR/PKCS5Padding
at javax.crypto.Cipher.getInstance(Unknown Source)
at PaddingIssue.main(PaddingIssue.java:10)
Caused by: javax.crypto.NoSuchPaddingException: CTR mode must be used with ISO10126Padding or NoPadding
at com.ibm.crypto.provider.AESCipher.engineSetPadding(Unknown Source)
at javax.crypto.Cipher$a.a(Unknown Source)
... 2 more

IBM JAVA 1.8
/usr/lib/jvm/java-ibm-x86_64-80/jre/bin/java PaddingIssue
Exception in thread "main" java.security.NoSuchAlgorithmException: Cannot find any provider supporting AES/CTR/PKCS5Padding
at javax.crypto.Cipher.getInstance(Unknown Source)
at PaddingIssue.main(PaddingIssue.java:10)
Caused by: javax.crypto.NoSuchPaddingException: CTR mode must be used with ISO10126Padding or NoPadding
at com.ibm.crypto.provider.AbstractBufferingCipher.engineSetPadding(Unknown Source)
at javax.crypto.Cipher$a.a(Unknown Source)
... 2 more

OpenJDK 7
/usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java PaddingIssue
Fine!

Full stacktrace:
Mar 22, 2016 3:54:13 PM hudson.remoting.jnlp.Main$CuiListener status
INFO: Trying protocol: JNLP3-connect
Mar 22, 2016 3:54:14 PM hudson.remoting.jnlp.Main$CuiListener error
SEVERE: Failed to create handshake ciphers
java.lang.AssertionError: Failed to create handshake ciphers
at org.jenkinsci.remoting.engine.HandshakeCiphers.create(HandshakeCiphers.java:116)
at org.jenkinsci.remoting.engine.JnlpProtocol3.performHandshake(JnlpProtocol3.java:138)
at org.jenkinsci.remoting.engine.JnlpProtocol.establishChannel(JnlpProtocol.java:77)
at hudson.remoting.Engine.run(Engine.java:308)
Caused by: java.security.NoSuchAlgorithmException: Cannot find any provider supporting AES/CTR/PKCS5Padding
at javax.crypto.Cipher.getInstance(Unknown Source)
at org.jenkinsci.remoting.engine.HandshakeCiphers.create(HandshakeCiphers.java:109)
... 3 more
Caused by: javax.crypto.NoSuchPaddingException: CTR mode must be used with ISO10
126Padding or NoPadding
at com.ibm.crypto.provider.AESCipher.engineSetPadding(Unknown Source)
at javax.crypto.Cipher$a_.a(Unknown Source)
... 5 more

Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
Atlassian logo

gabarmas@ie.ibm.com (JIRA)

unread,
Apr 8, 2016, 7:09:01 AM4/8/16
to jenkinsc...@googlegroups.com
Gabriel Lopez updated an issue
Change By: Gabriel Lopez
It is not possible to run slaves anymore using IBM Java.

This is due to the new [encrypted communication|https://issues.jenkins-ci.org/browse/JENKINS-26580] introduced in Jenkins 1.653, where the handshake is done [using "AES/CTR/PKCS5Padding"|https://github.com/jenkinsci/remoting/blob/master/src/main/java/org/jenkinsci/remoting/engine/HandshakeCiphers.java#L109].

I couldn't find what ciphers IBM Java does or doesn't support (maybe nothing else than the [default ones|https://www.ibm.com/support/knowledgecenter/SSYKE2_7.0.0/com.ibm.java.security.api.doc/jce/javax/crypto/Cipher.html]), but I created a quick test to check . See  (see  below ) .


Would it be possible to switch to a cipher supported by IBM Java?

* Test: *
import java.security.NoSuchAlgorithmException;
import javax.crypto.Cipher;
import javax.crypto.NoSuchPaddingException;

public class PaddingIssue {
private static final String CIPHER = "AES/CTR/PKCS5Padding";

public static void main(String[] args) throws NoSuchAlgorithmException, NoSuchPaddingException {
        Cipher encryptCipher = Cipher.getInstance(CIPHER);
        System.out.println("Fine!");
}
}

* Executions: *
* Full stacktrace: *
Mar 22, 2016 3:54:13 PM hudson.remoting.jnlp.Main$CuiListener status
INFO: Trying protocol: JNLP3-connect
Mar 22, 2016 3:54:14 PM hudson.remoting.jnlp.Main$CuiListener error
SEVERE: Failed to create handshake ciphers
java.lang.AssertionError: Failed to create handshake ciphers
        at org.jenkinsci.remoting.engine.HandshakeCiphers.create(HandshakeCiphers.java:116)
        at org.jenkinsci.remoting.engine.JnlpProtocol3.performHandshake(JnlpProtocol3.java:138)
        at org.jenkinsci.remoting.engine.JnlpProtocol.establishChannel(JnlpProtocol.java:77)
        at hudson.remoting.Engine.run(Engine.java:308)
Caused by: java.security.NoSuchAlgorithmException: Cannot find any provider supporting AES/CTR/PKCS5Padding
        at javax.crypto.Cipher.getInstance(Unknown Source)
        at org.jenkinsci.remoting.engine.HandshakeCiphers.create(HandshakeCiphers.java:109)
        ... 3 more
Caused by: javax.crypto.NoSuchPaddingException: CTR mode must be used with ISO10
126Padding or NoPadding
        at com.ibm.crypto.provider.AESCipher.engineSetPadding(Unknown Source)
        at javax.crypto.Cipher$a_.a(Unknown Source)
        ... 5 more

dbeck@cloudbees.com (JIRA)

unread,
Apr 11, 2016, 12:03:01 PM4/11/16
to jenkinsc...@googlegroups.com

dbeck@cloudbees.com (JIRA)

unread,
Apr 11, 2016, 12:03:01 PM4/11/16
to jenkinsc...@googlegroups.com
Daniel Beck updated an issue
 
Change By: Daniel Beck
Component/s: remoting
Component/s: core

nicholas.young@microfocus.com (JIRA)

unread,
May 9, 2016, 7:08:01 AM5/9/16
to jenkinsc...@googlegroups.com
nyoung02 commented on Bug JENKINS-34121
 
Re: IBM Java doesn't support AES/CTR/PKCS5Padding, required for JNLP3

Hitting the same problem. As I work on platforms where the IBM JRE is the only option, this will stop me from upgrading my Jenkins instance.

If it helps, I reverted the slave.jar file to an old one from another instance of Jenkins running on the same machine and this connects successfully using Jenkins 1.656, giving me a workaround of sorts.

The version number of the slave that will connect is at 2.33.

dbeck@cloudbees.com (JIRA)

unread,
May 9, 2016, 7:14:03 AM5/9/16
to jenkinsc...@googlegroups.com

What happens when you remove the JNLP3 protocol from the list of supported protocols on Jenkins master?

CC stephenconnolly who's planning to implement JNLP4, maybe this can be considered.

stephenconnolly@java.net (JIRA)

unread,
May 9, 2016, 12:38:02 PM5/9/16
to jenkinsc...@googlegroups.com

So the JNLP4 protocol is implemented already. I am just awaiting approval to release the code. As it uses TLS rather than a home grown cipher system this should not be an issue for JNLP4. (The other change with JNLP4 is that it uses NIO whereas JNLP3 dropped the NIO support)

If you remove JNLP3 from the list of supported protocols then it should fall back to JNLP2 if I recall the code correctly

nicholas.young@microfocus.com (JIRA)

unread,
May 10, 2016, 3:50:01 AM5/10/16
to jenkinsc...@googlegroups.com
nyoung02 commented on Bug JENKINS-34121

I have a system I can try it on so I'm happy to give it a try and see as a workaround - but how do I remove JNLP3 from the list of supported protocols?!

dbeck@cloudbees.com (JIRA)

unread,
May 10, 2016, 4:29:03 AM5/10/16
to jenkinsc...@googlegroups.com
java -Djenkins.slaves.JnlpSlaveAgentProtocol3.enabled=false -jar jenkins.war

should do it.

nicholas.young@microfocus.com (JIRA)

unread,
May 10, 2016, 4:49:01 AM5/10/16
to jenkinsc...@googlegroups.com
nyoung02 commented on Bug JENKINS-34121

I started Jenkins using that property, all started ok. This appeared in the console output for the master when I tried to connect a slave:

WARNING: Connection #1 failed
java.io.EOFException
        at java.io.DataInputStream.readUnsignedShort(Unknown Source)
        at java.io.DataInputStream.readUTF(Unknown Source)
        at java.io.DataInputStream.readUTF(Unknown Source)
        at hudson.TcpSlaveAgentListener$ConnectionHandler.run(TcpSlaveAgentListe
ner.java:175)

And the slave still fails to connect:

May 10, 2016 9:41:11 AM hudson.remoting.jnlp.Main$CuiListener status
INFO: Trying protocol: JNLP3-connect
May 10, 2016 9:41:12 AM hudson.remoting.jnlp.Main$CuiListener error
SEVERE: Failed to create handshake ciphers
java.lang.AssertionError: Failed to create handshake ciphers
        at org.jenkinsci.remoting.engine.HandshakeCiphers.create(HandshakeCipher
s.java:116)
        at org.jenkinsci.remoting.engine.JnlpProtocol3.performHandshake(JnlpProt
ocol3.java:138)
        at org.jenkinsci.remoting.engine.JnlpProtocol.establishChannel(JnlpProto
col.java:77)
        at hudson.remoting.Engine.run(Engine.java:308)
Caused by: java.security.NoSuchAlgorithmException: Cannot find any provider supp
orting AES/CTR/PKCS5Padding
        at javax.crypto.Cipher.getInstance(Unknown Source)
        at org.jenkinsci.remoting.engine.HandshakeCiphers.create(HandshakeCipher
s.java:109)
        ... 3 more
Caused by: javax.crypto.NoSuchPaddingException: CTR mode must be used with ISO10
126Padding or NoPadding
        at com.ibm.crypto.provider.AESCipher.engineSetPadding(Unknown Source)
        at javax.crypto.Cipher$a_.a(Unknown Source)
        ... 5 more

So it looks like the slave is still trying to connect with JNLP3. I tried passing the same property to the slave.jar in case the intention was to use it there, with no effect.

stephenconnolly@java.net (JIRA)

unread,
May 10, 2016, 5:57:01 AM5/10/16
to jenkinsc...@googlegroups.com

Yeah looks like there is no way to disable the client protocol: https://github.com/jenkinsci/remoting/blob/master/src/main/java/org/jenkinsci/remoting/engine/JnlpProtocolFactory.java#L54

So just use an older slave.jar as that will not try JNLP3 at all.

I will be fixing that code up to allow control of the individual protocols when I merge by JNLP4 protocol

stephenconnolly@java.net (JIRA)

unread,
May 10, 2016, 5:58:01 AM5/10/16
to jenkinsc...@googlegroups.com

(by fixing up I mean refactoring into something else)

scm_issue_link@java.net (JIRA)

unread,
May 12, 2016, 4:47:01 AM5/12/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Stephen Connolly
Path:
src/main/java/hudson/remoting/Engine.java
src/main/java/org/jenkinsci/remoting/engine/JnlpProtocol.java
http://jenkins-ci.org/commit/remoting/04037ec8ee633109c557d8f5f35922f2e2f495fc
Log:
[Related to JENKINS-34121] Allow disabling the protocols individually

  • Also ensure that a fatal unexpected error in one protocol does not prevent a fall-back

scm_issue_link@java.net (JIRA)

unread,
May 12, 2016, 11:49:01 AM5/12/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Stephen Connolly
Path:
src/main/java/hudson/remoting/Engine.java
src/main/java/org/jenkinsci/remoting/engine/JnlpProtocol.java

http://jenkins-ci.org/commit/remoting/43793e5b46f223c57f0a7b137cd983903fd63446
Log:
[Related to JENKINS-34121] Allow disabling the protocols individually (#83)

  • Also ensure that a fatal unexpected error in one protocol does not prevent a fall-back

o.v.nenashev@gmail.com (JIRA)

unread,
May 13, 2016, 2:05:02 PM5/13/16
to jenkinsc...@googlegroups.com

Workaround - Disable JNLP3 protocol.
This workaround has been implemented by Stephen and released as remoting 2.59.
Should become available in the next weekly, may be a subject for backporting into the next LTS release (1.651.3)

scm_issue_link@java.net (JIRA)

unread,
May 14, 2016, 5:00:05 AM5/14/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Oleg Nenashev
Path:
pom.xml
http://jenkins-ci.org/commit/jenkins/409438f36dc80f20964fb16f8d88041e11ba4ed4
Log:
[JENKINS-19445, JENKINS-34213, JENKINS-34808, JENKINS-34121] Bump remoting to 2.59. (#2344)

  • [JENKINS-19445, JENKINS-34213, JENKINS-34808] Bump remoting to 2.58.

Changes:

scm_issue_link@java.net (JIRA)

unread,
May 25, 2016, 4:26:09 AM5/25/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Oleg Nenashev
Path:
pom.xml


Log:
[JENKINS-19445, JENKINS-34213, JENKINS-34808, JENKINS-34121] Bump remoting to 2.59. (#2344)

  • [JENKINS-19445, JENKINS-34213, JENKINS-34808] Bump remoting to 2.58.

Changes:

(cherry picked from commit 409438f36dc80f20964fb16f8d88041e11ba4ed4)

ogondza@gmail.com (JIRA)

unread,
May 25, 2016, 7:48:01 AM5/25/16
to jenkinsc...@googlegroups.com

The workaround will be available in 1.651.3 LTS.

scm_issue_link@java.net (JIRA)

unread,
Mar 7, 2017, 3:25:07 AM3/7/17
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Oleg Nenashev
Path:
docs/protocols.md
src/main/java/org/jenkinsci/remoting/engine/JnlpProtocol3Handler.java
http://jenkins-ci.org/commit/remoting/fe2587b7f9d78334e0ab05ab0b95f39b4b600a25
Log:
Docs - Noting JENKINS-37302, JENKINS-33886, and JENKINS-34121 in Errata

This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
Atlassian logo

scm_issue_link@java.net (JIRA)

unread,
Mar 7, 2017, 3:25:08 AM3/7/17
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Oleg Nenashev
Path:
docs/protocols.md
src/main/java/org/jenkinsci/remoting/engine/JnlpProtocol3Handler.java

o.v.nenashev@gmail.com (JIRA)

unread,
Mar 7, 2017, 3:45:02 AM3/7/17
to jenkinsc...@googlegroups.com
Oleg Nenashev resolved as Won't Fix
 

Closing as "Won't fix", upgrade to JNLP4 is the recommended solution.

If somebody wants to fix it, please feel free to reopen it and to create a pull request

Change By: Oleg Nenashev
Status: Open Resolved
Resolution: Won't Fix

srimanoj.kandala@outlook.com (JIRA)

unread,
Mar 23, 2017, 2:31:01 AM3/23/17
to jenkinsc...@googlegroups.com
Mallikarjuna Manoj Kandala commented on Bug JENKINS-34121
 
Re: IBM Java doesn't support AES/CTR/PKCS5Padding, required for JNLP3

Can someone please provide instructions to upgrade to JNLP4 ?

We prefer to use IBM JRE.

o.v.nenashev@gmail.com (JIRA)

unread,
Mar 23, 2017, 4:10:01 AM3/23/17
to jenkinsc...@googlegroups.com

Mallikarjuna Manoj Kandala

1) Upgrade to Jenkins 2.32.1 or above
2) Go to the Global Security Configuration in Manage Jenkins
3) Ensure that JNLP4 is allowed in protocol security settings

Reply all
Reply to author
Forward
0 new messages