mitmproxy/mitmproxy

RSA-10241024-bit Already broken 4 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. test/mitmproxy/data/confdir/mitmproxy-ca-cert.cer:1 test path -----BEGIN CERTIFICATE-----
2. test/mitmproxy/data/confdir/mitmproxy-ca-cert.pem:1 test path -----BEGIN CERTIFICATE-----
3. test/mitmproxy/data/confdir/mitmproxy-ca.pem:16 test path -----BEGIN CERTIFICATE-----
4. test/mitmproxy/data/testkey.pem:16 test path -----BEGIN CERTIFICATE-----

pem.certificate

MD5 Already broken 1 place See details

Broken hash function

`hashlib.md5()` or `hashlib.sha1()`. Both have practical collisions. Where the call is annotated `usedforsecurity=False` the finding is recorded as inventory instead.

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, or SHA-384 for long-lived signatures.

1. mitmproxy/utils/magisk.py:90 full_hash = hashlib.md5(ca.subject.public_bytes()).digest()

py.hashlib.weak · CWE-328

SHA-1 Already broken 1 place See details

Broken hash function

`hashlib.md5()` or `hashlib.sha1()`. Both have practical collisions. Where the call is annotated `usedforsecurity=False` the finding is recorded as inventory instead.

This is already unsafe today, with no quantum computer involved. SHAttered and subsequent work produced practical collisions; NIST withdrew SHA-1 in 2030 guidance and it is already unacceptable for signatures.

What to do. SHA-256, or SHA-384 for long-lived signatures.

1. mitmproxy/utils/htpasswd.py:77 digest = hashlib.sha1(password.encode("utf-8")).digest()

py.hashlib.weak · CWE-328

RSA2048-bit Quantum-vulnerable 24 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. test/mitmproxy/data/clientcert/127.0.0.1.pem:28 test path -----BEGIN CERTIFICATE-----
2. test/mitmproxy/data/clientcert/client.pem:28 test path -----BEGIN CERTIFICATE-----
3. test/mitmproxy/data/mitmproxy.pem:31 test path -----BEGIN CERTIFICATE-----
4. test/mitmproxy/data/servercert/self-signed.pem:1 test path -----BEGIN CERTIFICATE-----
5. test/mitmproxy/data/servercert/trusted-leaf.pem:1 test path -----BEGIN CERTIFICATE-----
6. test/mitmproxy/data/servercert/trusted-root.pem:1 test path -----BEGIN CERTIFICATE-----
7. test/mitmproxy/net/data/clientcert/client.pem:28 test path -----BEGIN CERTIFICATE-----
8. test/mitmproxy/net/data/server.crt:1 test path -----BEGIN CERTIFICATE-----
9. test/mitmproxy/net/data/verificationcerts/example.mitmproxy.org.pem:1 test path -----BEGIN CERTIFICATE-----
10. test/mitmproxy/net/data/verificationcerts/invalid-crl.crt:1 test path -----BEGIN CERTIFICATE-----
11. test/mitmproxy/net/data/verificationcerts/private-public-mismatch.pem:1 test path -----BEGIN CERTIFICATE-----
12. test/mitmproxy/net/data/verificationcerts/self-signed.crt:1 test path -----BEGIN CERTIFICATE-----
13. test/mitmproxy/net/data/verificationcerts/self-signed.pem:1 test path -----BEGIN CERTIFICATE-----
14. test/mitmproxy/net/data/verificationcerts/trusted-chain-invalid.pem:1 test path -----BEGIN CERTIFICATE-----
15. test/mitmproxy/net/data/verificationcerts/trusted-chain.pem:1 test path -----BEGIN CERTIFICATE-----
16. test/mitmproxy/net/data/verificationcerts/trusted-chain.pem:49 test path -----BEGIN CERTIFICATE-----
17. test/mitmproxy/net/data/verificationcerts/trusted-client-cert.crt:1 test path -----BEGIN CERTIFICATE-----
18. test/mitmproxy/net/data/verificationcerts/trusted-client-cert.pem:1 test path -----BEGIN CERTIFICATE-----
19. test/mitmproxy/net/data/verificationcerts/trusted-leaf-ip.crt:1 test path -----BEGIN CERTIFICATE-----
20. test/mitmproxy/net/data/verificationcerts/trusted-leaf-ip.pem:1 test path -----BEGIN CERTIFICATE-----
21. test/mitmproxy/net/data/verificationcerts/trusted-leaf.crt:1 test path -----BEGIN CERTIFICATE-----
22. test/mitmproxy/net/data/verificationcerts/trusted-leaf.pem:1 test path -----BEGIN CERTIFICATE-----
23. test/mitmproxy/net/data/verificationcerts/trusted-root.crt:1 test path -----BEGIN CERTIFICATE-----
24. test/mitmproxy/net/data/verificationcerts/trusted-root.pem:1 test path -----BEGIN CERTIFICATE-----

