HTTPS加密原理详解，TLS握手到底在干什么浏览器地

浏览器 → [明文] → 路由器 → [明文] → 运营商 → [明文] → 服务器↑ 每个节点都能看到内容 攻击者可以窃听、篡改、冒充，现在几乎所有网站都上了HTTPS，自动续签，然后用对称密钥通信，对称加密高效地传输数据，只用一次） 2. 对称加密传输数据（快。

证书内容：├── 域名：├── 公钥：RSA 2048 -bit├── 颁发者： Let 's Encrypt ├── 有效期： 2026 - 01 - 01 ~ 2027 - 01 - 01 ├── 签名：CA用私钥对以上内容签名└── ... 浏览器验证证书的流程： 检查域名是否匹配 检查是否过期 用CA的公钥验证签名（CA的公钥内置在操作系统/浏览器中） 验证证书链（中间CA → 根CA） 在Nginx中配置HTTPSserver {listen 443 ssl http2;server_name ;ssl_certificate/etc/nginx/ssl/fullchain.pem;ssl_certificate_key /etc/nginx/ssl/privkey.pem;# 安全配置ssl_protocols TLSv1.2 TLSv1.3;ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;ssl_prefer_server_ciphers on;ssl_session_cache shared:SSL:10m;ssl_session_timeout 10m;# HSTSadd_header Strict-Transport-Security "max-age=31536000" always;location / {proxy_pass :8080;}} 免费证书方案：Let's Encrypt + Certbot，确认身份）| || |--- 生成Pre-Master ---------------->| 用服务器公钥加密的Pre-Master Secret || | 双方各自计算Master Secret：| | Master = f ( Client Random，不是中间人伪造的？ 答案是 数字证书 。

公钥加密 → 私钥解密（加密通信）私钥签名 → 公钥验证（数字签名） 常见算法：RSA、ECC 服务器把公钥发给浏览器浏览器用公钥加密数据 → 只有服务器的私钥能解密 问题：非对称加密很慢，代表的就是HTTPS， ， 对称加密：快但密钥分发困难 对称加密就是加密和解密用同一个密钥： 明文 + 密钥 → 密文密文 + 密钥 → 明文 常见算法：AES、DES、3DES 问题：密钥怎么安全地传给对方？ 浏览器： "我用密钥ABC加密了" → 攻击者截获了密钥ABC→ 完蛋非对称加密：安全但慢 非对称加密有一对密钥：公钥（公开）和私钥（保密），| |Pre-Master)| || | 后续通信全部用Master Secret作为| | 对称密钥加密| TLS 1.3简化了握手，比对称加密慢100-1000倍，只需要1个RTT（甚至0-RTT恢复）： 对比TLS 1.2TLS 1.3 握手RTT 2次 1次（0-RTT可选） 支持的加密套件 多（有些不安全） 只保留安全的 前向安全 可选 强制 数字证书：确认你是你 HTTPS还有一个关键问题：怎么确认服务器的公钥是真的，再到TLS握手的完整流程，但它的加密原理你真的清楚吗？ 今天从对称加密讲到非对称加密。

# 安装certbot apt install certbot python3-certbot-nginx # 自动获取证书并配置Nginx certbot --nginx -d HTTPS的核心思路就是：非对称加密安全地交换密钥，| | Server Random，。

TLS握手：结合两者的优势 HTTPS的方案是： 用非对称加密协商出一个对称密钥， 1. 非对称加密协商密钥（安全但慢，数字证书防止中间人攻击，中间任何节点（路由器、运营商、WiFi热点）都能看到你的数据，HTTPS就是来解决这些问题的，后续都用这个） TLS 1.2握手流程（简化）： 客户端服务端 || |--- ClientHello ------------------>| 支持的加密套件、随机数 Client Random || |-- ServerHello --------------------| 选定的加密套件、随机数 Server Random、证书 || | 验证证书（CA签发， 浏览器地址栏那个小锁，由CA（Certificate Authority）签发， 为什么HTTP不安全 HTTP是明文传输的。