HTTPS 如何保证数据传输的安全性

为什么需要 HTTPS?

我们知道 HTTP 是一个纯文本传输协议，对传输过程中的数据包不进行加密，是明文传输，那这样的话对于介于在发送端和接收端之间的任何

一个节点都能知道传输的内容，这些节点可能是路由器、代理等。

一个比较常见的例子：用户完善个人信息。用户输入需要填写的资料，这些资料中可能包含一些个人居住地址、手机号码等一些比较隐私的数据

，如果采用的是 HTTP 协议，只需要在代理服务器上做点手脚就可以拿到用户的相关资料数据。

HTTPS 是如何保障安全的？

    HTTPS 其实是 HTTP 的升级版，被称为安全传输协议。我们知道 HTTP 是应用层协议，而在 HTTP 之下的是 TCP 传输协议，TCP 主要负责传输

数据，而 HTTP 定义了如何包装数据，也就是 HTTP 将包装好后的数据包打包给 TCP 让其帮忙进行传输。那么 HTTPS 相较于 HTTP 有哪些不一样

的地方呢？其实在 HTTP 和 TCP 之间多了一层加密层 SSL/TLS。

SSL 和 TLS 是类似的东西，SSL 是一个加密套件，对 HTTP 打包的数据进行加密。TLS 是 SSL 的升级版本，现在说到的 HTTPS 加密套件基本上

指的就是 TLS。

传输加密的流程

     原先是 HTTP 应用层将数据打包给 TCP进行传输，现在应用层需要将数据先传给 SSL/TLS 进行加密，然后再传给 TCP。

HTTPS 怎么加密数据的？

     常见的加密手段有对称加密和非对称加密。

对称加密：

指的是，加密数据和解密数据用的是同一个密钥。对称加密的优点在于加密、解密效率比较高。缺点在于发送方和接收方公用一把密钥，如果这个密钥

泄露了数据依然是不安全的。

非对称加密：

指的是，加密数据用的密钥和解密数据用的密钥是不一样的，分为公钥(Public)和私钥(Private)，公钥是公开的，相对的私钥是非公开的密钥，这里有一点

需要注意，公钥加密的数据可以用私钥解开，同样使用私钥加密的数据也能通过公钥解开。

一个关于非对称加密的例子：

假设小明是某个知名网站 ZH 的用户，ZH 处于安全考虑在小明登陆的地方使用了非对称加密。小明在输入帐号、密码然后点击登陆。然后浏览器通过公钥对

小明的帐号密码进行加密，并向 ZH 发送登陆请求，ZH 通过私钥对数据解密，并进行验证，验证通过后将小明的个人信息再次通过私钥加密，传输回浏览器，

。浏览器再使用公钥解密，并展示给小明。

前面说过公钥和私钥可以相互将对方加密的数据解开，而公钥又是公开的，如果中间代理获得公钥，那么可以很容易的将小明的数据解开，所以，非对称

加密只能保证单向数据传输的安全性。

这里有两个问题 1：如何获取公钥？ 2：数据传输仅单向安全

1：如何获取公钥？

这里牵涉到两个非常重要的概念：证书、CA(证书颁发机构)

证书，可以理解为一个站点的身份证，这个身份证里面包含了很多信息，其中就有公钥。

当我们访问 ZH 的时候，ZH 就会把证书颁发给浏览器，告诉浏览器访问 ZH 的时候使用这个证书里面的公钥对数据加密，这里又会有一个问题，证书是哪来的

？这个就需要 CA 了。

CA(证书颁发机构)，网站在建站之初会向 CA 提交申请，当申请审核通过后，就会给网站颁发证书，用户访问网站的时候，网站将证书颁发给用户(其实是给到

浏览器，用户是无感知的)。

到这里我们已经知道了证书和公钥都是怎么来的了。

2：数据传输仅单向安全

上面我们说到通过私钥加密的数据也可以用公钥解开，那这样表明网站传给用户的数据也是不安全的，这时候我们会想既然 HTTPS 也是不能完全保证数据的安

全传输，那么为什么现在对 HTTPS 的呼声也很高呢？因为，HTTPS 可并不是仅仅只使用了非对称加密它还结合使用了其他手段，比如使用了对称加密来确保授权、

加密传输的效率、安全性。

概括的来说，整个简化版的加密通信的流程是这样的：

1.小明访问 ZH，ZH 将自己的证书给到小明(其实是给到浏览器，用户在这里对这个过程是无感知的)

2.浏览器从证书中拿到 ZH 的公钥 A

3.浏览器生成一个只有自己知道的对称密钥 B，使用公钥 A 加密，加密的数据包含对称密钥 B，并传给 ZH(这个过程是有一个协商的，这里便于理解简化了)

