Skip to main content

How to Disable SSL Verification in Reqwest with Rust

· 8 min read
Oleg Kulyk

How to Disable SSL Verification in Reqwest with Rust

By default, Reqwest includes TLS support through the native-tls crate, which relies on system-native implementations such as OpenSSL on Linux, Secure Transport on macOS, and SChannel on Windows (Reqwest TLS Documentation).

While this default behavior ensures secure HTTPS communication, it can introduce unwanted complexity and dependencies, particularly in constrained environments or when cross-compiling applications for platforms like AWS Lambda.

Fortunately, Reqwest provides mechanisms to explicitly disable these default TLS features, allowing developers to tailor their builds precisely to their project's requirements.

This comprehensive guide explores the various methods to disable SSL/TLS in Reqwest, including explicit feature flag management, alternative TLS backends such as rustls, and handling scenarios involving invalid or self-signed certificates. Additionally, we will discuss common pitfalls developers may encounter and provide best practices to ensure secure and efficient HTTP communication in Rust applications (Stack Overflow).

Understanding TLS Features in Reqwest​

Overview of TLS Feature Flags in Reqwest​

Reqwest provides several TLS backends, each controlled by Cargo feature flags. By default, Reqwest includes the default-tls feature, which enables TLS support using the native-tls crate. The native-tls crate relies on the system's native TLS implementation—OpenSSL on Linux, Secure Transport on macOS, and SChannel on Windows. However, Reqwest also supports alternative TLS backends, such as rustls, a pure-Rust TLS implementation, which can be enabled explicitly via the rustls-tls feature (Reqwest TLS Documentation).

The default inclusion of TLS features can lead to unwanted dependencies, particularly when developers aim for minimal builds or want to avoid external libraries like OpenSSL. To manage these dependencies effectively, developers must explicitly control the Cargo feature flags in their project's Cargo.toml.

Explicitly Disabling TLS Dependencies​

To completely disable TLS dependencies in Reqwest, it is essential to deactivate the default features provided by the crate. This is accomplished by setting default-features to false in the dependency declaration within the project's Cargo.toml file. The following snippet illustrates how to disable the default TLS features:

[dependencies]
reqwest = { version = "0.12.15", default-features = false }

This configuration explicitly instructs Cargo not to include any default features, including TLS-related ones. Consequently, this prevents the inclusion of native-tls, openssl, or other TLS libraries in the build, significantly reducing the dependency footprint (Stack Overflow).

It is important to note that disabling TLS entirely means the Reqwest client will no longer be able to perform HTTPS requests, limiting its functionality strictly to HTTP. Developers must ensure that their use case aligns with this limitation before disabling TLS.

Avoiding Unintentional Re-enabling of TLS Dependencies​

