通俗易懂的解释HTTPS

通俗易懂的HTTPS，SSL，数字签名，电子证书的说明文章.

标签（技术）： 计算机原理与运用

什么是HTTPS?

HTTPS是HTTP协议和SSL/TLS协议的组合。

SSL/TLS是什么？

SSL全名为Secure Sockets Layer，他是网景公司发明的用来解决http协议使用明文传输信息造成的信息安全泄露问题，而发明出来的协议。后来，因为SSL应用广泛，于是他成为了互联网的一个标准。于是SSL被标准化后改名为TLS(Transport Layer Security)。中文名叫做：“传输层安全协议”。

为什么用明文传输信息就会有泄露风险呢？

除开利用各种软硬件漏洞以及非法手段对信息进行窃取外，当你使用网络进行计算机通信时，根据以太网协议，你发出的信息实际上是”共享“到当前你计算机所处子网的所有的计算机的。

最初，我们的计算机是通过集线器/hub连接到一起形成子网的。如下图：

若计算机A向计算机D发送信息，信息由A发送到Hub，然后由Hub广播到计算机A所在子网的所有计算机(BCD)。接受到此消息的计算机会根据消息中包含的head信息，来判断自身的mac地址是否与消息中所附带的mac地址信息一致。若一致则处理，不一致则丢弃。

信息是如何加密的？

要理解信息是如何加密的，首先要对基础密码学做一个大概的了解。 密码学中的信息加密普遍来讲分为两种，它们分别是：

• 对称加密
• 非对称加密

对称加密？ : 非常好理解。加密解密使用同一种“密钥”或者说“规则”，称之为对称加密。 比如我们对某一个文件使用密码123进行压缩。接着再对其使用密码123进行解压缩。密码123，就是一种“密钥”，一种“规则”。

非对称加密？ : 非对称加密是指，加密和解密，使用两种密钥，两种规则。 非对称加密比较难理解，下面我们用一个例子来说明什么叫做非对称加密。

用户A持有一对密钥如下所示

• 公钥 public key，简称pbk。pbk是用加密的。
• 私钥 private key，简称prk。prk是用来解密的。

这一对公钥私钥拥有以下特点：

• 公钥加密，私钥解密。
• 私钥加密，公钥认证。
• pbk和prk是使用十分复杂的算法所计算出的一对密钥，从理论上讲，或者说从数学上讲几乎不可能从pbk推算出prk，或者从prk推算出pbk。
• 公钥加密的内容，通过私钥解密后能还原出原来的内容。私钥加密的内容，通过公钥认证后，亦能还原出原来的内容。

现在用户A向用户B写了一封信。用户A先把pbk，通过明文传递的方式邮寄用户B。用户B收到后，把一个对称加密密钥（比如密码123）通过pbk加密后再邮寄给用户A。用户A收到后使用prk对这个信息进行解密，于是用户A拿到了密码123. 然后用户A从现在开始，就使用密码123，对信息进行加密，和用户B进行书信交流。

什么是数字签名

现在你应该对SSL的加密方式有所了解了。 但是喜欢上网的你，是否遇到过下面这种情形呢？

造成这个警告的原因是，发布这个软件，提供这个信件的用户，没有给这个软件附上一个数字签名。 那么数字签名究竟是啥？ 上面我们提到了SSL的加密解密方式。但是这些只是对信息安全性做了一定程度上的保证。假设，中途邮递员，将信件的部分内容遗失，或者损坏了又该怎么办呢？作为用户我们如何得知，这封信件的内容已经被遗失/损坏了呢？

为了解决这个问题，我们就要靠数字签名这个东西啦。

举例来说，A在写信时，首先对信件内容调用hash函数，生成了一个信息的摘要。A把这个摘要内容通过私钥加密后，附在信件里随信寄出。 用户B收到信件后，通过之前拿到的公钥对这封信进行认证。于是，用户B通过pbk得到了摘要内容。接下来用户B再对用户A信件的正文调用hash函数，然后将通过pbk得到的hashcode和正文调用hash函数产生的hashcode进行对比。若一致，则说明信件的内容是完整的，无损的。

