JackHttp -- HTTPS 为什么是安全的?

如果你还不清楚 JackHttp 是什么，请戳这里！！！

---

阅读本文你将弄明白如下内容：

• HTTP 为什么是不安全的
• 什么是 HTTPS?
• SSL/TLS 在网络分层中所处的位置
• HTTPS 与 HTTP & SSL/TLS 之间的关系
• HTTPS 为什么是安全的
• HTTPS 连接流程
• 分析 HTTPS 真的一定安全吗？

文章前部分理论居多，但很重要。
ok,我们今天依旧带着问题开始今天的内容。

什么是 HTTP？

HTTP 定义的是一个客户端和服务器端通信的规范和标准。

如果你想具体了解什么是 HTTP ，可以阅读JackHttp – 从原理来理解 HTTP

HTTP 为什么不安全？

要弄清楚 HTTPS 为什么是安全的之前，首先我们得清楚 HTTP 为什么是不安全的,主要是2个原因。

1. HTTP 的传输是明文的。
2. HTTP 的传输过程中发生窃听或篡改。

再我们网络传输过程中， 为了遵守 HTTP, 我们的每一个请求都会被转换成报文，然后再进行传输，而我们的报文数据不是说能"嗖"的一下直接传输到对方服务器，中间会经过 中间代理服务器、路由器、wifi热点、通信服务运营商等 多个物理节点，这些节点会依次按顺序接收数据，并原封不动的传输到下一节点。

而由于 HTTP 是明文的，这些节点能清楚的看到我们每一个报文所发的原始数据（POST 请求时 Body 内容虽然不会被显示出来，但使用抓包工具也能获取到）。如果中间节点有坏人的话，他可以把我们的报文数据修改后，在传给下一节点。这样服务器在接收到数据的时候，就会拿到一个被篡改后的数据。

就算再中间节点中不发生篡改，单纯的窃听也是非常危险的，中间节点可以对我们的敏感数据进行记录，导致用户的隐私被泄露。

什么是 HTTPS？

那么为了解决 HTTP 不安全两个原因，大家想到两个思路，第一个思路是修改网络框架，让数据传输时不经过中间层或者只经过可靠的中间层。这种思路确实可以解决问题，但显然工作量太大，网络框架发展至今，要推翻重来不是闹着玩的。

于是就衍生出了第二种思路，既然 HTTP 是明文传输的，那么对 HTTP 传输的内容进行加密不就行了吗？这样中间节点就算看到数据，也没用啊，他看不懂，并且因为他看不懂，他也没办法篡改数据，监听的数据也将没有意义，这样不就完全规避了 HTTP 的弊端，达到安全了吗？

那么为什么还要引入 HTTPS 呢，要知道任何一个新的技术都需要经过 初版 -> 大众接收 -> 大众使用 -> 迭代 -> 推广 -> 迭代 -> 迭代 -> … -> 稳定 这样一个过程，会伴随着漫长的更换周期与兼容性遗留问题。能用当前技术解决问题的情况下，尽量不要选用新技术，来维持软件的稳定性。

其实 HTTPS 并不是什么新技术，也不是什么新的协议，他就是这么干的，再 HTTP 报文数据传递给 TCP 之前，也就是 HTTP 之下 TCP 之上的一个协议层增加了一个 安全层来对数据进行加密，同时会对服务器身份进行验证。

结论：由于 SSL 是基于 HTTP 之下 TCP 之上的一个协议层，是基于 HTTP 标准并对 TCP 传输数据时进行加密的，所以把数据从 HTTP 层经过 SSL/TLS 加密后再送达 TCP 之前的整个过程称之为 HTTPS 。既 HTTPS 是 HTTP+ SSL/TLS 的简称。

拓展：HTTPS 在数据送达 TCP 之前，会在安全层中进行 SSL/TLS 安全连接，其中连接过程会对服务器身份进行认证。也就是说要搞明白 HTTPS 为什么是安全的，我们必须得弄明白如下两个问题：
1、 SSL/TLS 是什么？
2、SSL/TLS 安全连接阶段是如何对数据进行加密以及身份验证的。**