pem.certificate

RSA Quantum-vulnerable Recorded traffic 18 places 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/mitmproxy/data/clientcert/127.0.0.1.pem:1 test path -----BEGIN RSA PRIVATE KEY-----
2. test/mitmproxy/data/clientcert/client.pem:1 test path -----BEGIN RSA PRIVATE KEY-----
3. test/mitmproxy/data/confdir/mitmproxy-ca.pem:1 test path -----BEGIN RSA PRIVATE KEY-----
4. test/mitmproxy/data/no_common_name.pem:1 test path -----BEGIN RSA PRIVATE KEY-----
5. test/mitmproxy/data/servercert/self-signed.pem:23 test path -----BEGIN RSA PRIVATE KEY-----
6. test/mitmproxy/data/servercert/trusted-leaf.pem:21 test path -----BEGIN RSA PRIVATE KEY-----
7. test/mitmproxy/data/servercert/trusted-root.pem:22 test path -----BEGIN RSA PRIVATE KEY-----
8. test/mitmproxy/data/testkey.pem:1 test path -----BEGIN RSA PRIVATE KEY-----
9. test/mitmproxy/net/data/clientcert/client.pem:1 test path -----BEGIN RSA PRIVATE KEY-----
10. test/mitmproxy/net/data/verificationcerts/private-public-mismatch.pem:22 test path -----BEGIN RSA PRIVATE KEY-----
11. test/mitmproxy/net/data/verificationcerts/self-signed.key:1 test path -----BEGIN RSA PRIVATE KEY-----
12. test/mitmproxy/net/data/verificationcerts/self-signed.pem:23 test path -----BEGIN RSA PRIVATE KEY-----
13. test/mitmproxy/net/data/verificationcerts/trusted-chain-invalid.pem:22 test path -----BEGIN RSA PRIVATE KEY-----
14. test/mitmproxy/net/data/verificationcerts/trusted-chain.pem:22 test path -----BEGIN RSA PRIVATE KEY-----
15. test/mitmproxy/net/data/verificationcerts/trusted-leaf-ip.key:1 test path -----BEGIN RSA PRIVATE KEY-----
16. test/mitmproxy/net/data/verificationcerts/trusted-leaf-ip.pem:21 test path -----BEGIN RSA PRIVATE KEY-----
17. test/mitmproxy/net/data/verificationcerts/trusted-root.key:1 test path -----BEGIN RSA PRIVATE KEY-----
18. test/mitmproxy/net/data/verificationcerts/trusted-root.pem:22 test path -----BEGIN RSA PRIVATE KEY-----

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

ECDH Quantum-vulnerable Recorded traffic 16 places See details

TLS cipher suite named in source

A cipher suite written into the code rather than into a configuration file - `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256`, or the OpenSSL spelling `ECDHE-RSA-AES128-GCM-SHA256`. The key exchange is reported, and the bulk cipher separately when it is one of the broken ones.

This code names the exact cryptography its TLS connections may use. Because the list is in the program rather than in a settings file, changing it needs a new release - which is the thing that makes a migration slow.

What to do. A hardcoded suite list ships with the binary and cannot be changed without a release, so move it to configuration first. The key exchange changes when the TLS library offers a hybrid group, not before.