什么是电子证书

在了解什么电子证书之前，先让我们来回顾和总结一下SSL的加密方式。 我们用现实生活中的信件传递，来模拟一次客户端与服务器的通信过程。

1：客户端向服务端发起一次SSL通信请求。

用户A准备开始给用户B写一封加密信件。并且通过邮差(网络)通知用户B。

2：服务端接收到本次SSL通信请求，将准备好的公钥(pbk)，通过网络（邮差）传递给客户端。

用户B得知用户A要给自己写信后，将公钥，通过邮差邮寄给用户A

3：用户A（客户端）得到公钥后，通过公钥，将一个对称加密密钥加密（比如密码123），然后再发送给服务器。

用户A用收到的公钥，将密钥“123”，用公钥加密。加密后的文字不可读。就像这样：54%$#I0X87FE00&*。加密后，再将本串文字，拜托邮差，邮寄给用户B。

4： 服务器收到“54%#I0X87FE00&”后，用自己的私钥将它还原成"123"。至此服务器和客户端都拿到了密码123，并且，就算在通信过程中被窃听，窃贼也无法得知“54%#I0X87FE00&”表示什么含义。*

用户B收到用户A的信件后，用私钥将内容解密得到密码“123”，于是接下来用户B与用户A之间的信件传递就会使用密码123，对内容进行加密。这样即使信件被邮差偷看，邮差也无法了解信件的具体含义。

整个过程的流程图如下：

客户端(A)->服务端(B): 请求开始进行一次SSL通信
服务端(B)->客户端(A): 服务器收到请求，回送公钥pbk
客户端(A)->服务端(B): 使用pbk将对称密钥(密码123)加密,发送给服务器
服务端(B)->客户端(A):  收到公钥加密信息，使用私钥解密，得到密码123，通知客户端准备工作完成
客户端(A)->服务端(B): 从此，开始使用密码123对信息进行加密和服务器进行交流
服务端(B)->客户端(A): ..................
客户端(A)->服务端(B): ..................

SSL加密解密的过程看起来完美无瑕，无懈可击。你根本无法想象它是怎么被设计出来的。

但是，美好的愿景总是用来打破的。 下面，就让我们来尝试一下，破解上述加密解密方式。

通过逐步分析以上通信步骤，我们可以发现，用户A与用户B写信回信，总是要先将信件送到邮差手中。那么，如果邮差对A和B双方进行欺骗，会发生什么情况呢？

*1. 邮差C，在收到用户A的第一封信件时，将信件内容，原封不动的交给用户B。

1. 用户B将公钥包装好后打算邮寄给用户A，于是他把信件交给邮差C。邮差C收到找到公钥后，藏起来，然后拿出自己伪造的公钥，交给用户A。
2. 用户A收到邮差C的公钥后,用邮差C的公钥，对密码123进行加密，然后将信件再给邮差C
3. 邮差C拿到用户A的信件后，用自己的私钥对信件解密，获取到密码123，再用之前私藏起来的用户B的公钥，对信件进行加密，然后将加密后的信件，交给用户B
4. 用户B拿到信件后，用私钥解密，得到密码123。然后通知用户A准备工作完成，开始正式写信。
5. 最后，用户A和用户B的信件，都能被邮差C窃取。因为邮差C通过之前的步骤掌握了密码123.*

用实际通信过程结合图片，来还原和说明上述过程：

客户端(A)->骇客(C): (1)
骇客(C)->服务端(B): (2)
服务端(B)->骇客(C): (3)
骇客(C)->客户端(A): (4)
客户端(A)->骇客(C): (5)
骇客(C)->服务端(B): (6)
服务端(B)->骇客(C): (7)
骇客(C)->客户端(A): (8)
客户端(A)->服务端(B): (9)
服务端(B)->客户端(A): (10)

