apache/httpcomponents-client

MD5 Already broken 10 places See details

HTTP Digest authentication

An HTTP Digest authentication implementation. RFC 7616 Digest is built on MD5 in its widely deployed form. This is not a quantum question: it is weak today and depends entirely on the TLS underneath it. HTTP Basic is deliberately not matched - it is base64 and contains no cryptography to inventory.

This is already unsafe today, with no quantum computer involved. Practical chosen-prefix collisions exist; MD5 has no remaining security as a digest.

What to do. Move to a token-based scheme. Where Digest must remain, use the SHA-256 variant.

1. httpclient5/src/main/java/org/apache/hc/client5/http/impl/async/H2AsyncClientBuilder.java:62 import org.apache.hc.client5.http.impl.auth.DigestSchemeFactory;
2. httpclient5/src/main/java/org/apache/hc/client5/http/impl/async/HttpAsyncClientBuilder.java:69 import org.apache.hc.client5.http.impl.auth.DigestSchemeFactory;
3. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/DigestScheme.java:88 public class DigestScheme implements AuthScheme, Serializable {
4. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/DigestSchemeFactory.java:46 public class DigestSchemeFactory implements AuthSchemeFactory {
5. httpclient5/src/main/java/org/apache/hc/client5/http/impl/classic/HttpClientBuilder.java:72 import org.apache.hc.client5.http.impl.auth.DigestSchemeFactory;
6. httpclient5/src/main/java/org/apache/hc/client5/http/impl/classic/ProxyClient.java:48 import org.apache.hc.client5.http.impl.auth.DigestSchemeFactory;
7. httpclient5/src/test/java/org/apache/hc/client5/http/examples/ClientPreemptiveDigestAuthentication.java:35 test path import org.apache.hc.client5.http.impl.auth.DigestScheme;
8. httpclient5/src/test/java/org/apache/hc/client5/http/impl/TestAuthenticationStrategy.java:45 test path import org.apache.hc.client5.http.impl.auth.DigestScheme;
9. httpclient5/src/test/java/org/apache/hc/client5/http/impl/auth/TestDigestScheme.java:81 test path final AuthScheme authscheme = new DigestScheme();
10. httpclient5/src/test/java/org/apache/hc/client5/http/impl/auth/TestHttpAuthenticator.java:95 test path .register(StandardAuthScheme.DIGEST, DigestSchemeFactory.INSTANCE)

java.httpauth · CWE-328

NTLM Already broken 10 places See details

NTLM authentication

An NTLM implementation. NTLM derives its credentials from MD4 and is broken by relay and offline cracking today; Microsoft has been deprecating it since 2024.

This is already unsafe today, with no quantum computer involved. NTLM authenticates with MD4-derived hashes and is broken by relay and cracking attacks today. Quantum computing is beside the point.

What to do. Kerberos, or a modern token-based scheme. This is a present-day defect, not a future one.

1. httpclient5-fluent/src/main/java/org/apache/hc/client5/http/fluent/Executor.java:200 return auth(host, new org.apache.hc.client5.http.auth.NTCredentials(username, password, workstation, domain));
2. httpclient5/src/main/java/org/apache/hc/client5/http/auth/NTCredentials.java:55 public class NTCredentials implements Credentials, Serializable {
3. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/NTLMEngine.java:39 public interface NTLMEngine {
4. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/NTLMEngineImpl.java:55 final class NTLMEngineImpl implements NTLMEngine {
5. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/NTLMScheme.java:60 public final class NTLMScheme implements AuthScheme {
6. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/NTLMSchemeFactory.java:59 return new NTLMScheme();
7. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/SystemDefaultCredentialsProvider.java:129 return new org.apache.hc.client5.http.auth.NTCredentials(
8. httpclient5/src/test/java/org/apache/hc/client5/http/auth/TestCredentials.java:61 test path final NTCredentials creds1 = new NTCredentials(
9. httpclient5/src/test/java/org/apache/hc/client5/http/impl/auth/TestNTLMEngineImpl.java:80 test path final NTLMEngineImpl.MD4 md4;
10. httpclient5/src/test/java/org/apache/hc/client5/http/impl/auth/TestNTLMScheme.java:46 test path final AuthScheme authScheme = new NTLMScheme();

java.ntlm · CWE-327

DES Already broken 4 places See details

Classical public-key cipher through the JCA

`Cipher.getInstance()` with a transformation whose algorithm component is a public-key or legacy symmetric cipher. The transformation string is parsed into algorithm, mode and padding, so `RSA/ECB/PKCS1Padding` is separated from `RSA/ECB/OAEPWithSHA-256AndMGF1Padding`.

This is already unsafe today, with no quantum computer involved. A 56-bit key is brute-forced classically in hours.

What to do. For RSA encryption, move to ML-KEM-768 and keep RSA-OAEP only as the classical half of a hybrid during transition.

1. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/NTLMEngineImpl.java:576 Cipher des = Cipher.getInstance("DES/ECB/NoPadding");
2. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/NTLMEngineImpl.java:579 des = Cipher.getInstance("DES/ECB/NoPadding");
3. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/NTLMEngineImpl.java:661 final Cipher des = Cipher.getInstance("DES/ECB/NoPadding");
4. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/NTLMEngineImpl.java:741 final Cipher des = Cipher.getInstance("DES/ECB/NoPadding");

java.cipher · CWE-327

MD5 Already broken 4 places See details

Hash algorithm through the JCA

`MessageDigest.getInstance()`. MD5 and SHA-1 are reported as already broken; SHA-256 is reported as a reduced margin rather than a defect.

This is already unsafe today, with no quantum computer involved. Practical chosen-prefix collisions exist; MD5 has no remaining security as a digest.

What to do. SHA-256 as the floor, SHA-384 where the digest protects something that must remain verifiable for decades.

1. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/NTLMEngineImpl.java:1828 return MessageDigest.getInstance("MD5");
2. httpclient5/src/test/java/org/apache/hc/client5/http/impl/auth/TestDigestScheme.java:589 test path final HttpEntityDigester digester = new HttpEntityDigester(MessageDigest.getInstance("MD5"));
3. httpclient5/src/test/java/org/apache/hc/client5/http/impl/auth/TestDigestScheme.java:770 test path final MessageDigest md = MessageDigest.getInstance("MD5");
4. httpclient5/src/test/java/org/apache/hc/client5/http/impl/auth/TestDigestScheme.java:814 test path final MessageDigest md = MessageDigest.getInstance("MD5");

java.messagedigest · CWE-328

RC4 Already broken 3 places See details

Key material constructed for a named algorithm

`new SecretKeySpec(bytes, "AES")` and the other key-spec constructors name the algorithm as an argument rather than through `getInstance()`. Code that wraps raw bytes into a key this way often never calls `getInstance()` at all, so the algorithm is invisible to a scan that only looks at the factories.

This wraps raw bytes into a key for a named algorithm. It is part of the same migration as whatever uses that key.

What to do. Wherever this key is used, the same migration applies as to the call that consumes it. Trace it to the operation and treat the two together.

1. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/NTLMEngineImpl.java:605 rc4.init(Cipher.ENCRYPT_MODE, new SecretKeySpec(key, "RC4"));
2. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/NTLMEngineImpl.java:847 cipher.init( Cipher.ENCRYPT_MODE, new SecretKeySpec( sealingKey, "RC4" ) );
3. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/NTLMEngineImpl.java:851 cipher.init( Cipher.DECRYPT_MODE, new SecretKeySpec( sealingKey, "RC4" ) );

java.keyspec · CWE-327

RC4 Already broken 2 places See details

Classical public-key cipher through the JCA

`Cipher.getInstance()` with a transformation whose algorithm component is a public-key or legacy symmetric cipher. The transformation string is parsed into algorithm, mode and padding, so `RSA/ECB/PKCS1Padding` is separated from `RSA/ECB/OAEPWithSHA-256AndMGF1Padding`.

This is already unsafe today, with no quantum computer involved. RC4 keystream biases break it classically; it is prohibited in TLS by RFC 7465.

What to do. For RSA encryption, move to ML-KEM-768 and keep RSA-OAEP only as the classical half of a hybrid during transition.

1. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/NTLMEngineImpl.java:604 final Cipher rc4 = Cipher.getInstance("RC4");
2. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/NTLMEngineImpl.java:844 cipher = Cipher.getInstance( "RC4" );

java.cipher · CWE-327

DES Already broken 1 place See details

Key material constructed for a named algorithm

`new SecretKeySpec(bytes, "AES")` and the other key-spec constructors name the algorithm as an argument rather than through `getInstance()`. Code that wraps raw bytes into a key this way often never calls `getInstance()` at all, so the algorithm is invisible to a scan that only looks at the factories.

This wraps raw bytes into a key for a named algorithm. It is part of the same migration as whatever uses that key.

What to do. Wherever this key is used, the same migration applies as to the call that consumes it. Trace it to the operation and treat the two together.

1. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/NTLMEngineImpl.java:1026 return new SecretKeySpec(material, "DES");

java.keyspec · CWE-327

RC4 Already broken 1 place See details

TLS cipher suites pinned in configuration

An `ssl_ciphers`, `SSLCipherSuite` or `ssl-default-bind-ciphers` directive. Every suite available today uses a classical key exchange; a suite naming RC4, DES, 3DES, EXPORT or NULL is broken now.

This is already unsafe today, with no quantum computer involved. RC4 keystream biases break it classically; it is prohibited in TLS by RFC 7465.

What to do. Remove anything below TLS 1.2. The key exchange changes when the server software offers a hybrid group, not before.

1. httpclient5-testing/docker/apache-httpd/httpd-ssl.conf:70 test path SSLCipherSuite HIGH:MEDIUM:!MD5:!RC4:!3DES

config.tls-ciphers · CWE-757

RSA2048-bit Quantum-vulnerable 2 places See details

X.509 certificate

A PEM certificate. The subject public-key algorithm and key size are read from the SubjectPublicKeyInfo structure, and the not-after date is reported so certificates that outlive the migration window are visible.

This is a digital identity document. Its expiry date matters: one valid for many years locks in today's algorithms for that long.

What to do. Shorten certificate lifetimes so re-issuing with a post-quantum key is routine.

1. httpclient5-testing/docker/apache-httpd/server-cert.pem:64 test path -----BEGIN CERTIFICATE-----
2. test-CA/ca-cert.pem:1 test path -----BEGIN CERTIFICATE-----

pem.certificate

RSA2048-bit Quantum-vulnerable Recorded traffic 1 place See details

Private key committed to the repository

A PEM private-key block. The header names the algorithm where the format is the legacy one; for PKCS#8 the algorithm OID is read out of the DER. A private key in version control is a present-day incident before it is a quantum question.

A secret key is stored in this repository's files. Anyone who can read the repository can use it. This needs attention today, regardless of quantum computers.

What to do. Revoke and rotate the key, then keep key material out of the repository. Record the algorithm in the inventory.

1. httpclient5-testing/docker/apache-httpd/server-key.pem:1 test path -----BEGIN PRIVATE KEY-----

pem.private-key · CWE-321, CWE-327

TLS Quantum-vulnerable Recorded traffic 1 place See details

TLS versions pinned in configuration

An `ssl_protocols` or `SSLProtocol` directive. SSLv3, TLS 1.0 and TLS 1.1 are withdrawn.

A quantum computer of sufficient size breaks this completely. It has to be replaced, not tuned. Every TLS cipher suite in general use negotiates a classical key exchange, so a recorded session is decryptable once that exchange falls.

What to do. TLS 1.2 as the floor, TLS 1.3 preferred.

1. httpclient5-testing/docker/apache-httpd/httpd-ssl.conf:97 test path SSLProtocol all -SSLv3

config.tls-protocols · CWE-757

Kerberos Reduced margin 5 places See details

Kerberos or SPNEGO authentication

`javax.security.auth.kerberos` or a GSS-API call. Kerberos itself is symmetric and survives Shor; its PKINIT certificate flow is public-key and does not. The encryption types configured for the realm decide whether it is also a present-day concern.

A quantum computer weakens this but does not break it. Increasing the key or digest size restores the margin. Kerberos is symmetric at its core, so Shor does not break it. The surrounding PKINIT certificate flow is public-key and does fall.

What to do. Restrict the realm to AES encryption types, and treat PKINIT certificates as part of the public-key migration.

1. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/GGSSchemeBase.java:49 import org.ietf.jgss.GSSContext;
2. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/KerberosScheme.java:52 public class KerberosScheme extends GGSSchemeBase {
3. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/KerberosSchemeFactory.java:79 return new KerberosScheme(this.config, this.dnsResolver);
4. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/SPNegoScheme.java:53 public class SPNegoScheme extends GGSSchemeBase {
5. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/SPNegoSchemeFactory.java:79 return new SPNegoScheme(this.config, this.dnsResolver);

java.kerberos

SHA-256 Reduced margin 3 places See details

Hash algorithm through the JCA

`MessageDigest.getInstance()`. MD5 and SHA-1 are reported as already broken; SHA-256 is reported as a reduced margin rather than a defect.

A quantum computer weakens this but does not break it. Increasing the key or digest size restores the margin. Pre-image resistance falls to about 128 bits of quantum work. Adequate for most uses; SHA-384 restores the full margin where a signature must last decades.

What to do. SHA-256 as the floor, SHA-384 where the digest protects something that must remain verifiable for decades.

1. httpclient5-cache/src/main/java/org/apache/hc/client5/http/impl/cache/FileResourceFactory.java:67 sha256 = MessageDigest.getInstance("SHA-256");
2. httpclient5-cache/src/main/java/org/apache/hc/client5/http/impl/cache/memcached/SHA256KeyHashingScheme.java:63 return MessageDigest.getInstance("SHA-256");
3. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/NTLMEngineImpl.java:1775 final MessageDigest sha256 = MessageDigest.getInstance( "SHA-256" );

java.messagedigest · CWE-328

unknown Could not be determined 10 places See details

Non-cryptographic randomness near key material

`new Random()` or `Math.random()` in a file that also imports `java.security`, `javax.crypto` or BouncyCastle. `java.util.Random` is a linear congruential generator and its output is predictable from a handful of samples. The import check is what keeps this from firing on every retry jitter and test fixture in the tree.

Part of this code uses a predictable source of random numbers. If any key comes from it, that key can be guessed today, with no quantum computer needed.

What to do. `java.security.SecureRandom`. This is a classical defect, not a quantum one, and it is worth fixing first.

1. httpclient5/src/test/java/org/apache/hc/client5/http/impl/auth/TestNTLMEngineImpl.java:101 test path new Random(1234),
2. httpclient5/src/test/java/org/apache/hc/client5/http/impl/auth/TestNTLMEngineImpl.java:121 test path new Random(1234),
3. httpclient5/src/test/java/org/apache/hc/client5/http/impl/auth/TestNTLMEngineImpl.java:141 test path new Random(1234),
4. httpclient5/src/test/java/org/apache/hc/client5/http/impl/auth/TestNTLMEngineImpl.java:161 test path new Random(1234),
5. httpclient5/src/test/java/org/apache/hc/client5/http/impl/auth/TestNTLMEngineImpl.java:183 test path new Random(1234),
6. httpclient5/src/test/java/org/apache/hc/client5/http/impl/auth/TestNTLMEngineImpl.java:203 test path new Random(1234),
7. httpclient5/src/test/java/org/apache/hc/client5/http/impl/auth/TestNTLMEngineImpl.java:223 test path new Random(1234),
8. httpclient5/src/test/java/org/apache/hc/client5/http/impl/auth/TestNTLMEngineImpl.java:250 test path new Random(1234),
9. httpclient5/src/test/java/org/apache/hc/client5/http/impl/auth/TestNTLMEngineImpl.java:259 test path new Random(1234),
10. httpclient5/src/test/java/org/apache/hc/client5/http/impl/auth/TestNTLMEngineImpl.java:297 test path new Random(1234),

java.random.insecure · CWE-338

unknown Could not be determined 1 place See details

Private key committed to the repository

A PEM private-key block. The header names the algorithm where the format is the legacy one; for PKCS#8 the algorithm OID is read out of the DER. A private key in version control is a present-day incident before it is a quantum question.

A secret key is stored in this repository's files. Anyone who can read the repository can use it. This needs attention today, regardless of quantum computers.

What to do. Revoke and rotate the key, then keep key material out of the repository. Record the algorithm in the inventory.

1. test-CA/ca-key.pem:1 test path -----BEGIN ENCRYPTED PRIVATE KEY-----

pem.private-key · CWE-321, CWE-327

CSPRNG Quantum-safe 4 places See details

Random number generation

`SecureRandom`. A platform CSPRNG is not a quantum exposure; it is recorded because an inventory that omits the randomness source is incomplete. `SHA1PRNG` is named explicitly where it appears, since it is a legacy algorithm even though its output is adequate.

This is where the software gets its random numbers. Quantum computers do not weaken it.

What to do. No action. Prefer the platform default over naming an algorithm.

1. httpclient5-testing/src/test/java/org/apache/hc/client5/testing/async/AbstractHttpAsyncClientAuthenticationTest.java:468 test path final SecureRandom secureRandom = SecureRandom.getInstanceStrong();
2. httpclient5-testing/src/test/java/org/apache/hc/client5/testing/sync/TestClientAuthentication.java:761 test path final SecureRandom secureRandom = SecureRandom.getInstanceStrong();
3. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/DigestScheme.java:532 final SecureRandom rnd = new SecureRandom();
4. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/NTLMEngineImpl.java:107 rnd = java.security.SecureRandom.getInstance("SHA1PRNG");

java.rng