1. mitmproxy/addons/tlsconfig.py:35 "ECDHE-ECDSA-AES128-GCM-SHA256",
2. mitmproxy/addons/tlsconfig.py:36 "ECDHE-RSA-AES128-GCM-SHA256",
3. mitmproxy/addons/tlsconfig.py:37 "ECDHE-ECDSA-AES256-GCM-SHA384",
4. mitmproxy/addons/tlsconfig.py:38 "ECDHE-RSA-AES256-GCM-SHA384",
5. mitmproxy/addons/tlsconfig.py:39 "ECDHE-ECDSA-CHACHA20-POLY1305",
6. mitmproxy/addons/tlsconfig.py:40 "ECDHE-RSA-CHACHA20-POLY1305",
7. mitmproxy/addons/tlsconfig.py:44 "ECDHE-ECDSA-AES128-SHA256",
8. mitmproxy/addons/tlsconfig.py:45 "ECDHE-RSA-AES128-SHA256",
9. mitmproxy/addons/tlsconfig.py:46 "ECDHE-ECDSA-AES128-SHA",
10. mitmproxy/addons/tlsconfig.py:47 "ECDHE-RSA-AES128-SHA",
11. mitmproxy/addons/tlsconfig.py:48 "ECDHE-ECDSA-AES256-SHA384",
12. mitmproxy/addons/tlsconfig.py:49 "ECDHE-RSA-AES256-SHA384",
13. mitmproxy/addons/tlsconfig.py:50 "ECDHE-ECDSA-AES256-SHA",
14. mitmproxy/addons/tlsconfig.py:51 "ECDHE-RSA-AES256-SHA",
15. test/mitmproxy/addons/test_tlsconfig.py:261 test path ciphers_client="ECDHE-ECDSA-AES128-GCM-SHA256",
16. test/mitmproxy/addons/test_tlsconfig.py:329 test path ctx.client.cipher_list = ["TLS_AES_256_GCM_SHA384", "ECDHE-RSA-AES128-SHA"]

config.cipher-suite · CWE-757

RSA Quantum-vulnerable Recorded traffic 12 places See details

RSA key generated with pyca/cryptography

`rsa.generate_private_key()`. The `key_size` argument is read where it is a literal and reported on the finding; it does not change the classification, because Shor is polynomial in the modulus size.

A quantum computer of sufficient size breaks this completely. It has to be replaced, not tuned. Broken by Shor's algorithm on a cryptographically relevant quantum computer.

What to do. ML-KEM-768 for encryption and ML-DSA-65 for signatures.

1. mitmproxy/certs.py:165 if isinstance(public_key, rsa.RSAPublicKey):
2. mitmproxy/certs.py:236 ) -> tuple[rsa.RSAPrivateKeyWithSerialization, x509.Certificate]:
3. mitmproxy/certs.py:239 private_key = rsa.generate_private_key(
4. mitmproxy/certs.py:315 privkey: rsa.RSAPrivateKey,
5. mitmproxy/certs.py:408 privkey: rsa.RSAPrivateKey,
6. mitmproxy/certs.py:434 privatekey: rsa.RSAPrivateKey
7. mitmproxy/certs.py:452 default_privatekey: rsa.RSAPrivateKey
8. mitmproxy/certs.py:462 default_privatekey: rsa.RSAPrivateKey,
9. mitmproxy/certs.py:571 key: rsa.RSAPrivateKeyWithSerialization
10. mitmproxy/certs.py:731 def load_pem_private_key(data: bytes, password: bytes | None) -> rsa.RSAPrivateKey:
11. mitmproxy/proxy/layers/quic/_hooks.py:30 dsa.DSAPrivateKey | ec.EllipticCurvePrivateKey | rsa.RSAPrivateKey | None
12. test/mitmproxy/test_certs.py:198 test path ) -> tuple[rsa.RSAPrivateKey, x509.Certificate]:

py.cryptography.rsa · CWE-327

RSA2048-bit Quantum-vulnerable Recorded traffic 6 places 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/mitmproxy/net/data/server.key:1 test path -----BEGIN PRIVATE KEY-----
2. test/mitmproxy/net/data/verificationcerts/example.mitmproxy.org.pem:23 test path -----BEGIN PRIVATE KEY-----
3. test/mitmproxy/net/data/verificationcerts/trusted-client-cert.key:1 test path -----BEGIN PRIVATE KEY-----
4. test/mitmproxy/net/data/verificationcerts/trusted-client-cert.pem:23 test path -----BEGIN PRIVATE KEY-----
5. test/mitmproxy/net/data/verificationcerts/trusted-leaf.key:1 test path -----BEGIN PRIVATE KEY-----
6. test/mitmproxy/net/data/verificationcerts/trusted-leaf.pem:23 test path -----BEGIN PRIVATE KEY-----

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

