HTTPS加密过程详细分享

浏览器地址栏的小锁图标，什么时候亮绿，什么时候打红叉？大部分时候我们扫一眼就过了，直到某天自己搭的网站被浏览器标成“不安全”，才意识到这事儿没那么简单。

其实那个小锁背后，藏着一整套精密的加密流程。今天咱们就聊聊，当你敲下https://那一刻，浏览器和服务器之间到底发生了什么。

先说个基本概念：HTTPS不是新协议，它就是HTTP外面套了一层SSL/TLS。好比你在街上喊话谁都能听见，但要是钻进一间加密的玻璃房，外面的人就只能看见嘴动，听不见内容。这间玻璃房就是TLS协议干的事。

那这间房是怎么建起来的？核心思路挺聪明：用两种加密方式打配合。

一种叫对称加密，加密解密用同一把钥匙。优点是快，缺点是钥匙怎么安全地交给对方？要是钥匙在路上被抄了，后面全白搭。

另一种叫非对称加密，有两把钥匙，公钥加密、私钥解密。公钥可以随便发，谁拿到都能加密数据，但只有拿着私钥的人才能解开。安全是安全了，问题是慢，加密几段文字还行，要是加密整个网页，服务器得累死。

HTTPS的解法是：先用非对称加密安全地传递一把临时钥匙，然后用这把临时钥匙走对称加密，高效地传输数据。这就好比你先用保险箱（非对称加密）把家门钥匙（对称密钥）运过去，之后就用这把家门钥匙正常进出，又快又稳。

但这里有个致命问题：你怎么确定你拿到的公钥是真的？

这就是数字证书登场的时刻。服务器得向证书颁发机构CA申请一张证书，里面装着服务器的公钥、域名、有效期，还有CA的签名。浏览器内置了一堆受信任的CA根证书，收到服务器证书后，会用根证书的公钥去验证签名——就像验钞机照一照，看看是不是真钱。

这套信任链是怎么串起来的？假设你在浏览器里输入某银行网址，服务器返回一张证书，上面写着“本证书由GlobalSign中间CA签发”。浏览器顺着往上查，发现GlobalSign中间CA的证书又是由某个根CA签发的，而这个根CA正好在浏览器的信任列表里。层层追溯，直到信任锚点，这条链才算走通。

如果中间任何一环出了问题——证书过期了、域名对不上、签发机构不被信任——浏览器就会弹个大红警告，问你“真的要继续吗？”

流程捋顺了，咱们从头到尾走一遍。

第一步叫Client Hello。你访问一个HTTPS网站，浏览器向服务器打招呼，带上自己支持的TLS版本、加密算法列表，还有一个客户端随机数。

第二步叫Server Hello。服务器挑一个双方都支持的加密算法，回传自己的数字证书，还有一个服务器随机数。

第三步是证书验证。浏览器拿到证书，先看有效期、再看域名匹不匹配、然后用内置的CA公钥解签名，确认证书没被篡改。验证通过后，浏览器生成第三个随机数，叫预主密钥，用服务器公钥加密后发过去。

第四步，服务器用自己的私钥解密得到预主密钥。现在双方都有了三个随机数，各自用同样的算法算出一个主密钥，后续通信就用这个主密钥做对称加密。整个过程叫TLS握手，通常在一秒内完成。

还有个细节值得提。早期很多HTTPS用的是RSA密钥交换，客户端直接拿服务器公钥加密预主密钥发过去。这种方式有个隐患：要是哪天服务器的私钥泄露了，之前所有加密过的通信记录都能被解密。

所以后来流行起ECDHE这种算法，双方各自生成临时密钥对，交换参数后各自算出相同的预主密钥，整个过程私钥不参与加密，只用来签名认证。哪怕以后私钥泄露，以前的通信记录依然安全，这就是所谓的“前向保密”。

说到这你可能想问：既然HTTPS这么安全，为什么不全站都用？

两个原因。一是慢，加解密要消耗CPU，握手过程要多几次网络往返，比起纯HTTP可能慢上两三倍。二是麻烦，得买证书、配证书、还得记得续期。但这点代价换来的是用户数据不被窃听篡改，对涉及登录、支付、隐私的场景来说，这笔账算得过来。

最后说句实在话：那个小锁图标看着不起眼，其实是整个互联网信任体系的缩影。下次再看到它亮绿，你可以知道，浏览器和服务器刚刚完成了一场复杂的加密握手——虽然你什么都没感觉到，但安全已经在背后发生了。