什么是 SSL/TLS?

通过 HTTPS 的介绍我们清楚了 SSL 是基于 HTTP 之下 TCP之上的一个协议层，是基于 HTTP 标准并对 TCP 传输数据时进行加密的。那么什么是 SSL，什么又是 TLS 呢？

SSL (Secure Socket Layer ) 安全套接层

是 基于 HTTPS 下的一个协议加密层 ，最初是由网景公司（Netscape）研发，后被IETF（The Internet Engineering Task Force - 互联网工程任务组）标准化后写入 RFC（RFCRequest For Comments ），RFC 是互联网技术的规范！了解 RFC

TLS (Transport Layer Security) 安全传输层

由于 HTTPS 的推出受到了很多人的欢迎，在 SSL 更新到 3.0 时，IETF 组织对 SSL 3.0 进行了标准化，标准化后 IETF 对 SSL 进行更名为 TLS(Transport Layer Security)安全传输层协议并正式发布 TLS 1.0 版本，可以说 TLS 就是 SSL 的 3.1 版本或者说是 4.0 版本。

并同时发布 “RFC2246-TLS加密协议详解”，如果想更深入的了解 TLS 可以戳这里，传送门 ,在搜索栏搜索“RFC2246”下载 RFC 文档查看。

总结成网上的一张图，引用自百度：

HTTPS 安全连接流程（重点）

弄清楚 HTTPS 与 HTTP & SSL/TLS 之间的关系之后且我们清楚了 SSL/TLS 安全层目的是对数据进行加密同时对服务器身份进行验证的，以此来达到数据传输安全。因此我们要了解 HTTPS 为什么是安全的，既需要弄明白 SSL/TLS 是怎么对数据进行加密和身份验证的。

由于 SSL/TLS 连接流程比较复杂，为了加深大家的印象，我会使用抓包工具对整个连接流程进行 抓包验证并且尽量多的用图片代替文字 来方便我们理解。

跟介绍 HTTP 时一样，我们同样的对我的播客主页 "https://blog.csdn.net/zhanggang740"进行访问。

当我在游览器中输入"https://blog.csdn.net/zhanggang740" 并按下回车后， SSL/TLS 连接到来时。

1. Client Hello

握手第一步是客户端向服务端发送 Client Hello 消息，这个消息里包含了一个客户端生成的随机数 Random1、客户端支持的加密套件（Support Cipher Suite）和 SSL Version 等信息。

抓包后的数据如下：

从抓包数据中可以很明显的看到，客户端和 CSDN 服务器建立的 TLS 连接版本是 1.2 ，发送的 Random 值以及支持的加密套件（加密套件包含对称加密算法，非对称加密算法以及Hash算法）。

2. Server Hello

第二步是服务端向客户端发送 Server Hello 消息，这个消息会从 Client Hello 传过来的加密套件里确定一份加密套件，这个套件决定了后续加密和生成摘要时具体使用哪些算法，另外还会生成一份随机数 Random2。

注意，至此客户端和服务端都拥有了两个随机数（Random1+ Random2），这两个随机数会在后续生成对称秘钥时用到。

这一步结束后，首次握手就结束了，客户端和服务端会存着如黄色部分数据：

3. Certificate

这一步是服务端将自己的证书下发给客户端，让客户端验证自己的身份。具体包含服务端的网站证书，网站签发机构证书以及证书机构的签发根证书。

解释：发送的服务端的网站证书，网站签发机构证书以及证书机构的签发根证书分别包含如下具体信息：证书公钥信息、证书签名、证书签名算法、证书基本信息（主机、证书域名、注册名称、注册地址）等。

红色部分就是我刚才说的证书中所包含的信息。绿色部分是什么呢？在我们游览器状态栏的左边有一个