DH Quantum-vulnerable Recorded traffic 5 places See details

TLS cipher suite named in source

A cipher suite written into the code rather than into a configuration file - `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256`, or the OpenSSL spelling `ECDHE-RSA-AES128-GCM-SHA256`. The key exchange is reported, and the bulk cipher separately when it is one of the broken ones.

This code names the exact cryptography its TLS connections may use. Because the list is in the program rather than in a settings file, changing it needs a new release - which is the thing that makes a migration slow.

What to do. A hardcoded suite list ships with the binary and cannot be changed without a release, so move it to configuration first. The key exchange changes when the TLS library offers a hybrid group, not before.

1. mitmproxy/addons/tlsconfig.py:41 "DHE-RSA-AES128-GCM-SHA256",
2. mitmproxy/addons/tlsconfig.py:42 "DHE-RSA-AES256-GCM-SHA384",
3. mitmproxy/addons/tlsconfig.py:43 "DHE-RSA-CHACHA20-POLY1305",
4. mitmproxy/addons/tlsconfig.py:52 "DHE-RSA-AES128-SHA256",
5. mitmproxy/addons/tlsconfig.py:53 "DHE-RSA-AES256-SHA256",

config.cipher-suite · CWE-757

DH Quantum-vulnerable 3 places See details

Public key file

A PEM public-key block. The algorithm is read from the SubjectPublicKeyInfo.

A quantum computer of sufficient size breaks this completely. It has to be replaced, not tuned. Broken by Shor's algorithm on a cryptographically relevant quantum computer.

What to do. Inventory only; a public key is not itself a secret.

1. mitmproxy/certs.py:48 -----BEGIN DH PARAMETERS-----
2. test/mitmproxy/data/confdir/mitmproxy-dhparam.pem:2 test path -----BEGIN DH PARAMETERS-----
3. test/mitmproxy/net/data/dhparam.pem:1 test path -----BEGIN DH PARAMETERS-----

pem.public-key

RSA2048-bit Quantum-vulnerable Recorded traffic 3 places See details

RSA key generated with pyca/cryptography

`rsa.generate_private_key()`. The `key_size` argument is read where it is a literal and reported on the finding; it does not change the classification, because Shor is polynomial in the modulus size.

A quantum computer of sufficient size breaks this completely. It has to be replaced, not tuned. Broken by Shor's algorithm on a cryptographically relevant quantum computer.

What to do. ML-KEM-768 for encryption and ML-DSA-65 for signatures.

1. test/mitmproxy/test_certs.py:200 test path key = rsa.generate_private_key(public_exponent=65537, key_size=2048)
2. test/mitmproxy/test_certs.py:227 test path rsa.generate_private_key(public_exponent=65537, key_size=2048)
3. test/mitmproxy/test_certs.py:248 test path key = rsa.generate_private_key(public_exponent=65537, key_size=2048)

py.cryptography.rsa · CWE-327

DSA 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. test/mitmproxy/data/invalid-subject.pem:1 test path -----BEGIN CERTIFICATE-----
2. test/mitmproxy/net/data/dsa_cert.pem:1 test path -----BEGIN CERTIFICATE-----

pem.certificate

TLS Quantum-vulnerable Recorded traffic 2 places See details

TLS protocol version pinned in code

An `ssl.PROTOCOL_*` constant or `ssl.SSLContext(...)`. Versions below TLS 1.2 are broken classically; TLS 1.2 and 1.3 both negotiate a classical key exchange.

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.3, and add a hybrid key-exchange group once the platform offers one.

