密码学基础：HTTPS 背后的数学原理

去年面试一个后端岗位，面试官问我：”HTTPS 为什么安全？”

我说：”因为加密了。”

“怎么加密的？”

“呃……用证书？”

面试官笑了笑，换了个话题。我知道，我暴露了。

后来花了一周时间恶补密码学基础。发现这东西没有想象中那么难，只是教材写得像天书。

安全不是黑魔法

很多人以为密码学是数学天才的专利。其实不是。

现代密码学的核心原理，初中数学就能理解。难点在于工程实现——如何把理论变成可靠的代码。

作为开发者，你不需要能自己设计加密算法（那是密码学家的工作），但你需要理解现有方案的原理和局限。

否则就会出现这种问题：

info

对称加密：一把钥匙

对称加密是最直观的方案：加密解密用同一把密钥。

AES（高级加密标准）是目前最常用的对称加密算法。256 位密钥理论上需要 2^256 次尝试才能破解——这个数字比宇宙中的原子还多。

但对称加密有个致命问题：密钥怎么传递？

如果 Alice 要给 Bob 发加密消息，她需要先把密钥告诉 Bob。但如果传输渠道不安全，密钥被截获了，加密就没有意义。

这就引出了非对称加密。

非对称加密：钥匙对

非对称加密有两把密钥：公钥和私钥。

公钥可以公开，用来加密
私钥必须保密，用来解密

RSA 是最著名的非对称加密算法。基于一个简单的数学事实：大质数的乘法很容易，但质因数分解很难。

比如：

选两个大质数 p 和 q，计算 n = p × q（很简单）
知道 n，要找出 p 和 q（极其困难）

这个”单向函数”的特性，构成了 RSA 的安全基础。

但非对称加密计算量太大，不适合加密大量数据。实际使用中，通常用非对称加密传输对称密钥，再用对称加密传输实际数据。

这就是 HTTPS 的基本思路。

HTTPS 握手：建立信任

当你在浏览器输入 https://example.com，发生了什么？

1. Client Hello

2. Server Hello

3. 密钥交换

4. Finished

浏览器发送支持的 TLS 版本、加密套件列表、随机数。

服务器选择加密套件，发送证书和公钥，以及另一个随机数。

浏览器验证证书，生成预主密钥，用服务器公钥加密后发送。

双方基于随机数和预主密钥计算会话密钥，后续通信用这个对称密钥加密。

关键点在于证书验证。

服务器证书由 CA（证书颁发机构）签名。浏览器内置了可信 CA 的公钥，可以验证证书的合法性。

如果证书是自签名的，或者由未知 CA 签发，浏览器会警告用户。

证书链和信任

为什么需要 CA？

想象一个场景：你第一次访问某个网站，怎么确定它就是你想要的那个？

公钥本身不能证明身份。任何人都可以声称自己是 example.com。

CA 的作用是身份背书。它验证域名所有者的身份，然后用自己的私钥签名证书。

浏览器信任 CA，所以信任 CA 签名的证书，所以信任证书中的公钥属于该域名。

这就是信任链：

浏览器 → 信任 CA → 信任证书 → 信任公钥 → 建立加密连接

中间人攻击如何防范

如果没有证书验证，攻击者可以拦截连接，伪装成服务器。这就是中间人攻击。证书验证确保你连接的是真正的服务器，而不是攻击者的代理。

实战：生成自签名证书

理解了原理，来动手试试。

用 OpenSSL 生成一个自签名证书：

# 生成私钥
openssl genrsa -out server.key 2048

# 生成证书签名请求
openssl req -new -key server.key -out server.csr \
  -subj "/C=CN/ST=Beijing/L=Beijing/O=MyOrg/CN=localhost"

# 生成自签名证书
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

现在你有两个文件：

server.key：私钥，必须保密
server.crt：证书，可以公开

在 Nginx 中配置 HTTPS：

server {
    listen 443 ssl;
    server_name localhost;
    
    ssl_certificate /path/to/server.crt;
    ssl_certificate_key /path/to/server.key;
    
    # 启用现代 TLS 配置
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
}

自签名证书只适合开发和测试。生产环境应该使用 Let’s Encrypt 等免费证书，或购买商业证书。

安全不是终点

理解了 HTTPS 的原理，你会发现它解决的是”传输安全”——数据在传输过程中不被窃听和篡改。

但安全问题远不止于此：

服务端漏洞（SQL 注入、XSS、CSRF）
密钥管理（如何安全地存储和轮换密钥）
证书过期（忘记续期导致服务中断）
重放攻击（截获合法请求重复发送）

HTTPS 只是安全链条的一环。真正的安全需要全方位的考虑。

但至少现在，当有人问你”HTTPS 为什么安全”，你可以说：

“它用非对称加密建立安全通道，用证书验证身份，然后用对称加密高效传输数据。整个流程基于数学难题，暴力破解不可行。”

然后反问一句：

“你的证书自动续期了吗？”

这才是工程师的思维。