企业官网建设流程全解析

Requests库的verify=False不安全？深入聊聊Python中HTTPS证书验证的‘正确’关闭姿势

当你在Python中使用Requests库发起HTTPS请求时，如果遇到自签名证书或内部测试环境的服务，可能会不假思索地加上verify=False参数来跳过证书验证。这个看似简单的解决方案背后，隐藏着哪些安全风险？作为开发者，我们是否有更优雅的应对方式？

1. 为什么verify=False会引发安全警告

每次使用verify=False时，你都会看到这样的警告：

InsecureRequestWarning: Unverified HTTPS request is being made to host

这个警告不是Requests库的多此一举，而是底层urllib3库发出的重要安全提醒。HTTPS的核心安全机制就是证书验证，它确保你连接的是真实的服务器，而非中间人攻击的伪装者。

证书验证的三个关键作用：

1. 身份认证：确认服务器确实是它声称的那个实体
2. 数据加密：建立安全的通信通道
3. 完整性保护：防止传输数据被篡改

当你设置verify=False时，相当于关闭了第一道安全防线。虽然数据仍然是加密传输的，但你无法确认通信对方的真实身份。这就好比收到一封加密邮件，但你完全不知道发件人是谁。

2. 禁用验证的三种方式及其风险等级

不是所有绕过证书验证的方法都同样危险。让我们比较几种常见做法：

最危险的做法是同时使用这两种代码：

requests.packages.urllib3.disable_warnings() response = requests.get(url, verify=False)

这相当于不仅关闭了警报系统，还拆掉了大门锁。攻击者可以轻松实施中间人攻击，而你完全不会收到任何警告。

3. 更安全的替代方案

3.1 为内部服务配置专用CA证书

对于企业内网或开发环境，最佳实践是创建自己的CA证书，并配置客户端信任该CA：

import requests # 指定自定义CA证书路径 response = requests.get( 'https://internal-api.example.com', verify='/path/to/company-ca-cert.pem' )

操作步骤：

1. 生成自签名CA证书
2. 用该CA签发服务器证书
3. 将CA证书分发给所有客户端
4. 在代码中指定CA证书路径

3.2 使用SSLContext进行精细控制

对于需要更复杂控制的情况，可以直接配置SSLContext：

import ssl import requests from urllib3.util.ssl_ import create_urllib3_context # 创建自定义SSL上下文 ctx = create_urllib3_context() ctx.load_verify_locations(cafile='/path/to/certs.pem') # 仅禁用特定类型的证书验证 ctx.verify_mode = ssl.CERT_OPTIONAL response = requests.get( 'https://api.example.com', verify=ctx )

这种方法允许你：

• 混合使用系统证书和自定义证书
• 控制验证深度
• 设置特定的协议版本

4. 临时测试的安全实践

如果必须在测试环境临时禁用验证，至少应该：

1. 限制只在测试代码中使用
2. 添加明显的注释说明
3. 确保不会意外提交到生产代码

# 测试环境专用 - 生产环境必须移除！ # 仅用于访问开发环境的自签名证书 response = requests.get( 'https://dev-api.example.com', verify=False # 安全风险：仅在测试环境使用 )

更好的做法是使用环境变量控制：

import os import requests VERIFY_SSL = os.getenv('VERIFY_SSL', 'True').lower() == 'true' response = requests.get( 'https://api.example.com', verify=VERIFY_SSL )

这样可以通过环境变量VERIFY_SSL=False在测试时禁用验证，而生产环境默认保持安全。

5. 常见陷阱与最佳实践

陷阱1：全局禁用警告

# 不推荐 - 隐藏所有安全警告 import urllib3 urllib3.disable_warnings()

陷阱2：错误的自定义证书路径

# 文件路径错误会导致静默失败 requests.get(url, verify='wrong/path/cert.pem')

最佳实践清单：

• 生产环境始终启用证书验证
• 为内部服务建立专用CA体系
• 测试代码明确标记临时解决方案
• 监控日志中的安全警告
• 定期更新CA证书包

在最近的一个项目中，我们遇到旧系统使用的SHA-1签名证书被现代浏览器拒绝的情况。通过分析发现，正确的解决方案不是禁用验证，而是升级服务器证书。这提醒我们：verify=False应该是最后手段，而非首选方案。