什么是 HTTPS ?

不管是使用手机还是电脑上网，都离不开数据的通讯。

现在互联网上传输数据，普遍使用的是超文本传输协议，即 HTTP (HyperText Transfer Protocol)

所以，我们以前在上网的时候，会发明 所有的网址都一个 http:// 前缀：

HTTP 协议

简单而言，HTTP 协议界说 了一套规范，让客户端或浏览器可以和办事 器正常通信，完成数据传输

然则 ，HTTP 使用明文传输，比如  你输入账号/密码提交登录：

明文传输

很有可能被中间人窃听，从而造成数据泄露，所以说 HTTP 是不平  安 的，现代浏览器会在地址栏提示连接不平  安 ：

火狐浏览器平安 提示

为了解决平安 传输的问题，人们创造 了 HTTPS，即 HTTP + Secure

为什么 HTTPS 是平安 的？

只要把传输的数据加密，那么通信就是平安 的，前提是除通信双方外，任何第三方无法解密：

加密传输

在上图示例中，通信的数据经过加密，即使被中间人窃听到了，它也无法知道数据内容

火狐浏览器平安 提示

HTTPS 是怎么实现平安 通信的？


加密传输确实平安 ，然则 客户端把数据加密后，办事 器怎么解密呢？又怎样包管 中间人窃听到密文后无法解密呢？

谜底 是：使用对称加密技术

什么是对称加密？

简单而言，通信双方各有一把相同的钥匙（所谓对称），客户端把数据加密锁起来后，传送给办事 器，办事 器再用钥匙解密。同理，办事 器加密后传输给客户端数据，客户端也可以用钥匙解密

那么，新的问题又涌现 了：怎样在通信之前，给双方分派 两把一样的钥匙呢？

如果真的只有两小我 要通信的话，可以简单的私下见个面分派 好，以后要通信的时候用就行。然则 ，实际通信往往是一个办事 器和成千上万的客户端之间，总不克不及 让每小我 都和办事 器先私下见个面

另外，即使使用了对称加密技术，如果一方保管不善的话，也有可能钥匙被人偷了去复制一个，这样就存在很年夜 的平安 隐患，最好是每个客户端每次和办事 器通信都用不合  的密钥

一个简单的解决计划 是：客户端在每次请求通信之前，先和办事 器协商，通过某种办法  ，产生  只有双方知道的对称密钥

这个进程 就是所谓：密钥交换

密钥交换算法有很多种实现，常见的有：

Deffie-Hellman 密钥交换算法

RSA 密钥交换算法

本文以较简单的 RSA 密钥交换为例

简单而言，RSA 密钥交换算法需要客户端向办事 器提供一个 Pre-Master-Key，然后通信双方再生成 Master-Key，最后依据  Master-Key 产生  后续一系列所需要的密钥，包含 传输数据的时候使用的对称密钥

那么，客户端怎么把 Pre-Master-Key 告诉  办事 器呢？直接明文传输么？

我们之前说过，没加密的通信都邑 被窃听，是不平  安 的

似乎进入死循环了：为了加密通信，需要先把 Pre-Master-Key 传送给办事 器，然则 这个传送又必须  要加密

我们引入一种新的加密技术：非对称加密

什么是非对称加密？

简单而言，办事 器可以生成一对不合  的密钥（所谓非对称），一把私自保存  ，称为私钥；一把向所有人公开，称为公钥

这对密钥有这样的性质：公钥加密后的数据只有私钥能解密，私钥加密后的数据只有公钥能解密

非对称加密的一种经典实现叫 RSA 算法，这种加密算法最早 1977 年由罗纳德·李维斯特（Ron Rivest）、阿迪·萨莫尔（Adi Shamir）和伦纳德·阿德曼（Leonard Adleman）一起提出的，RSA 就是他们三人姓氏开头字母拼在一起组成的。

有了非对称加密的技术后，事情就好办了：

客户端把 Pre-Master-Key 用办事 器的公钥加密后，传送给办事 器

因为只有办事 器才有私钥，所以只有办事 器能力 解密数据，获取客户端发送来的 Pre-Master-Key

具体的交互进程 ：

客户端向办事 器索取公钥 PublicKey；

办事 器将公钥发给客户端（这里没有保密需求，因为公钥是向所有人公开的）；

客户端使用办事 器的公钥 PublicKey 把 Pre-Master-Key 加密成密文 PublicKeyEncryptedData 传送给办事 器；

办事 器用私钥 PrivateKey 解密密文 PublicKeyEncryptedData，获取到客户端发送的 Pre-Master-Key;

看起来很完美，然则 第 2步调 又引发了一个新问题：

由于互联网是公开的，办事 器发送给客户端的公钥可能在传送进程 中被中间人截获并修改  （所谓中间人进击  Man-in-the-middle attack，缩写：MITM）

中间人进击

