jenkins

The Jenkins project uses standard open-source implementations of cryptographic protocols and algorithms (e.g. implemented by JVM, Bouncy Castle, MINA SSH, and other open-source libraries like eddsa for its Ed25519 implementation). There are also standard APIs offered to the plugin developers (e.g. for storing secrets).

The Jenkins core and its modules do not implement cryptography on their own in recent versions. They depend on open-source libraries which provide cryptography functions. There are historical cryptography APIs offered in Jenkins, but their internal implementations have been replaced by open-source cryptography libraries used in the project.

Additional notes about previous releases that are no longer supported:

• Jenkins Remoting layer used to implement encryption on its own in the JNLP3 protocol. This protocol was deprecated in Dec 2017 (Remoting 3.15) and then completely removed from the codebase in Dec 2019 (Remoting 3.40)
• The Jenkins core used to include cryptography implementations, e.g. a Jenkins-specific fork of the abandoned Trilead SSH library. It was removed from Jenkins 2.186 in July 2019 and is only included as detached plugin for backward compatibility with plugins depending on it, but not used by Jenkins itself.

Jenkins core is fully FLOSS, as well as its dependencies.

The Jenkins core generally does not manage the key lengths in the codebase. We use the default values provided by the recent versions of cryptography libraries. One of the exceptions is a CryptoConfidentialKey used in hudson.util.Secret and a few other locations. These occurrences use AES 128 by default, and it is compliant with the length requirement for symmetric keys.

We do NOT use broken cryptography algorithms for security mechanisms inside the Jenkins core or modules. In some cases MD5 is used to produce unique keys for Jenkins objects which are not used in a security context. Such objects have soft uniqueness requirements, and potential collisions do not compromise the Jenkins security or sensitive data.

Jenkins core generally does not rely on SHA-1 for security purposes. The only security-related use of SHA-1 in the Jenkins core is related to the validation of downloaded plugins and Jenkins .war files from update sites. This is only used as a fallback if the update site does not provide SHA-256 or SHA-512 checksums, and a warning is logged. Official Jenkins update sites have provided these better checksums since April 2018, so this only matters for third-party unofficial update sites, and only if downloads are not delivered via HTTPS.

CBC mode is not used by the Jenkins core, and the algorithm is removed from the SSHD Module which implements the SSH server side logic in Jenkins.

Note: In some cases we use AES encryption with default settings provided by JVM, without explicit padding and mode specification. This results in ECB usage in some circumstances in the case of the default JVM configuration. ECB is not optimal due to data correlation analysis weakness, but it is not considered as a serious weakness for short data objects. Jenkins users have an option to change the JVM defaults to enforce strong cryptography and other default AES modes.

In the majority of use-cases we use the default forward secrecy provided by 3rd-party open-source libraries (e.g. for establishing SSH connections). Same for HTTPS, the entire implementation is supplied by external libraries or projects (e.g. Eclipse Jetty bundled in the Jenkins core and used as a default web container).

The only exception is the Jenkins Remoting library that includes an implementation of the JNLP4-connect protocol for networking between the Jenkins server and agents. This protocol uses the standard TLS encryption layer provided by JVM (default version). As of Jenkins 2.235.1 LTS Jenkins supports Java 8 (TLS 1.2 by default, no TLS 1.3 implementation in OpenJDK) and Java 11 (TLS 1.2 or 1.3 are provided). TLS 1.2 does not enforce perfect forward secrecy by default, but users of Jenkins can enforce TLS 1.3 and forward secrecy with OpenJDK 11 or with other JVMs for Java 8/11. Jenkins admins can also elect to block the JNLP4-connect protocol over TCP, and to use the WebSocket connection over HTTP/HTTPS, in which case the encryption is delegated to the web server and reverse proxies.

In Jenkins we provide a private security realm which stores password hashes in the local filesystem database. This implementation uses BCrypt, and hence it is compatible with the requirements. It is also possible to use external authentication services (e.g. LDAP) which do not store user passwords in Jenkins. Jenkins Security Realm documentation

In the Jenkins core and modules we use the standard secure random number generator provided by the JVM. There are no custom implementations within the codebase.