HTTPS

HTTPS 也是⼀个应⽤层协议. 是在 HTTP 协议的基础上引⼊了⼀个加密层.
HTTP 协议内容都是按照⽂本的⽅式明⽂传输的. 这就导致在传输过程中出现⼀些被篡改的情况.

加密

加密就是把明文(要传输的信息)进行⼀系列变换, 生成密文.解密就是把密文再进⾏⼀系列变换, 还原成明文.
在这个加密和解密的过程中, 往往需要⼀个或者多个中间的数据, 辅助进⾏这个过程, 这样的数据称为 密钥.

为什么要加密呢？
http的内容是明文传输的，明⽂数据会经过路由器、wifi热点、通信服务运营商、代理服务器等多个物理节点，如果信息在传输过程中被劫持，传输的内容就完全暴露了。劫持者还可以篡改传输的信息且不被双⽅察觉，这就是中间人攻击 ，所以我们才需要对信息进行加密。

对称加密

采用单钥密码系统的加密方法法，同⼀个密钥可以同时⽤作信息的加密和解密，这种加密⽅法称为对称加密，也称为单密钥加密，特征：加密和解密所用的密钥是相同的
常见对称加密算法(了解)：DES、3DES、AES、TDEA、Blowfish、RC2等
特点：算法公开、计算量小、加密速度快、加密效率高
对称加密其实就是通过同⼀个 “密钥” , 把明文加密成密文, 并且也能把密⽂解密成明文.

非对称加密

需要两个密钥来进⾏加密和解密，这两个密钥是公开密钥（public key，简称公钥）和私有密钥private key，简称私钥。
常⻅⾮对称加密算法：RSA，DSA，ECDSA
特点：算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂，⽽使得加密解密速度没有对称加密解密的速度快。
⾮对称加密要⽤到两个密钥, ⼀个叫做 “公钥”, ⼀个叫做 “私钥”.
公钥和私钥是配对的. 最⼤的缺点就是运算速度非常慢，⽐对称加密要慢很多.

1. 通过公钥对明文加密, 变成密文，通过私钥对密文解密, 变成明文
2. 通过私钥对明文加密, 变成密文， 通过公钥对密文解密, 变成明文

数据摘要 && 数据指纹

1. 数字指纹(数据摘要),其基本原理是利⽤单向散列函数(Hash函数)对信息进行运算,⽣成⼀串固定⻓度
   的数字摘要。数字指纹并不是⼀种加密机制,但可以⽤来判断数据有没有被窜改。
2. 摘要常见算法：有MD5、SHA1、SHA256、SHA512等，算法把⽆限的映射成有限，因此可能会有
   碰撞（两个不同的信息，算出的摘要相同，但是概率非常低）
3. 摘要特征：和加密算法的区别是，摘要严格意义不是加密，因为没有解密，只不过从摘要很难反推
   原信息，通常用来进行数据对比

通过哈希函数将信息转化为散列值，这个过程是不可逆的，也就是说可以通过判断哈希出来的散列是否相同可以知道数据是否被修改，但是这个过程是不可逆的，直到散列值是不能知道数据的。

应用场景

1. http在某些场景中需要想服务器交付我们用户的密码时，如果不经过任何处理，密码泄漏的风险是很大的，并且在后端MySql中存储的密码如果泄漏了，那么用户都需要修改密码，影响较大，所以可以在想服务器传送密码这种关键的数据时直接通过MD5来进行散列化，然后在服务器后端存储的也是散列化后的数据，这样就算密码泄露了也没事，因为进行散列化，拿到了也没有用。当用户需要验证登录的时候，把输入后的密码进行散列化后和后端的数据对比就可以了。
2. 在网盘等领域，用户存入的数据是很多的，同样用户存储的相同的数据也是非常多的，假设两个人今天都像网盘上传了一个电影，那么后端同样的数据存在两份太浪费空间了，所以可以把这个电影形成一个数据指纹，形成一个指纹库，当用户上传一个电影前先无判断这个电影形成的指纹是否在指纹库中，如果在就不用上传了，直接给该用户建立一个链接文件就可以了。

HTTPS的加密过程

1. 只使用对称加密
   如果通信双⽅都各⾃持有同⼀个密钥X，且没有别⼈知道，这两⽅的通信安全当然是可以被保证的（除⾮密钥被破解）
   
   引⼊对称加密之后,中间人即使数据被截获,但是由于中间人不知道秘钥是啥,中间人因此就无法进行解密,中间人也就不知道请求的真实内容是啥了.但是服务器要和很多客服端通信，和每个客服端的秘钥还不能一样，如果是相同那秘钥就太容易扩散了,中间人就也能拿到了，所以服务器一定要进行管理这些秘钥，管理这些秘钥也是一个麻烦的事情。所以为了不用对密钥进行管理，双方在建立连接时就需要进行秘钥的协商。
   
   但是密钥不能明文传送，所以这个问题就变得无解了。