4.ZH 通过私钥去解密，拿到对称密钥 B

5.浏览器、ZH 之后的数据通信，都是使用对称密钥 B 进行加密

注意：对于每一个访问 ZH 的用户，生成的对称密钥 B 是不一样的，比如说小明、小花、小华可能生成的就是B1、B2、B3

证书可能存在哪些问题？

          简单的了解了 HTTPS 加密通信的流程后，我们会想如何保证证书是合法有效的呢？

证书非法可能会有两种情况：

1.证书是伪造的，压根不是 CA 颁发的

2.证书被篡改过，比如说将证书中的公钥给替换了

示例：

假设，小明登陆 ZH 网站，小明的请求先到了代理服务器上，代理服务器再将请求转发到授权服务器，假如，有一天代理服务器被入侵了，将小名的请求拦截了，

同时，返回了一个非法的证书，然后小明(浏览器)相信了，那么小明的数据将再次不安全，那么，是通过什么机制防止这样的事情发生的呢？

我们先来看一下证书都包含哪些内容，这样我们就可以知道防护措施了。

证书简介

         我们先看一下什么是数字证书和摘要，这两个是证书防伪非常关键的点。

数字签名与摘要：

简单的说，摘要就是对传输的内容，通过 hash 算法计算出一段固定长度的串，然后再通过 CA 的私钥对这段摘要加密，加密后得到的结果就是数字签名。

明文->通过 hash 算法->摘要->CA 私钥->数字签名

现在我们来了解一下证书中都包含哪些内容，证书的内容非常多，我们需要关注的点有几个：

1.证书包含了颁发证书机构的名字

2.证书本身的数字签名(用 CA 私钥生成)

3.证书持有者的公钥

4.证书签名用到的 hash 算法

有2点需要注意：

1.CA 有自己的证书，被称为 "根证书"，这个"根证书"是用来证明 CA 自己的，本质是一份普通的数字证书

2.浏览器通常会内置大多数主流权威的 CA 的根证书

如何辨别非法证书：

1.证书颁发机构是伪造的，浏览器不认识，直接认为是危险证书

2.证书颁发机构确实存在，于是根据 CA 名，找到对应的内置 CA 根证书、CA 的公钥

3.用 CA 的公钥，对伪造的证书的数字签名解密，发现解不了，认为是危险证书

HTTPS 如何保证数据加密传输的安全机制基本上都覆盖了，细节的技术这里没提，方便于理解，这里还有两个问题没有解决，

1.网站是如何将证书给到浏览器的

2.上面我们提到浏览器会生成一个对称密钥，这个对称密钥是如何协商的

HTTPS 的数据传输流程和 HTTP 是类似的，同样包含两个阶段，握手，数据传输

握手阶段，证书下发，密钥协商(这个阶段都还是明文的)，数据传输是加密阶段，用的就是在握手阶段协商出来的密钥

原文地址：https://blog.csdn.net/jasonjwl/article/details/50985271

--------------------------------------------------------------------分割线--------------------------------------------------------------

看到一篇比较不错的文章，写的也是非常简明易懂，贴出来看看

　首先先举一个例子：

假设你坐在一个教室里面，你现在非常想把某个信息传递给教室里的另一个人，一般我们会选择传纸条。传纸条这个比喻相当正确，因为

这就类似互联网的一个基础协议 TCP 协议的工作模式。通常情况下，HTTP 协议的数据是使用 TCP 传输协议传输的。HTTP 指的是你在纸

条上写的你要传递的目的地的作为，再然后才是你想要传输的内容。途径的同学拿到纸条后根据上面的地址传过去就行了。这样要面临一个

问题：途径的同学完全知道你纸条上写的什么。

这就是 HTTP 面临的一个问题，这个问题通常情况下被叫做 "窃听"，指的是在接受方和发送方之间的任意一个节点这个节点可以是路由可

以是代理服务器，可以偷窥到你传输的内容。这当然也是 HTTPS 要解决的第一个问题。这种问题通常是通过"加密"解决的，一般采用一种叫

做 AES 的算法来解决的，这种算法需要一个密钥 KEY 来加密整个信息，加密和解密所需要使用的 KEY 是一样的，所以这种加密一般也叫作

对称加密。AES 在数学上保证了，只要你使用的 KEY 足够的长，破解是很难的。

我们假设这种破解几乎是不可能的，现在我们再次回到教室，你接着传纸条，你把地址写上了，也用了 AES 对传输的内容加密了。但是问

题来了，AES 有一个 KEY，我们怎么把 KEY 传输到目的呢？不然对方收到后没法解密啊，如果我们把 KEY 直接写在纸条上那么中间人也可

