下面的整理来自一个B站up主的视频，讲的特别好，推荐给大家，视频链接：https://www.bilibili.com/video/BV1w4411m7GL
首先要知道https 是 非对称加密 + 对称加密 + 带有数字签名的证书 三者组合使用一种安全网络传输技术。
因为对称加密用到的key也是需要在网络上进行传输的，也就是说当客户端在向服务器发送数据的时候，发送的不单纯是加密了的data了，还会携带一个用于加密的key(必须得浏览器自己携带啊，不然浏览器怎么知道对方服务器使用的key呢)，那这个key可能就会被中间人窃取，那黑客拿到了这个key，将这个key作为参数传递给解密算法（至于用的什么算法，什么方式进行的加密，反正就只有哪几种加密算法，那黑客挨着试试就可以了），那数据就被破解了。并且一台服务器上，所有用户使用的key都是一样的，不可能一个用户一个key，那只要黑客一破解了这个key，那所有用户的数据就白加密了。
下面这个代码里面就是对称加密算法需要的一个key。当然可以看到下面的代码在努力的让这个key动起来，让他不是死的，这样能增加key的安全性，但也没有https安全啊，因为它生成了是要传递给客户端的，而https不需要一个裸露的传递过程。
对于非对称加密要知道的是：非对称加密有两个密钥：公钥和私钥，并且用公钥加密的数据，只有对应的私钥能解开，对于用私钥加密的数据，只有对应的公钥能解开。服务端持有公钥和私钥，并且私钥只有服务端可以持有。
第一步客户端发送请求，索要公钥，拿到客户端本地
第二步将使用公钥进行加密的数据发送到服务器
服务端通过私钥对数据进行解密，这样就拿到数据了
这样看似很完美，因为即使黑客截获到了数据，因为他没有私钥是没法对数据进行解密的
但有一个致命的缺点，就是服务端怎么给客户端返回数据呢？首先服务器肯定更不能使用公钥对数据进行加密啊，因为客户端没有私钥，是没法对数据进行解密的
那服务端只能使用私钥对数据进行加密了，加密之后发给客户端
但此时问题来了，在上面的第二步的时候，黑客也可以截获公钥啊，公钥所有人都能拿到，那么黑客就可以对服务器返回来的数据进行截获，然后用之前拿到的公钥进行解密就可以了，这也不安全啊。
也就是说客户端向服务器发送数据是安全的，但服务端向客户端返回数据是不全的。
先利用非对称加密的方式在服务端和客户端达成一个协商，协商出一个临时指定的key，在协商出这个key之后，再使用对称加密使用这个key。因为这个key是这个客户端跟服务端商量出来的，而其他的客户端或是请求商量的key会是另外一个值的key，复现一下过程：
第一步客户端还是去服务端索要公钥
客户端随机产生一个字符串，并用索要的公钥对这个字符串进行加密，然后发送给服务端
服务端拿到这个数据后，用私钥对这个字符串进行解密，这样这个字符串就作为之后的对称加密的key就可以了，因为黑客们是不知道这个随机字符串是啥，之后就用非对称加密进行通信就可以了
第一步还是客户端先去服务端索要公钥
但此时第一步的时候黑客就介入了，拦截了请求，客户端不是索要公钥嘛，那黑客这里准备了自己的黑公钥和黑私钥，然后把黑公钥发给了客户端
此时黑客会继续假装良民去服务端索要一个公钥，拿到服务端真正的公钥后，自己留着
同时客户端那里，自己生成一个随机的字符串num1，用黑客的公钥进行加密，然后发送的时候，又被黑客拦截
黑客拦截后用黑私钥对客户端发来的数据进行解密，然后拿到了这个随机字符串num1
同时黑客做第二手打算，也随机生成一个字符串(当然也可以用解密得到的上面的num1)，用服务端的公钥加密后，发送给服务端
这样客户端服务端都以为没问题了，连接建立了，之后这个对话过程就开始了,
客户端发送数据X1给黑客，黑客也发送同样的数据X1给服务端；服务算发送数据X2
给黑客，黑客也发送数据X2给客户端，充当中间人，并且黑客能获取所有的数据信息，比如银行里面的信息，账户密码信息等，黑客可以随意修改传输的数据，比如转账的时候把转账的卡号改成自己的，再发给服务器，那么用户转账的金额全到了黑客账户里。
所以对称+非对称也存在很大问题：
就是中间人问题。
中间人是怎么产生的呢？是因为第一步的时候他就介入了，那么解决思路就是，在第一步就限制住中间人，让他无缝可钻。
解决办法就是引入CA，一个权威机构。
因为导致上面问题是因为客户端不知道第一步拿到的公钥是好是坏，那这样的话，设置一个权威的机构，只有这个权威机构认证的公钥才是好公钥，其他的都是黑客的公钥。
以前客户端在第一次请求的时候，服务器会直接把非对称加密的公钥发给客户端，现在呢，在客户端第一次请求的时候，不再直接发送公钥了，而是先使用CA的私钥对 非对称加密的公钥 进行加密，生成证书，把生成的证书返给客户端。
收到证书以后，要做的第一件事情是验证证书的真伪，如果能用ca的公钥将加密的证书解开，那么就证明证书是有效的，就是说明是真正的服务器发过来的。
那证书发到客户端怎么对签名的证书进行解密呢？当然是用证书机构的公钥进行验证解密，因为服务端使用证书机构的私钥对证书进行的加密（其实就是所谓的证书签名）。
那证书机构的公钥在哪里呢？我们需不要去证书机构的服务器上去拿这个公钥呢？不需要的，因为浏览器里面已经内置了大量证书的公钥，如下面的截图：百度一下的证书，可以看到证书公钥就在浏览器内。
所以就直接在浏览器里面拿着证书的公钥对证书进行校验就行啦，校验通过了就是合法的证书，就代码服务器是我真正要访问的服务器，而不是中间人伪造的服务器。用证书机构的公钥解密后，同时也会拿到里面非对称加密的公钥了,然后生成一个随机的字符串，用非对称加密的公钥进行加密，之后的步骤就跟之前 对称加密+非对称加密方式的步骤一样了。
拿百度来说：有个小锁，就说明他是https
点开上面的证书：可以看到下面的信息
-------------------------网上的答案--------------------------------------------------------------------
正常情况下的 https 就不需要单独加密了。
公司锁了大门，个人的抽屉需要上锁吗？
分情况，很多场景需要后端加密，只确保传输层安全（https就是实现的传输层的安全）是远远不够的。前端加密倒是可以部分取代，例如登陆密码的传输。
顺手能加个密就加吧，毕竟 HTTPS 只是协议层的加密，业务层不确定因素还是挺多的。
服务器不完全可信，我会担心 1password 的 admin 看我密码。而 CA 想要中间人我，还要控制网络。
密码不需要向其他人传输，密码只有我需要知道。我不需要信任链，只需要 PSK。
前端加密也不是完全不可取。最早的做法 md5 连续做 30 次 再和网页的里一个变量做一个 md5。安全性也是不低的。服务器里寸的是密码 md5 30 次。
--------------------------网上的答案结束---------------
下面是自己的分析：
我觉得有些情况是需要加密的，比如密码这样的数据，首先如果不加密的话，在浏览器里面F12查看的话，查看传输的参数那里，看到的是明文信息，并且我记得中创的时候，数据库里面的密码都是加密了的，数据库里面保存的也是加密了的密码，通常只有用户自己知道密码是啥，那中创的那种情况，后台是怎么知道用户输对还是输错了密码呢？后台肯定知道我前端用的是什么加密方式啊，或是直接进行对两个加密的后的密文进行比较也行啊，如果用户输对了的话，数据库里面的密文和从前端传过来的密文应该是一致的，这样就进行了校验了。