2. 只使用非对称加密
   如果服务器先把公钥以明⽂⽅式传输给浏览器，之后浏览器向服务器传数据前都先⽤这个公钥加密好再传，从客⼾端到服务器信道似乎是安全的(有安全问题)，因为只有服务器有相应的私钥能解开公钥加密的数据。如果服务器⽤它的私钥加密数据传给浏览器，那么浏览器⽤公钥可以解密它，⽽这个公钥是⼀开始通过明⽂传输给浏览器的，若这个公钥被中间⼈劫持到了，那他也能⽤该公钥解密服务器传来的信息了。所以这个方案也是不行的。

3. 双方都是用非对称加密
   方案二已经已经解决了客服端到服务器的安全通信，所以我们只需要在给客服端使用一下非对称加密，把公钥给服务器，然后服务器就可以通过公钥加密的方式安全的把数据交给客服端，但是依旧存在安全问题，并且非对称加密的效率太低了。

4. ⾮对称加密+对称加密
   服务端具有⾮对称公钥S和私钥S’，然后客户端发起请求得到公钥S，然后通过公钥把对称加密的秘钥发送给服务端，这样双方就可以安全的知道对称加密的秘钥，所以之后就可以使用对称加密进行安全通信。由于中间人没有私钥S’,所以对称加密是安全的。
   
   但是这种场景依旧存在安全问题！！！
   比如说：服务器存在公钥S和私钥S’，中间人也存在公钥M和私钥M’，客户端向服务器发送请求公钥S，但是公钥S被中间人拿走保存起来，把自己的公钥M发送给了客户端，客户端收到报文，客户端不知道公钥被替换过了，所以就拿着这个公钥M给服务器发送形成的对称加密的秘钥X，中间人收到后，解析出来X然后用S加密发送给服务器，然后服务器和客户端中间人都知道了X，这样一来，所有的数据都在中间人的掌握之中，对数据进行修改都是可以的。

所以这个问题的核心在哪？？
核心就在于客户端不知道，无法判定收到公钥的安全性。所以就需要在方案四的基础上引入证书了。

CA认证

服务端在使⽤HTTPS前，需要向CA机构申领⼀份数字证书，数字证书⾥含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书⾥获取公钥就⾏了，证书就如⾝份证，证明服务端公钥的权威性。
这个证书可以理解为一个结构化的字符串。
申请证书的时候，需要在特定平台⽣成查找，会同时⽣成⼀对⼉密钥对⼉，即公钥和私钥。这对密钥对⼉就是⽤来在⽹络通信中进⾏明⽂加密以及数字签名的。其中公钥会随着CSR⽂件，⼀起发给CA进⾏权威认证，私钥服务端⾃⼰保留，⽤来后续进⾏通信（其实主要就是⽤来交换对称秘钥）

CSR文件是可以在线生成的 https://myssl.com/csr_create.html。

CA签名的形成

签名的形成是基于⾮对称加密算法的。

CA通过hash函数对服务器提供的数据进行散列值，然后用自己的私钥进行加密形成签名，然后服务器提供的很多数据都是公开明文的，为证书明文，周狗证书明文和签名一起为数字签名证书。就可以发给服务器了。

从此以后服务器可以直接给客户端发送证书就行了。客户端对证书进行验证。

客户端得到数字证书后，得到数据和签名，把数据通过同样的hash函数形成散列值，然后通过CA的公钥把签名进行解密，这就意味着所有的客户端会有CA的公钥，所以CA的公钥一般是内置在浏览器中的，然后把形成的散列值和签名进行对比，相等就说明数据没有被修改，是可以相信的。通过这种方式可以很好的让客户端判断得到的公钥的合法性。

就算中间人想要破坏，也是会被客户端发现的。如果中间人到了证书，如果修改数据，那么客户端一定会知道，如果修改签名，那么没有什么意义，如果都修改了，因为签名是需要CA的私钥形成的，所以自己无法形成，因此就需要去CA申请一个合法的证书，但是这个证书中是存在域名的，所以中间人形成的证书的域名一定和我们自己的是不一样的，这样客户端也可以发现，所以通过这种方式可以很好的解决这个问题。

HTTPS的最终方案

⾮对称加密+对称加密+证书认证

客户端行服务器请求连接，服务器给客户端一个证书，客户端一定可以拿到正确的公钥，所以就可以把对称加密的私钥传递给服务器，接下来皆可以通过方案4来完成后续通信。


总结：