How Implicit TLS Certificate Verification Happens in Python and How to Fix It

How Implicit TLS Certificate Verification Happens in Python and How to Fix It

The plugins/python-build/scripts/add_cpython.py file is responsible for a highly sensitive task: fetching CPython release metadata, OpenSSL release information, and cryptographic SHA-256 checksums from external sources to drive the build process. When this script fetches the wrong data — whether through a network fault or an active attacker — it can corrupt the entire CPython build pipeline. That's exactly the risk that was silently present in two requests.get() calls at lines 542 and 568.

The Vulnerability Explained

What Was Actually Wrong

At first glance, the code looks reasonable:

# Before — lines 542-543 (get_store_latest_release method)
response = requests.get(url, timeout=30)
response.raise_for_status()

# Before — line 568
shasum_text = requests.get(shasum_url, timeout=30).text

The first call fetches the list of OpenSSL releases from https://api.github.com/repos/openssl/openssl/releases. The second fetches a .sha256 checksum file from a browser_download_url asset associated with that release. Both are security-critical operations: the release list determines which OpenSSL version gets bundled, and the SHA-256 checksum is used to verify the integrity of the downloaded package.

The problem is implicit reliance on library defaults for certificate verification. The requests library defaults to verify=True, but this default is not immutable. It can be silently overridden by:

• The REQUESTS_CA_BUNDLE or CURL_CA_BUNDLE environment variables being set to an attacker-controlled certificate bundle
• Monkey-patching in test environments that accidentally leaks into production
• A future library version changing the default behavior
• A compromised dependency in the build environment modifying requests internals

Beyond the verification concern, the second call on line 568 is particularly dangerous because it omits raise_for_status():

# No error check — silently accepts a 404, 500, or attacker-injected response
shasum_text = requests.get(shasum_url, timeout=30).text

If an attacker intercepts this request and returns a crafted SHA-256 checksum file, the build script will parse it without ever knowing the response was tampered with.

The Attack Scenario

Consider a developer running add_cpython.py on a corporate network with a transparent TLS-intercepting proxy (common in enterprise environments). If the proxy's certificate is not in the system trust store, or if an attacker has compromised the proxy:

1. The attacker intercepts the request to api.github.com/repos/openssl/openssl/releases
2. They return a crafted JSON response pointing to a malicious OpenSSL release URL
3. The script follows the asset URL and fetches a .sha256 file — also served by the attacker
4. The attacker-controlled SHA-256 hash matches a trojanized OpenSSL tarball
5. The CPython build proceeds with a backdoored OpenSSL library

Because raise_for_status() was missing from the shasum_url fetch, even an HTTP error response would have been silently parsed, potentially causing a confusing failure or — worse — a successful build with malicious content.

This is a supply chain attack vector embedded directly in the build tooling.

The Fix

Introducing the Requests Wrapper Class

The fix consolidates all outbound HTTP calls into a single, auditable wrapper class added at line 741:

# After — new Requests wrapper class
class Requests:
    @staticmethod
    def get(url: str) -> requests.Response:
        response = requests.get(url, timeout=30)
        response.raise_for_status()
        return response

And the two call sites are updated to use it:

# After — line 542 (get_store_latest_release, GitHub API call)
response = Requests.get(url)

# After — line 568 (SHA-256 checksum fetch)
shasum_text = Requests.get(shasum_url).text

Why This Fix Works

Before vs. After — Side by Side:

The Requests class acts as a security boundary. Any future call added to this script that uses Requests.get() automatically inherits timeout enforcement, HTTP error checking, and the centralized location where verify=True can be explicitly added if needed. This is the defense-in-depth principle applied to HTTP client code.

To make this fix even more robust, the explicit verify=True parameter should be added to the wrapper:

# Recommended hardening of the wrapper
class Requests:
    @staticmethod
    def get(url: str) -> requests.Response:
        response = requests.get(url, timeout=30, verify=True)
        response.raise_for_status()
        return response

This makes the security intent explicit and immune to environment-level overrides.

Prevention & Best Practices

1. Always Centralize HTTP Client Configuration

Never scatter requests.get() calls throughout a security-sensitive script. A wrapper class or session object gives you a single place to enforce:
- verify=True
- Timeouts
- Retry logic with backoff
- Authentication headers
- Response validation

import requests