以解密，在现实中你可以通过一些其他办法来把密钥安全地传输给目的地，但是在互联网上要想这么做是很难的，毕竟这个过程会有很多节点

，所以，貌似这种方式也是不安全的。

我们现在来使用另外一种加密算法---非对称加密算法， 这种算法理解起来可能会困难一点，这种加密指的是可以生成一对密钥(K1，K2)凡

是 K1加密的数据，K1 自身不能解密，而需要 K2 才能解开；凡是 K2 加密的数据，K2 自身不能解开，需要 K1 能解开。这种算法有很多，常

用的就是 RSA ，我们现在继续传纸条，但是传纸条之前需要先准备把接下来通讯的对称加密密钥给传输过去。于是，你使用 RSA 生成一对密

钥 K1，K2 ，你把K1 用明文送了出去，途中有人或许会劫持，但是没有用，K1 加密的数据需要使用 K2 才能解密，而此时 K2 在你自己手里，

K1 到达目的地后，目的地的人会去准备一个接下来用于加密传输内容的对称密钥 KEY，然后使用 K1 把 KEY 加密了，把加密好的数据传回来

，就算途中的人劫持了也解不开，等到了你的手上你用手上的 K2 把K1 加密的 KEY 解出来，现在整个班级只有你和目的地有 KEY，你们就可

以使用 AES 算法进行加密传输了。

当然这个时候会有两个问题：

1：既然非对称加密算法那么安全为什么不直接使用它来加密信息呢，而是去加密 对称加密的 密钥呢？

因为非对称加密密钥对生成和加密消耗的时间比较长，为了节约双方的计算时间，通常只用它交换密钥，而非直接用来传输数据。

2：非对称加密是完全安全的吗？

听起来是挺安全的，但实际上，还有一种更恶劣的攻击是这种方法无法防范的，这就是传说中的“中间人攻击”。我们继续让你坐在教室里

传纸条，现在你和你的目的地途径一个中间人，他有意想要知道你们的消息。我们将你称为 A，你的目的地称为 B，而中间人称为 M。当你和 B

完成第一次密钥交换的时候，途径了 M，M 知道你要进行密钥交换了，它把小纸条扣了下来，伪装自己是 B，伪造了一个 KEY，然后用你发来的

密钥 K1 对 KEY加密返回给你，你以为你和 B 完成了密钥交换，实际上你是和 M 完成了密钥交换。同时 M 和 B 也完成了一次密钥交换，让 B 误

以为和你完成了密钥交换。现在，由A->B 完整的加密，变成了 A(加密链接1)->M(明文)->B(加密链接2)的情况了。这时候 M 依然能够知道 A 和 B

传输中的全部信息。

对于这种事，似乎很难找到一个解决办法来解决这个问题，除非我们能从源头保证交换密钥的对象是安全的。这时候我们就要认识互联网 HTT

PS 和 传纸条的微妙区别了。传纸条的时候，你和你的目的地的关系是对等的。而你访问网站的时候，你访问的对象通常是一个比较大的服务提供

商，他们有充沛的资源证明他们的合法性。

这时候我们会引入一个第三方叫做 CA，CA 是一些非常权威的专门用于认证一个网站合法性的组织。服务商会向他们申请一个证书，使得他们

建立安全链接时可以带上 CA 的签名。而 CA 的安全性由操作系统或浏览器来认证。你的 Windows、Linux、Chrome等会默认内置一些 CA 证书列

表，如果和你建立安全链接的人带着这些人的签名，那么认为这个安全连接是安全的，没有遭到中间人攻击。

CA 证书通常情况下是安全的，因为一旦某个 CA 颁发的证书被用于非法途径，浏览器和操作系统一般会通过更新将整个 CA 颁发过的全部证书

视为不安全。这使得 CA 在颁发证书的时候是比较小心的。

所以，通过 非对称加密 + 对称加密 + CA 认证这三个技术混合在一起，才使得 HTTP 的后面加上了一个 S-Security。实际上 HTTPS 的协议比

我这里描述的更加复杂一些，这里主要说的是基本的实现原理。因为其中任何一环稍有闪失，就会使得整个加密都将变得不安全。这也是为什么 HT

TPS 的加密协议从 SSL1.0升级到SSL3.0再被 TLS1.0 取代现在被TLS1.2取代，但即使如此，你的 HTTPS 尽可能的保证了你传输的安全，但这种安

全也不是绝对的，比如说 CA 证书被用于了中间人攻击，短期内，你的安全将陷于直接的麻烦，直到浏览器或操作系统重新更新了 CA 列表或你手动

调整了列表，但是大多数情况下还是安全的。