因为中间人也可以生成一对非对称密钥，它会截获办事 器发送的公钥，然后把它自己的公钥 MiddleMan-PublicKey 发送给客户端，进行欺骗

可怜我们的客户端，竟然信以为真！然后傻乎乎的把自己的 Pre-Master-Key 用 MiddleMan-PublicKey 加密后，发给中间人

怎么解决这个问题？

问题等价于：客户端怎么确定收到的公钥，真的就是办事 器的公钥？

想一想你乘高铁、坐飞机的时候，怎么向工作人员证明你是你

谜底 很简单，到公安局（权威机构 英文名：Authority）出个身份证明（Certificate）

身份证上记载了你的号码、姓名、年龄、照片、住址，还有签发机关、有效期等

所以，办事 器也想办法  到权威机构 (Authority) 办一张证书 Certificate，上面记载了办事 器的域名、公钥、所属单位  ，还有签发机关、有效期等

当客户端收到办事 器发过来的证书后，只要证书不是伪造的，那么上面记载的公钥肯定也就是真的！

证书长啥样？

点击 IE 浏览器上的小锁就可以查看办事 器的证书

查看证书

不过  ，这里又有个新问题：怎么证明证书不是伪造的？

我们介绍一种防伪手段：签名（Signature）

什么是签名？

我们在生活、工作进程 中，经常遇到需要签名的情况：刷信用卡、签合同等，用来证明这是本人的行为。签名之所以可信，是因为理论上每小我 的签名都有生理学基础，别人是无法伪造的，就像你的指纹一样

所以，只要办事 器发送的证书上有权威机构 Authority 的签名，就可以确信证书是揭橥  给办事 器的，而不是谁伪造的

这就相当于，只要你的请假条上有领导的签名，那么 HR 就会确信领导已经审批同意你请假了

如果说人类签名使用纸笔，那么计算机的数字化签名怎么实现呢？

谜底 是使用非对称加密技术：

数字证书认证机构（Certificate Authority，简称 CA）生成一对公/私钥；

办事 器将自己的域名、公钥等信息提交给 CA 审查；

CA 审查无误，使用私钥把办事 器信息的摘要加密，生成的密文就是所谓签名（Signature）；

CA 把办事 器的信息、签名、有效期等信息集合到一张证书上，揭橥  给办事 器；

客户端收到办事 器发送的证书后，使用 CA 的公钥解密签名，获得办事 器信息的摘要，如果和证书上记录的办事 器信息的摘要一致，说明办事 器信息是经过 CA 认可的

什么是信息摘要？

简单来说，就是一段任意长的数据，经过信息摘要处理  后，可以获得 一段固定长度的数据，比如   32 字节，只要原始数据有任意更改 ，生成的信息摘要都不一  样

然则 ，在第5步调 又有一个新问题：客户端怎么知道 CA 的公钥？

谜底 ：与生俱来

世界上的根 CA 就那么几家，浏览器或者操作系统在出厂的时候，已经内置了这些机构的自签名证书，上面记录他们的公钥信息，你也可以在需要的时候手动安装 CA 证书

以 Windows 系统为例：

系统信任的根证书

至此，HTTPS 通信进程 已经很明朗了：

操作系统/浏览器 自带了 CA 根证书；

客户端因此可以验证办事 器发送的证书真实性，从而获取到办事 器的公钥；

有了办事 器的公钥，客户端就可以把 Pre-Master-Key 传送给办事 器；

办事 器获取到 Pre-Master-Key 后，通事后 续产生  的对称密钥，就可以和客户端加密通信了。

总结

本文简述了 HTTPS 通讯进程 的基来源基础  理，涉及到了对称加密、非对称加密、信息摘要、签名、密钥交换等技术基础，以及刊行 机构、数字证书等概念

具体的 HTTPS 实现细节还要庞杂 得多，这里并没有展开讲，然则 并不影响对 HTTPS 不熟悉的读者对原理有基本的认知

参考文献

传输层平安 协议规范 https://tools.ietf.org/html/rfc5246

HTTPS 连接前的几毫秒产生 了什么 http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html

查看 Windows 系统根证书 https://technet.microsoft.com/zh-cn/library/cc754841.aspx

存眷 ，收藏，点赞，都是极好的！

文章来源：今日头条(昭通热线网www.ztrxw.cn版权与免责声明：1.本网转载其他媒体，目的在于传递信息，并不代表赞同其观点和对其真实性负责，本网不承担此类稿件侵权行为的连带责任。2.如本网所转载稿件涉及版权等问题，请著作权或版权拥有机构致电或来函与本网联系，本网将在第一时间处理妥当。如有侵犯您的名誉权或其他权利，亦请及时通知本网。电话：0870-2156588 邮箱：信箱：569098112@qq.com。本网在审慎确认后，将即刻予以删除。3.本网原创文章未经允许,私自转载者本网保留追究其版权责任的权利。转载请注明来源昭通热线网www.ztrxw.cn）