1. test/mitmproxy/proxy/layers/test_tls.py:99 test path self.ctx = ssl.SSLContext(
2. test/mitmproxy/proxy/layers/test_tls.py:100 test path ssl.PROTOCOL_TLS_SERVER if server_side else ssl.PROTOCOL_TLS_CLIENT

py.ssl.protocol · CWE-757

ECDSA256-bitsecg/secp256r1 Quantum-vulnerable 1 place 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. test/mitmproxy/net/data/ec_cert.pem:1 test path -----BEGIN CERTIFICATE-----

pem.certificate

RSA4096-bit Quantum-vulnerable 1 place 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. test/mitmproxy/data/no_common_name.pem:52 test path -----BEGIN CERTIFICATE-----

pem.certificate

SHA-256 Reduced margin 5 places See details

Hash function in use

`hashlib.sha256()` and friends. The digest is read from the call, so SHA-384 and above are inventory while the broken ones are reported separately.

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 long-lived.

1. mitmproxy/addons/serverplayback.py:223 return hashlib.sha256(repr(key).encode("utf8", "surrogateescape")).digest()
2. mitmproxy/tools/web/app.py:142 content_hash = hashlib.sha256(flow.request.raw_content).hexdigest()
3. mitmproxy/tools/web/app.py:163 content_hash = hashlib.sha256(flow.response.raw_content).hexdigest()
4. release/build.py:333 ib_setup_hash = hashlib.sha256()
5. test/mitmproxy/test_certs.py:234 test path sha256_ski_digest = hashlib.sha256(pub_der).digest()[:20]

py.hashlib

unknown Could not be determined 4 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. docs/src/content/concepts/certificates.md:132 -----BEGIN CERTIFICATE-----
2. docs/src/content/concepts/certificates.md:135 -----BEGIN CERTIFICATE-----
3. docs/src/content/concepts/certificates.md:181 -----BEGIN CERTIFICATE-----
4. test/mitmproxy/net/data/verificationcerts/trusted-chain-invalid.pem:49 test path -----BEGIN CERTIFICATE-----

pem.certificate

unknown Could not be determined 3 places 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. docs/src/content/concepts/certificates.md:129 -----BEGIN PRIVATE KEY-----
2. docs/src/content/concepts/certificates.md:178 -----BEGIN PRIVATE KEY-----
3. test/mitmproxy/data/mitmproxy.pem:1 test path -----BEGIN ENCRYPTED PRIVATE KEY-----

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

unknown Could not be determined 1 place See details

Cryptographic library in the dependency manifest

A dependency known to implement classical asymmetric cryptography. Its presence is inventory, not a finding about this codebase: the library may never be called with a quantum-vulnerable algorithm.

The project depends on a cryptography library. Listed so the inventory is complete; it is not by itself a problem.

What to do. Check the version. Several of these libraries have shipped ML-KEM and ML-DSA support since 2024, so the migration may need an upgrade rather than a replacement.

1. pyproject.toml:41 "cryptography>=42.0,<=50.0.0", # relaxed upper bound here to get security fixes

dep.crypto-library

CSPRNG Quantum-safe 5 places See details

Random number generation

`secrets.token_bytes()`, `os.urandom()` or `ssl.RAND_bytes()`. Recorded so the inventory names its randomness source.

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

What to do. No action. `random.random()` is a separate, present-day defect if it reaches key material.

1. mitmproxy/http.py:990 boundary = "-" * 20 + binascii.hexlify(os.urandom(16)).decode()
2. mitmproxy/tools/web/app.py:934 cookie_secret=secrets.token_bytes(32),
3. mitmproxy/tools/web/webaddons.py:27 self._password = secrets.token_hex(16)
4. test/helper_tools/memoryleak2.py:16 test path commonname=secrets.token_hex(16).encode(), sans=[], organization=None
5. test/mitmproxy/proxy/layers/test_websocket.py:51 test path mask = secrets.token_bytes(4)

py.rng

bcrypt Quantum-safe 1 place See details

Password hashing or key derivation

A password hashing or key derivation function. Not a quantum exposure, and part of a complete inventory.

This is how passwords are stored. Quantum computers do not meaningfully weaken it.

What to do. Argon2id for new work. PBKDF2 needs a high iteration count to stay defensible.

1. mitmproxy/utils/htpasswd.py:81 return bcrypt.checkpw(password.encode("utf-8"), pwhash.encode("utf-8"))

py.kdf