聊聊浏览器里的那把锁：HTTPS 如何让你安全冲浪？( 三 ) 多年以前

整理一下。结合前面的「问候」过程，现在你和少数派双方手上拥有：
一个双方都认可的加密算法 TLS_RSA_WITH_AES_256_GCM_SHA384 ，邮差可以偷看
一个少数派生成的随机数 785391 ，邮差可以偷看
一个你生成的随机数 11872 ，邮差可以偷看
另一个你生成的随机数 36721 ，只有你和少数派知道
通过这些信息，你和少数派会各自使用三个随机数和算法，计算出一个称为「会话密钥」的密码。由于随机数和算法都已经确定，因此你和少数派计算出的「会话密钥」必然是一致的；假设这个计算出来的密码是 1627638 。
你们事实上完成了一件很有意思的事情：在所有聊天内容都会被人偷看的情况下，你们成功交换了密码。这使得后续的秘密聊天成为可能。交换密钥的方法也还有很多，这里仅仅展示了其中的一种。
愉快的秘密通信
好了，最后，你们可以使用前面制作的 1627638 这个密码来进行后面的聊天。
这个密码用起来就方便多了，只要双方通过一个带密码锁的小盒子来互相通信，那路上的邮差就肯定打不开。
暴力解锁？密码复杂度保证了即使用人类最顶级的计算机，也无法在有生之年把密码猜出来。（1627638 这只是个例子，实际使用当然不可能这么短小）
你把想问的问题（我的私信？）塞进了密码锁，并把密码锁的密码设为 1627638 ，锁上之后打乱密码锁。
少数派拿到了这个密码锁，通过 1627638 解开密码锁。同样的，少数派会把你的私信内容也用 1627638 锁上，寄回给你。
最后，你还是用 1627638 解锁私信内容，秘密通信顺利完成。
再来回头看看最开始 HTTP 遇到几个风险，在 HTTPS 中是如何解决的：
邮差知道了你的私信内容、姓名和密码：在 HTTPS 中，由于通信使用 1627638 这个密码锁来加密，所以路上的邮差不可能知道信件的内容
无法确定到底是不是少数派给出的答复：在 HTTPS 中，证书的信任链保证了「公钥」的可信度，而公钥和私钥的匹配认证了少数派的身份
捣蛋的邮递员修改了信件内容：在 HTTPS 中，由于使用了密码锁，邮差读不了邮件，也无法写入信件
所以通过这稍显复杂的 HTTPS 通道，我们最终解决了 HTTP 的一些风险。
HTTPS 已随处可见
现在几乎所有主流的浏览器都已经用比较强烈的视觉效果区分了 HTTP 和 HTTPS 网站，例如 Google Chrome ，访问少数派网站时，地址栏前方的标识是一把寓示着安全的小锁，点开则提示「连接是安全的」：

文章图片

文章图片
而如果访问一个使用 HTTP 的网站，则会直接显示「不安全」：

文章图片

文章图片
当访问的网站，虽然正常完成了「问候」的过程，但是从服务器取到的证书存在或多或少的问题时，浏览器会阻断你们之间的通信：

文章图片

文章图片
即使通过「高级」按钮底下的选项坚持访问，浏览器依然会时刻把「不安全」标注为醒目的红色：

文章图片

文章图片
这样激进的措施曾经饱受争议，但是浏览器这样的强制性的行为却带来了非常好的结果。时至今天，我们已经很少见到有哪个网站还只支持 HTTP 访问，也很少见到证书错误的情况。以至于当我们说起互联网的时候，我们已经很难想象，当年那样几乎完全基于 HTTP 的通信是多么不可靠、不安全。