HTTPS是什么？加密过程与安全保障详解

探讨信息安全时，最常见的加密传输方式莫过于HTTPS。当浏览器地址栏显示绿色标识，意味着该网站启用了HTTPS加密传输，你与它之间的连接确实受到了保护。但HTTPS并非单一技术，而是HTTP协议与某个加密协议（通常是TLS）的结合体。那么HTTPS究竟为什么安全呢？首先需要了解HTTP为何不安全。

想象你坐在教室里，想把一条信息传递给另一个人——典型的做法是传纸条。这个比喻非常贴近现实，这正是互联网基础协议TCP/IP的工作模式。HTTP数据正是通过TCP/IP发送的。你在纸条上写明目标同学的座位，再写上要传达的内容。途经的同学拿到纸条后，根据地址依次传递。这样，第一个问题出现了：途经的同学可以完全看到你写了什么。

这就是HTTP面临的第一个问题，通常称为“窃听”或“嗅探”——同一网络或路由上的攻击者能够窥探到传输的内容。这是HTTPS需要解决的首要问题，通常通过“加密”来应对。从最原始的角度看，就是双方约定一个暗号，比如用某个字母替换另一个字母。但互联网每天有海量信息需要加密，这种原始方法显然不适用。实际方案一般采用一种名为AES的算法。AES需要一个密钥key来加密和解密整个信息，加密和解密使用同一个key，因此也称为“对称加密”。AES在数学上保证了：只要使用的key足够长，破解几乎是不可能的。

先假设这种破解确实不可能——目前也确实没有对AES本身发动有效攻击的案例。

回到教室，你接着要传小纸条。写上地址后，把内容用AES加密起来。刚准备传，问题来了：AES的key如何传递给目的地？如果直接把密钥写在纸条上，中间的人不照样能解密？在现实中，你可以通过其他方式安全地把密钥传给对方，但在互联网上不行——传输终究要经过这些路由。要实现加密，必须采用更复杂的数学方法。

于是聪明的人们发明了一种更复杂的加密算法——非对称加密。这种加密可以生成一对密钥(k1, k2)。k1加密的数据只能由k2解密，k2加密的数据只能由k1解密。常用的是RSA算法，其原理是两个大素数的乘积很容易计算，但从乘积反向分解出两个素数却极其困难。只要这个数足够大（通常使用2的10次方个二进制位，即1024位以上），即便超级计算机也需要极长的时间才能破解。

利用非对称加密，设想一个场景：你继续传纸条，但首先要将接下来通讯的对称加密密钥传输过去。你用RSA生成一对k1、k2，把k1明文发送出去。沿途的人即使截取到也没用——k1加密的数据需要k2才能解密，而k2在你手里。k1到达目的地后，对方准备一个用于对称加密的key，用k1把key加密后传回来。路上的人即使截取到也解密不出key。等你收到后，用k2解密得到key。现在全班只有你和你的目的地拥有这个key，接下来你们就可以用AES进行对称加密传输了！此时，通讯再也无法被任何人窃听。

当然，你可能会问两个问题。

既然非对称加密这么安全，为什么不直接用非对称加密来加密信息，而是只用来加密对称密钥呢？

因为非对称加密的密钥生成和加解密过程比较耗时，为了节省双方的计算开销，通常只用它来交换密钥，而不是直接传输大量数据。

使用非对称加密完全安全吗？

听起来挺安全，但有一种更恶劣的攻击无法用这种方法防范——传说中的“中间人攻击”。继续回到教室传纸条。你和目的地的中间有一个中间人，他有意要知道你们的消息。把你们称为A和B，中间人称为M。当A要和B完成第一次密钥交换时，途径了M。M扣下纸条，假装自己是B，伪造了一个key，用A发来的k1加密后发还。A以为和B完成了密钥交换，实际上和M完成了交换。同时M和B完成一次密钥交换，让B误以为和A交换了。结果A→B的加密链路变成了A（加密连接1）→M（明文）→B（加密连接2）。M依然可以知道A和B传输的全部信息。

对于这种情况，似乎很难找到解决方法，除非能从源头保证密钥交换的对象是安全的。这时需要认识到互联网HTTPS和传纸条的微妙区别：传纸条时，你和目的地的关系几乎对等；而访问网站时，你访问的对象通常是一个大型服务供应商，他们有能力证明自己的合法性。

于是引入一个第三方叫做CA。CA是一些权威的组织，专门认证网站合法性。服务商可以向CA申请证书，建立安全连接时带上CA的签名。CA的安全性由操作系统或浏览器认证。Windows、Mac、Linux、Chrome、Safari等在安装时带有一份信任的CA证书列表。如果和你建立安全连接的人带着这些受信任CA的签名，就认为这个连接是安全的，没有遭到中间人攻击。

CA证书通常情况下是安全的。一旦某个CA颁发的证书被用于非法用途，浏览器和操作系统会通过更新将该CA颁发的全部证书视作不安全。这使得CA在颁发证书时通常比较谨慎。

所以，对称加密+非对称加密+CA认证这三个技术混合在一起，才使HTTP后面加上了S——Security。实际上HTTPS的协议比这里描述的更复杂，这里主要说明了基本的实现原理。因为其中任何一环稍有闪失，就会使整个加密变得不安全。这也是HTTPS协议从SSL1.0升级到SSL3.0，再到TLS1.0，现在被TLS1.2取代的原因——背后都是细节上的修改，以防任何地方出现漏洞。

即使如此，HTTPS尽可能保证了传输的安全，但这种安全也不是绝对的。例如，如果CA证书出了问题被用于中间人攻击，那么短期内你的安全会陷入麻烦，直到浏览器或操作系统更新CA列表，或者你手动调整该列表。不过大多数情况下不必杞人忧天——它基本上是安全的。

当然，路由也可以选择直接丢包——它看不到的，也不让你看到。