class SecureHTTPClient:
    def __init__(self, timeout: int = 30):
        self.session = requests.Session()
        self.session.verify = True  # Explicit, not default
        self.timeout = timeout

    def get(self, url: str) -> requests.Response:
        response = self.session.get(url, timeout=self.timeout)
        response.raise_for_status()
        return response

2. Never Trust Library Defaults for Security Properties

Python's requests defaults to verify=True, but this is a convenience default, not a security guarantee. Always be explicit:

# ❌ Risky — relies on default
requests.get("https://api.example.com/data")

# ✅ Explicit — survives environment changes
requests.get("https://api.example.com/data", verify=True, timeout=30)

3. Pin Certificate Bundles in Build Environments

For build tools that fetch cryptographic checksums, consider pinning the CA bundle:

requests.get(url, verify="/path/to/pinned/ca-bundle.crt", timeout=30)

This prevents environment-level CA bundle substitution attacks.

4. Validate Checksums Independently

When fetching SHA-256 checksums from the same server as the artifact, consider verifying the checksum file's own signature if available (e.g., GPG-signed release files from OpenSSL).

5. Use Static Analysis Tools

• Bandit: Detects requests calls with verify=False (B501, B502)
• Semgrep: Can be configured to flag requests.get() without explicit verify=True
• Safety / pip-audit: Detects vulnerable versions of the requests library itself

Relevant Standards

• CWE-295: Improper Certificate Validation
• OWASP A02:2021: Cryptographic Failures
• OWASP Transport Layer Security Cheat Sheet: Recommends explicit certificate validation in all TLS connections

Key Takeaways

• The SHA-256 checksum fetch at line 568 had no raise_for_status() call, meaning a tampered or errored response would have been silently parsed — a critical gap in a supply chain integrity check.
• Relying on requests library defaults for verify=True is insufficient in build tool contexts where environment variables like REQUESTS_CA_BUNDLE can silently override verification behavior.
• The Requests wrapper class introduced in this fix creates a single auditable location for all HTTP security controls — any future developer adding a network call to add_cpython.py gets these protections automatically.
• Both the GitHub API call and the OpenSSL asset download were unprotected — an attacker only needed to intercept one to inject malicious build data into the CPython pipeline.
• Supply chain scripts are high-value MITM targets: tools that fetch release metadata and checksums deserve stricter HTTP hardening than general application code.

How Orbis AppSec Detected This

• Source: Outbound HTTP request to https://api.github.com/repos/openssl/openssl/releases and a derived shasum_url asset endpoint in get_store_latest_release()
• Sink: requests.get(url, timeout=30) at line 542 and requests.get(shasum_url, timeout=30).text at line 568 in plugins/python-build/scripts/add_cpython.py
• Missing control: No explicit verify=True parameter; no raise_for_status() on the SHA-256 checksum fetch; no centralized HTTP security policy
• CWE: CWE-295 — Improper Certificate Validation
• Fix: Introduced a Requests wrapper class that enforces timeout=30 and raise_for_status() for all HTTP calls, with a single location to add verify=True explicitly

Orbis AppSec automatically detected this vulnerability and opened a pull request with the fix. Try Orbis AppSec on your repositories to find and fix issues like this automatically.

Conclusion

The vulnerability in add_cpython.py is a textbook example of how implicit security defaults create hidden risk in build tooling. The two requests.get() calls that fetched OpenSSL release metadata and SHA-256 checksums were not obviously broken — they worked correctly under normal conditions. But in an adversarial environment, the absence of explicit certificate verification enforcement and consistent HTTP error handling created a real supply chain attack vector.

The fix is elegant precisely because it doesn't just patch the two affected lines: it introduces a Requests wrapper class that makes secure HTTP behavior the default for all future code in this file. This is the right way to remediate this class of vulnerability — not line-by-line patches, but architectural controls that prevent the same mistake from recurring.

For developers working on build scripts, release automation, or any tool that fetches cryptographic artifacts from external sources: treat every HTTP call as a potential attack surface. Centralize your HTTP client configuration, be explicit about verify=True, and always call raise_for_status() before trusting a response.

References

• CWE-295: Improper Certificate Validation
• OWASP Transport Layer Security Cheat Sheet
• Python requests library — SSL Cert Verification
• Semgrep rules for requests without verify
• fix: the scripts use requests in add_cpython.py