Even after explicitly disabling default TLS features, developers may encounter situations where TLS dependencies are unintentionally re-enabled. This typically occurs due to Cargo's additive feature system, where another crate in the dependency tree may request the default TLS feature from Reqwest, causing it to be reactivated. To prevent this scenario, developers must audit their dependency tree carefully and ensure no other crate explicitly or implicitly enables Reqwest's default TLS features (GitHub Issue #571).

A practical approach to verifying the absence of TLS dependencies involves inspecting the generated Cargo.lock file. If TLS-related crates such as native-tls, openssl-sys, or hyper-tls appear in the lock file after disabling default features, developers should investigate their dependency tree to identify and resolve the source of these unwanted inclusions. Tools like cargo tree can help visualize dependencies and pinpoint the responsible crates.

Using Alternative TLS Backends to Avoid OpenSSL​

While completely disabling TLS restricts Reqwest to HTTP-only requests, developers who wish to retain HTTPS capabilities without relying on OpenSSL or native system TLS implementations can opt for alternative TLS backends. The most common alternative is rustls, a pure-Rust TLS implementation that does not depend on external libraries like OpenSSL. To enable rustls instead of the default TLS backend, developers should explicitly specify the rustls-tls feature in their Cargo.toml file, ensuring default-features remains disabled:

[dependencies]
reqwest = { version = "0.12.15", default-features = false, features = ["rustls-tls"] }

This configuration allows Reqwest to perform HTTPS requests using the Rust-native rustls library, eliminating the need for external TLS dependencies. It is particularly beneficial for cross-compilation scenarios, such as compiling Rust applications for AWS Lambda or other minimal runtime environments, where external TLS libraries pose compatibility or build complexity issues (GitHub Issue #495).

Handling Invalid or Self-Signed Certificates Without Disabling TLS​

In scenarios where developers encounter issues with invalid or self-signed SSL certificates, completely disabling TLS is not always the desired solution. Instead, Reqwest provides methods to configure the client to accept invalid certificates explicitly. This approach maintains the security benefits of TLS while accommodating scenarios where certificate validation is impractical or unnecessary.

To accept invalid or self-signed certificates, developers can configure the Reqwest client builder using the danger_accept_invalid_certs method as shown below:

use reqwest::Client;

#[tokio::main]
async fn main() -> Result<(), reqwest::Error> {
    let client = Client::builder()
        .danger_accept_invalid_certs(true)
        .build()?;

    let response = client.get("https://self-signed.badssl.com/").send().await?;
    println!("Status: {}", response.status());
    Ok(())
}

This configuration explicitly instructs the client to bypass SSL certificate validation, allowing connections to servers with invalid or self-signed certificates. However, developers must exercise caution when using this option, as it significantly weakens the security guarantees provided by TLS, potentially exposing applications to man-in-the-middle attacks (Stack Overflow).

Common Pitfalls and Troubleshooting When Disabling TLS​

Disabling TLS in Reqwest can introduce several common pitfalls, primarily related to dependency management and unexpected behavior due to Cargo's additive feature system. Developers frequently encounter the following issues:

  • Unexpected TLS Dependencies: Even after explicitly disabling default features, developers may notice TLS-related crates appearing in their dependency tree. This typically arises from indirect dependencies that explicitly enable Reqwest's default TLS features. To troubleshoot, developers should use Cargo's dependency inspection tools (cargo tree) to identify and resolve these indirect dependencies (GitHub Issue #571).

  • Compilation Errors After Disabling TLS: When TLS is disabled, attempting to perform HTTPS requests results in runtime or compile-time errors. Developers must ensure that their application logic aligns with the absence of TLS, restricting requests exclusively to HTTP endpoints. If HTTPS functionality is required, developers should consider using alternative TLS backends such as rustls.

  • Cross-Compilation Issues: Disabling TLS or switching TLS backends can sometimes lead to cross-compilation challenges, especially when targeting minimal environments like AWS Lambda or embedded systems. Developers should carefully select TLS backends compatible with their target environment and verify compatibility through thorough testing (Reddit Discussion).

To mitigate these pitfalls, developers should maintain a clear understanding of their project's dependency tree, explicitly manage Cargo feature flags, and thoroughly test their applications in target environments to ensure compatibility and functionality.

Security Considerations and Best Practices When Disabling TLS​

While disabling TLS entirely can simplify dependency management and reduce binary size, it inherently eliminates the security guarantees provided by encrypted communication. Developers must carefully evaluate the security implications of disabling TLS in their applications. The following best practices can help developers make informed decisions:

  • Use TLS Whenever Possible: Unless explicitly required by the application's constraints, developers should prefer retaining TLS support, either through the default backend or alternative implementations such as rustls.

  • Explicitly Document Security Trade-offs: If disabling TLS is unavoidable, clearly document the security trade-offs and communicate these decisions to stakeholders and users, ensuring transparency and informed consent.

  • Limit Exposure: Restrict non-TLS communications to trusted networks or internal services where the risk of interception or tampering is minimal.

  • Regularly Review Dependencies: Periodically audit the project's dependency tree to ensure that TLS dependencies remain intentionally managed and that no unintended dependencies have been introduced.

By adhering to these best practices, developers can balance the practical considerations of dependency management and binary size with the critical importance of maintaining secure communications in their Rust applications.

Final Thoughts on Disabling SSL Verification in Rust​

Disabling SSL/TLS in Reqwest can significantly simplify dependency management, reduce binary sizes, and facilitate cross-compilation, making it an attractive option for developers working in constrained or specialized environments. However, it is crucial to approach this process with a clear understanding of the implications and limitations involved. Explicitly disabling TLS dependencies requires careful management of Cargo feature flags and vigilant monitoring of the dependency tree to avoid unintended reactivation of TLS features (GitHub Issue #571).

For developers who still require secure HTTPS communication without relying on external libraries like OpenSSL, alternative TLS backends such as rustls offer a viable solution. The pure-Rust implementation provided by rustls eliminates external dependencies, simplifying cross-compilation and enhancing compatibility across diverse runtime environments (Reddit Discussion). Additionally, Reqwest's built-in methods for handling invalid or self-signed certificates provide flexibility without entirely sacrificing security, though developers must exercise caution to avoid potential vulnerabilities (Stack Overflow).

Ultimately, the decision to disable SSL/TLS should be guided by careful consideration of security trade-offs, project requirements, and environmental constraints. By adhering to best practices, clearly documenting decisions, and regularly auditing dependencies, developers can effectively balance security, performance, and simplicity in their Rust-based web scraping and data extraction applications.

Additional Resources and References​

Forget about getting blocked while scraping the Web

Try out ScrapingAnt Web Scraping API with thousands of proxy servers and an entire headless Chrome cluster

Try free planContact sales

LLM-ready data extraction

Turn any website into well-structured markdown with our LLM-ready Web Scraping API

Try for free
Contact Sales