最近准备面试没时间更新，之前对https 还只是停留在一个表层，于是今天继续看了他的协议文档。对它有个重新的认识。

  互联网上传输数据，普遍使用的是超文本传输协议，即 HTTP (HyperText Transfer Protocol)；HTTP 协议定义了一套规范，让客户端或浏览器可以和服务器正常通信，完成数据传输。但是，HTTP 使用明文传输，比如你输入账号/密码提交登录。这个直接就提交给服务器了。这很可能被中间人截取。所以就出现了https .
   对通信数据进行加密，即使被中间截取也无法获取数据，加密传输确实安全，但是客户端把数据加密后，服务器也是不能解密

对称加密

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

  加入一方把这个钥匙泄露了，我们的加密也不安全了。引出了——客户端在每次请求通信之前，先和服务器协商，通过某种办法，产生只有双方知道的对称密钥这个就是一个秘钥交换。通常是采取非对称加密。

RSA 密钥交换算法

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

简单而言，服务器可以生成一对不同的密钥（所谓非对称），一把私自保存，称为私钥；一把向所有人公开，称为公钥
这对密钥有这样的性质：公钥加密后的数据只有私钥能解密，私钥加密后的数据只有公钥能解密
非对称加密的一种经典实现叫 RSA 算法，这种加密算法最早 1977 年由罗纳德·李维斯特（Ron Rivest）、阿迪·萨莫尔（Adi Shamir）和伦纳德·阿德曼（Leonard Adleman）一起提出的，RSA 就是他们三人姓氏开头字母拼在一起组成的

具体的交互过程：

客户端向服务器索取公钥 PublicKey；
服务器将公钥发给客户端（这里没有保密需求，因为公钥是向所有人公开的）；
客户端使用服务器的公钥 PublicKey 把 Pre-Master-Key 加密成密文，传送给服务器；
服务器用私钥 PrivateKey 解密密文，获取到客户端发送的 Pre-Master-Key;
看起来很完美，但是第 2 步骤又引发了一个新问题：

由于互联网是公开的，服务器发送给客户端的公钥可能在传送过程中被中间人截获并篡改,因为中间人也可以生成一对非对称密钥，它会截获服务器发送的公钥，然后把它自己的公钥 MiddleMan-PublicKey 发送给客户端，进行欺骗

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

怎么解决这个问题？

客户端怎么确定收到的公钥，真的就是服务器的公钥？
当客户端收到服务器发过来的证书后，只要证书不是伪造的，那么上面记载的公钥肯定也就是真的！
我们介绍一种防伪手段：签名（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