(1). 请求开始进行一次SSL通信 (2). 收到请求，将请求转发给服务端(B) (3). 误以为收到了客户端A的请求，回送公钥pbk (4). 收到公钥，将服务端的公钥私藏起来，自己计算一只骇客用的公钥，回送给客户端A (5). 误以为收到了来自服务器B的请求，于是用骇客的公钥对密码123进行加密。然后将信息送回骇客手中。 (6). 收到公钥加密信息，使用私钥解密，得到密码123，然后再将密码123用之前私藏的服务器B的公钥加密，发送给服务端 (7). 服务端用私钥解密信息，得到密码123，然后通知客户端准备工作完成。今后使用密码123进行通信。 (8). 通知客户端准备工作完成，今后使用密码123通信。 (9). 通信内容被骇客C窃取 (10). 通信内容被骇客C窃取

通过这样的方式，我们就能破解之前提到的SSL通信的加密解密方式。这种攻击方式，我们称之为：“中间人攻击”。

归根结底，造成中间人攻击得逞的原因，就是邮差C对用户A和B进行了欺骗。A要防范这种攻击，有很多种方式。其中一种方式，就是邮差C必须要想方设法证明，交给用户A的公钥，是真正的服务器B的公钥。A选择信任此公钥后，才继续接下去的步骤。

那邮差C如何证明公钥真的是来自于A呢？ 我们可以假设，有一个权威的，德高望重的，大家都认可的“人”，能够证明某个公钥，就是某个用户的公钥。 这样，大家都通过询问这个“人”，便可以得知公钥是否是捏造的。但是，每个人都去打电话问这个人，查询公钥是否为真，岂不是太麻烦了？ 于是这个人就发明了一种证书，来证明某公钥属于某个人。 这就是电子证书的由来。

在实际的计算机通信中，我们就是采用这种“公证人方式”，来进行SSL通信安全认证的。

所谓的公证人,其实就是CA啦，全名为“数字证书认证机构”，英文全称叫做“Certificate Authority”。 就是它来充当这个“公证人”的角色。

一般的网站运营商，都会提前向CA申请一个电子证书。CA会通过自己的私钥将网站的公钥和网站的各种相关信息，比如域名等等进行加密。加密后形成电子证书，颁发给申请者。申请者，会把这个电子证书部署到服务器上。

对于权威的CA来说，他们的公钥，都会由操作系统内置。比如微软的windows就内置了几十个不同的CA的公钥。客户端收到服务器发来的电子证书以后，会对通过内置的CA公钥，对证书进行认证（私钥加密，公钥认证）。若认证成功，则代表是本次来自服务器的响应，是可信的。

所以，SSL通信，除了加密解密，数字签名以外，应该还要包括对电子证书的验证。它整个的流程图，大致如下图所示：

客户端(A)->服务端(B): 请求开始进行一次SSL通信
服务端(B)->客户端(A): 服务器收到请求，将电子证书，回送给客户端A
客户端(A)->服务端(B): 判断(私钥认证)电子证书，若可信，则从证书中提取出服务器公钥，对密码123加密发送给服务器
服务端(B)->客户端(A):  收到公钥加密信息，使用私钥解密，得到密码123，通知客户端准备工作完成
客户端(A)->服务端(B): 从此，开始使用密码123对信息进行加密和服务器进行交流
服务端(B)->客户端(A): ..................
客户端(A)->服务端(B): ..................

若服务器响应的电子证书是由不受信任的机构颁发的，浏览器会出现以下安全警报：

若服务器响应的电子证书上记载的各种所属信息，和你将要浏览的网站的信息不一致的话，则会出现电子证书冒用警告

总结

长篇大论了一大堆，最后让我们一起来总结一下，也方便一下喜欢直接拉到下面看结论的朋友。

1. https通信是指htttp+ssl.
2. ssl的加密解密方式是非对称加密与对称加密的结合
3. 数字签名，是为了保证数据完整性的一种手段。
4. 电子证书是通过第三方权威机构，结合非对称加密系统，对双方身份的一种认证，是为了保证数据的安全性。

Copyright 2017/08/15 by Chuck Lin

若文章有幸帮到了您，您可以捐助我，以鼓励我写出更棒的作品！