如何简单理解HTTPS
HTTPS作为老生常谈的技术，想必大家都多少有所耳闻，这篇文章主要目的是希望能帮助对HTTPS不太熟悉的朋友比较轻松的理解并掌握HTTPS的基础概念。
加密技术
根据马斯克的第一性原理，先从能力范围内的最小原理讲起，我们在讲HTTPS之前我们先了解一下HTTPS使用的加密技术有些，这部分内容可能有点枯燥，但他们是基础，对后面理解HTTPS非常有用，在区块链中也是大量用到这些加密技术。
当前主流的加密技术一般分为两类：一类是可逆加密，一类是不可逆称加密。可逆加密又分为对称加密和非对称加密。这里提一下我们非常熟悉的base64编码，不属于加密算法，只是一种编码方式，类似UTF-8和ASCII，能够将任何数据转换为易移植的字符串，主要是为了避免了传输过程中失真问题。
对称加密
对称加密的解密和加密都是用同一个密钥，如果想要用对称加密和别人通信，必须把密钥告诉别人。你用密钥加密通信内容，别人用密钥解密通信内容。
对称加密的优点是加密和解密的速度比较快，适合大数据量的加解密。但是如何安全的传输密钥是个问题，而如果一直用同一个密钥，密钥的保存也是一个问题。
常见的对称加密算法有:DES、3DES、AES
非对称加密
非对称加密会有两个密钥，一个私钥，一个公钥。那什么是公钥，什么是私钥？公开给别人的是公钥，自己保密的是私钥，私钥可以推导出公钥，但是公钥不能推导出私钥。
公钥加密，私钥可以解密。私钥加密，公钥可以解密（这里一般说私钥可以签名，公钥可以验签）。到底为什么，可以参考这里
非对称加密的优点在于不需要泄露私钥，就可以互相通信，如果用私钥加密，公钥解密，我们可以确定这个报文来一定自于某人。但是缺陷在于非对称加解密的成本较高，速度比较慢，适合少数据量的加密传输。非对称加密，也会存在中间人攻击的问题（后面会讲），但是安全系数要比对称加密高。
常见的非对称加密算法：AES、ECC
不可逆加密算法
这里的不可逆既指不能根据转换后的结果逆转回原文，也指对于两个输入，即使其转换结果相同也不能说这两个输入就一定相同。常见的不可逆算法，比如Hash算法可以将任意长度输入转换成固定长度的输出，这个固定长度的输出就是Hash值。因为，Hash 算法的定义域是一个无限集合，但是值域确是一个有限集合，将一个无限集合映射到有限集合上，每个哈希结果都存在无数个可能的目标文本，因此哈希是一个多对一的映射，所以它也不存在逆映射。不同输入转换得到同一个输出称为Hash碰撞，防止哈希碰撞的最有效方法，就是扩大哈希值的取值空间。例如一个22个字符Hash值能保证300万亿次计算里面，只有1000亿分之一的概率发生碰撞。常见的SHA256哈希函数产生的是64个字符的哈希值，发生碰撞的概率还要低得多。
使用场景：
- 一般常在用户密码加密，其验证过程就是通过比较两个加密后的字符串是否一样来确认身份的。
- 文件传输，比如我们下载软件时网站都会提供一个md5值，在下载完成之后，对文件内容进行md5计算，然后和网站的md5值比较，结果一致就代表文件内容完整。
- 区块链中也是用SHA-256，保证它的不可篡改性，对此有兴趣推荐廖雪峰的区块链教程
常见的不可逆算法有：MD5、SHA-1、HMAC、HMAC-MD5、HMAC-SHA1 等
这里留个坑，前面只是讲了这些算法的特性，但是为什么加密算法可以做到非对称加密和不可逆加密，涉及到很多数学问题，本人能力有限就不展开讲了 - -!
为什么我们需要HTTPS
在没有HTTPS之前，我们在网络上传输的报文，只要在某个节点被别人拿到，我们能解析报文拿到明文内容，这里面可能会有我们银行卡，密码，手机号等敏感信息，是非常不安全的。
HTTPS的出现就是为了解决这个问题，对传输的报文内容先加密，再传输，这样别人即使拿到报文，如果没有密钥，也无法还原出明文内容。同样如何安全的传输密钥也是HTTPS要解决的问题。
什么是HTTPS
HTTPS全称是Hypertext Transfer Protocol Secure，是HTTPS协议的拓展，它是在HTTP的基础上封装了一层加密。具体如下图：
HTTPS常见的加密协议一般有两种SSL(Secure Sockets Layers)和TLS(Transport Layer Security)，TLS是在SSL的基础上发展而来的，就像HTTP2和HTTP1.1的关系，现在的HTTPS用两种协议都有，而且这两种协议也存在不同的版本。具体关系如下图：
关于SSL和TLS的不同可以看这篇SSL vs TLS - What's the Difference?
HTTPS是如何运行的
前面讲到的加密算法都不能完全满足我们的安全需要。
对称加密：传输密钥，如何保证密钥不能泄露，一旦泄露，任何人都可以冒充服务端给客户客户端发信息，而且也可以冒充客户端给服务端发信息。
非对称加密：虽然可以保证私钥不被泄露，但是公钥如何安全传输是个问题，如果公钥被截获，就可能存在中间人攻击。
中间人 Chad 把自己伪装成 Bob 向 Alice 要信息，然后，再伪装成 Alice 对 Bob 说，这就是 Alice 的公钥（实际上是Chad的公钥），于是 Bob 也无法验证是不是 Alice 的公钥，因为公钥里就是一堆乱七八糟的数据，我们完全不能分辨哪个公钥属于 Alice 的。试想，如果我们收到声称属于银行的密钥。我们怎么知道它确实属于你的银行？
这时候就需要数字证书，来做第三方认证。
为了解决公钥认证的问题的，我们需要一个权威的CA 机构。
- Alice 把自己的信息（姓名、组织，地址，电邮，网址等）和自己的公钥打包成一个 CSR 的文件，发给 CA 机构，
- CA 机构会来找 Alice 做物理世界的认证，如果通过后，就会用自己的机构私钥，把CSR 变成一个签名证书。
- Bob 同学拿到 Alice 的证书，用 CA 机构的公钥解密后，得到 Alice 的公钥
- 后面就可以签证 信息是否来自 Alice 了。
https的加密过程
第一步 客户端向服务端发起连接请求，告诉服务端采用的加密协议和客户端支持的加密算法。
第二步 告诉客户端，服务端选择加密算法，服务端的公钥，服务端的数字证书，会话id。
第三步 客户端用CA机构的公钥解密数字证书，如果解密成功，就代表这个证书确实是CA机构签发的，是有效的。
第四步 用服务端的公钥加密客户端的随机密码，发送给服务端。
第五步 服务端用私钥解密拿到客户端的随机密码。采用对称加密算法，用随机密码对finish消息加密。
第六步 解密得到finish消息，同样采用对称加密算法，用随机密码对finish消息加密。握手阶段完成。
第七步，第八步 都是在用对称加密算法对通信消息加密，正常加解密通信。
注意，这里CA机构只是做了单向的认证，我们只能保证客户端收到消息可以确定这个消息是不是来自正确的服务端，但是不能保证服务端收到的消息来自正确的客户端。有些情况下会需要用到双向认证，比如微信支付和商户之间。这种情况下就要用到mTLS协议，通信的两端都需要拿到CA机构的证书。
前面1-6是建立链接的部分，采用非对称加密，链接建立好了之后，客户端和服务端会成功交换对称加密的密钥，后续的数据传输，都是使用这个密钥进行对称加解密。前面使用非对称加密主要是为了安全性，后面安全的交换了密钥之后，用非对称加密，可以保证数据传输的效率。
