HTTPS 算法的灵魂拷问
本文来自他人的整理，版权归原作者所有
HTTPS 四个加密算法追问：
对称加密和非对称加密分别都有什么？
为什么对话要用对称加密，不能一直用非对称加密吗？
数字摘要是什么时候加的？连接建立后，每一次的发送都要加数字摘要吗？
数字证书有公钥，服务器还要再发一份给客户端吗？
数字证书的主要内容有哪些？
解决上述问题：
HTTPS主要利用了如下四种算法解决传输内容安全性的问题：
对称加密（保证数据的安全性）
非对称加密（保证对称秘钥的安全性）
数字摘要（用来辅助数字证书进行验证）
数字签名（证明证书的完整性）
对称加密
对称加密就是通话双方利用「同一对」秘钥进行传输内容的加密过程。
但是！两者一样，中间被截走了钥匙🔑后，还是相当于明文传输了。
因此，这个时候，就需要一种机制来保证钥匙能够安全的传输，所以在传输对称秘钥的时候，加入了一层非对称加密
非对称加密
非对称加密是通信双方各持有一个秘钥：公钥、私钥。私钥由钥匙生产者所有，公钥由钥匙生产者广播给大家。
加密方式为：公钥加密，私钥解密；私钥加密，公钥解密
How: 如何工作呢？
首先客户端通过URL访问服务器，建立SSL连接
服务端收到客户端请求后，回将公钥给客户端
客户端拿到公钥后，由客户端建立会话秘钥，使用服务端提供的公钥对会话秘钥进行加密，传送给服务端
服务端利用私钥对传送回来的信息进行解密，得到会话秘钥
利用会话秘钥加密与客户端之间的通信
这里：
为什么必须要客户端来建立会话秘钥呢？
因为非对称加密是只能公钥加密，私钥解密，或者私钥加密，公钥解密。如果类似于第一种对称加密的情况，中间被劫持了公钥，如果对称秘钥是由服务端生成，那么公钥劫持者还是能够获得对话秘钥的，没有用。而如果是由客户端进行建立，并用公钥进行加密，那么即使公钥再被人劫持，他也无法解开由公钥加密后的密文，因为公钥无法解开公钥加密的内容嘛
另外，
既然非对称加密算法这么安全，为什么不每一次都使用非对称加密来进行内容的传输呢？
这里主要是两种算法性能上的影响。
对称加密：两个钥匙一样，计算方式一样，相比于非对称加密来讲，计算简单，性能也响应的更高，加密速度快，更加高效
非对称加密：两个钥匙不一样，计算方式就比对称加密复杂了，性能也会有影响，解密是建成，效率低
因此，如果非对称加密能够保证对称秘钥的安全传输，为了更高效的传输信息，后面更好的方式是使用对称加密，这样非对称加密的使命就完成了。
PS：
常见的对称加密和非对称加密算法：
对称加密：AES、DES
非对称加密：RSA
BUT！
难道只加上一层非对称加密就安全了吗？
漏漏漏！如果遇到「中间人攻击」还是不行，直接完全截胡，由中间人拿到服务器的公钥，自己建立和服务器的对话秘钥，然后自己当成服务器，同样的一套操作建立和客户端的连接，那么这中间的通话主导权就完完全全的掌握在了中间人的手里。即中间人可以伪造一堆非对称秘钥。
那咋办呢？
这个时候，伟大的CA机构就需要登场了！！！✨
哒哒~
CA机构是给服务器办法数字证书的，当服务器发送公钥给客户端的时候，不是发送公钥，而是直接发送「经过认证的数字证书」，证书里有服务器自己的公钥供客户端提取。
BUT，伪造证书了咋办？所以需要数字摘要哇。
数字摘要就是对一段信息经过指定的一个hash算法，通常是SHA256，生成一个长度固定的字符串，嵌在传送内容的后面，当客户端获取到信息后，对于信息再次使用同样的hash算法进行字符串的生成，对比两个字符串，如果字符串一样，则内容没有发生修改，否则则有修改。
因此，服务器就要委托这个CA机构进行证书的构造啦
数字证书的构建：
首先，服务器把自己的身份信息给CA机构，同时呢，也把公钥提供给CA机构。
CA机构这个时候，就生成了粗略版本的证书：
签发者信息
证书版本号
证书序列号
hash算法（签名算法）
服务器信息（身份信息）
证书有效期
公钥（Pub key）
但此时的证书不具有安全性，万一被篡改也不知道，因此，CA机构会将这些内容，根据指定的那个hash签名算法进行hash操作，得到「数字摘要」H，同时利用CA机构自己的私钥，对这个数字摘要H进行加密，得到「CA机构对于这个数字证书的签名S（Signature）」，并将这个Signature放到证书的里面，即最终生成的证书主要内容有：
签发者信息
证书版本号
证书序列号
hash算法（签名算法）
服务器信息（身份信息）
证书有效期
公钥（Pub key）
数字签名
OK，CA机构已经对服务器的信息、公钥进行了认证，那么他就将这个证书发给了服务器。服务器再建立连接时，就不是发公钥啦，而是直接把证书发给客户端，客户端直接使用里面的公钥即可。
但是客户端如何认证其中公钥的正确性的呢？
PS：权威的CA认证的公钥已经提前设置在我们设备当中了。
因此，客户端就可以从证书中提取出CA的数字签名，利用CA的公钥对签名进行解密，得到证书上面内容的hash值H。
同时，客户端用证书中指定的hash算法对上面的内容进行同样的hash加密，得到对应的hash值H’
对比H 和 H’，如果相同，则表示证书没有被篡改，否则就代表有问题。
那么中间人也有公钥，不是可以对证书解密，再进行篡改吗？
但是，中间人即使利用CA公钥进行解密了，并对其中的公钥和签名同时做了更改（用自己的私钥），但是客户端没有对应做签名的公钥哇，那这自然是无法认证成功的。
因此，这样就可以保证数字签名靠一己之力，既将pub key安全送达，同时也能保证pub key确实送的是正确的。
这样当pub key安全的传送后，后面的通话就安全了。那么实际上也就没有必要使用数字摘要了。
因此：
数字摘要只需要在开头，CA机构对数字证书进行签名，以及客户端进行数字证书验证的时候使用。当连接安全建立起来时，只需要对称秘钥加密即可。
服务器这边也不需要再次单独传公钥给客户端。
即实际上建立SSL的过程是:
客户端通过URL访问服务器建立SSL连接
服务器收到客户端的请求后，将数字证书（包含公钥）传给客户端
客户端生成会话秘钥，并用服务端的公钥对会话秘钥进行加密，并传送给服务器
服务器利用私钥解密出会话秘钥
服务器和客户端之间通过会话秘钥进行通信
粗略流程图：
一个自签名证书的实际内容：
