从 HTTP 到 HTTPS - 什么是 HTTPS

这篇文章首发于个人我的网站：据说 - https://tasaid.com/，建议在个人我的网站阅读，拥有更好的阅读体验。

这篇文章与 博客园 和 Segmentfault 共享。

前端开发QQ群：377786580

HTTPS是互联网 web 大势所趋。各大网站都已陆续部署了HTTPS，这篇文章咱们来探讨什么是HTTPS以及为何要部署HTTPS。

这篇文章收录在《Said - 从HTTP到HTTPS》系列：

• 从 HTTP 到 HTTPS - 什么是 HTTPS

• 从 HTTP 到 HTTPS - IIS如何部署 HTTPS

• 从 HTTP 到 HTTPS - 网站部署 HTTPS 中须要作的事情

HTTP

当你在浏览器输入一个网址 (例如 http://tasaid.com)的时候，浏览器发起一个 HTTP 请求，带着请求信息 (参见 HTTP Headers)，链接到服务器，把请求信息递给服务器，服务器收到信息以后，解析相关的信息，而后进行处理，再返回浏览器请求的数据。

简单来讲是这么一个流程：

1. 小明 跟 浏览器爸爸 说我想要去中关村某个店家拿一些东西 (发起请求)

2. 浏览器爸爸 就把 小明 要的东西记在一张清单上 (生成HTTP协议)

3. 而后 浏览器爸爸 派出一个 线程小弟，噌噌噌跑到中关村的店里，把清单递给 店家，说小明要这些东西 (进行传输)

4. 店家 让 线程小弟 稍等，而后去屋子里面拿小明的这些东西 (服务器收到请求)

5. 店家 把东西拿出来后，而且也打印了一份清单，让 线程小弟 带着清单和东西一块儿拿回去 (服务器处理请求完毕)

6. 而后 线程小弟 回到 浏览器爸爸 那边，把服务器给的清单和物品交给浏览器爸爸，浏览器爸爸根据清单核对物品 (浏览器处理响应)

7. 而后把物品打包交给了 小明 (浏览器渲染并呈现界面)

看图说话：

这其中有个问题，浏览器爸爸和服务器都没有验证清单信息的有效性和对方的身份。万一有人在中间把线程小哥拦下来，暴揍一顿，而后把物品清单给换了怎么办？或者有人把线程小哥在半路上暴揍一顿，拿了清单换了另一个小哥怎么办？

这是个很严肃的问题：假如服务器要把一些东西锁在柜子里，须要小明给密码才能够打开柜子。而后小明把密码写在清单上让浏览器爸爸交给服务器。这时候，若是这张清单被人拦截下来，不就获得了小明的密码？

简单来讲，传输的信息中包含用户密码，被拦截了怎么办？

HTTPS

正由于HTTP请求有这些安全性的问题，因此HTTPS诞生了，致力于解决了这些安全性问题，咱们进行一下对比：

安全性	HTTP	HTTPS
窃听风险	传递的信息是明文的，可能会被有心人拦截下来窃听	信息加密传播
篡改风险	传递的信息可能会被篡改	信息校验，一旦被篡改马上就会被发现
假装风险	没有验证通讯另一头对方的身份，可能遭遇假装	身份校验

那么HTTPS是如何作到更安全的呢？

简单来讲，HTTPS 便是在 HTTP 下加入了一层 SSL 加密，因此被称为HTTPS。具体的加密过程则是 公匙加密法：

• 客户端向服务器索要公匙，而后使用公匙加密信息

• 服务器收到加密后的信息，用本身的私匙解密

公匙密码和算法都是公开的，而私匙则是保密的。加密使用的公匙和解码使用的密匙都是不相同的，所以这是一个 非对称加密 算法。

数字证书

说起 HTTPS ，就会听到你们说须要证书才能部署，那么什么是证书呢？

由于互联网不安全，公匙也是信息的一部分，也是会有被篡改的风险的。因此引入了互联网权威机构 - CA 机构，又称为证书受权 (Certificate Authority) 机构，浏览器会内置这些"受信任的根证书颁发机构" (即 CA)。

服务端向权威的身份鉴定 CA 机构申请数字证书，CA 机构验证了网站以后，会把网站录入到内部列表，采用 Hash 把服务端的一些相关信息生成摘要，而后 CA 机构用本身的私匙，把服务端的公匙和相关信息一块儿加密，而后给申请证书的服务端颁发数字证书，用于其余客户端 (好比浏览器) 认证这个网站的公匙。

客户端经过服务端下发的证书，找到对应的 CA，而后向 CA 验证这个证书是否有效，CA 验证经过以后，下发服务端的公匙。

由于 CA 是权威而且可信的，因此客户端 (浏览器) 信任 CA，而 CA 又信任通过认证的服务端 ，因此客户端 (浏览器) 也信任这个服务端，这就是信任链 (Chain Of Trust)。

而 CA 颁发的数字证书，通常包含这些信息：

简单来讲：为了保证公匙是安全的，因此经过数字证书验证公匙。

加密通讯

一条完整的HTTPS请求应该是这样的：

1. 客户端 (浏览器) 发起 HTTP 请求，请求链接服务端，发送支持的加密通讯协议 (和版本)，而且生成一个随机数，后续用于生成"对话密钥"。

2. 服务端确认加密通讯协议 (和版本)，同时也生成一个随机数，后续用于生成"对话密匙"，而且将 CA 颁发的数字证书，一块儿发送给客户端。

3. 客户端收到数字证书后，检测内置的"受信任的根证书颁发机构"，查看解开数字证书的公匙是否在。

4. 若是解开数字证书的公匙存在，则使用它解开数字证书，获得正确的服务器公匙，同时再次生成一个随机数，用于服务器公匙加密，并发送给服务器。

5. 此时本地和服务器同时将三个随机数，根据约定的加密方法进行加密，各自生成本次会话的所使用的同一把 "会话密匙" 。

6. 到这里，认证阶段已经完毕，数据传输从 非对称加密 换成了 对称加密 (由于考虑到性能)，接下来全部的数据传输都是使用HTTP协议进行传输，只不过使用了 "会话密匙" 来加密内容。

见下图：

参考和引用

• HTTPS 工做原理

• 阮一峰 - 数字签名是什么

• 阮一峰 - SSL/TLS协议运行机制的概述

这篇文章首发于个人我的网站：据说 - https://tasaid.com/，建议在个人我的网站阅读，拥有更好的阅读体验。

这篇文章与 博客园 和 Segmentfault 共享。

前端开发QQ群：377786580