linux网络 | 深度理解https加密过程 | 模拟设计方案
前言：本节内容开始理解https的加密， 博主会采用自己设计加密方案的方式， 一步一步带着友友们理解https设计加密方案的原因，其中涉及到了MTM攻击方式、证书的相关内容。 现在废话不多说， 开始我们的学习吧。
ps:本节内容涉及到了https的密钥种类， 数据摘要等知识点， 建议了解后再来学习哦！
目录
对称加密
非对称加密
双方都是用非对称加密
混合使用非对称加密和对称加密
MTM
引入证书
什么是证书
申请证书一般流程
申请证书
编辑
审核
签发证书
返回证书
csr文件
数字签名
客户端接收到证书后认证过程
通信过程
本节的内容博主将一共设计五套方案， 模拟https的工作过程。
对称加密
首先第一套方案是只是用对称加密。 假如今天客户端和服务器都持有一个密钥。
就如同上图，双方都约定好了一个秘钥，客户端发送请求，要先加密，加密后就形成了密文。 这个时候如果有黑客成为了中间人，那么黑客截取到了密文也不知道里面的信息是什么。然后密文再发送到服务端，服务端使用秘钥解密后就能获得数据。这是我们理想的状态。
但是现实是我们的客户端能够拿到密钥， 中间人为什么拿不到密钥呢？ 客户端拿到密钥的过程， 一定是向服务端发起请求的过程。 那么客户端一旦发起了请求， 这个时候客户端和服务端之间的信息是没有密钥保护的， 所以中间人就能够拿到两端交互的信息， 只要服务端发给客户端密钥， 那么中间人就能拿到。 在这种情况下， 中间人不就也能有密钥了？ 所以， 这种方案是行不通的。
非对称加密
第二种方案是使用非对称加密
一开始，客户端向服务器请求公钥，然后服务端将公钥发给了客户端。以后我们客户端向服务器发送请求，就是用公钥加密，因为世界上，只有服务器有私钥， 所以客户端写的数据只有服务器能看到。
黑客，只能拿到公钥，拿不到私钥，所以就能保证客户端----》服务端的保密性。但是，因为公钥黑客也有，所以黑客也能解密服务器的响应。 所以不能保证服务端 ----》客户端的保密性。
双方都是用非对称加密
服务端有自己的公钥S和私钥S', 客户端拥有公钥C和对应的私钥C'。
然后一开始客户端将C发给服务端，服务端利用C加密，将S发给C此时双方都获得了对方的公钥。
然后双方再进行通信的时候，客户端就对数据使用S进行加密，服务端用S'解密， 服务端用C加密，客户端用C'解密。
但是这样效率太低，并且伴随着一系列安全问题。 安全问题先不说， 我们就把它当成效率太低即可。
混合使用非对称加密和对称加密
服务端有自己的公钥S和私钥S'，客户端有自己的公钥C。 然后客户端就向服务端请求公钥S，然后服务端就发过去了，拿到了公钥S。客户端之后就把公钥C加密，发给服务器，服务器收到了密文数据后，就能用S解密， 解密后就拿到了C公钥。双方以后就能使用C进行通信了。
这种情况下，解决了一直使用非对称加密的效率问题。已经接近完美了，但是还是有一点安全问题， 也就是我们方案三说的安全隐患。
下面我们就来谈一谈这个安全隐患。
MTM
方案2， 3， 4都有一个共性的问题，就是如果在一开始， 中间人就已经开始攻击了呢。
中间人有一种攻击方式叫做MTM：
一开始， 中间人也准备好自己的公钥M， 私钥M'。
一开始客户端向服务器发送请求，然后中间人先什么都不做，当服务器响应一个公钥S的时候，中间人一看是S公钥，就把公钥S替成了自己的M公钥。客户端以为自己拿到的是服务器端公钥。那么他就用这个M对C进行加密。发送给了服务器，中间人截取了密文，就用M'进行解密，解密拿到C。
又用S对C加密发送给了服务端。 这样，客户端以后和服务器交换数据, 服务器使用C加密，客户端使用C加密，数据都经过中间人， 中间人也有C，就能对数据进行随意地查看和更改!!!
上面，整个过程当中问题的本质就是客户端无法辨认服务器发来的公钥是不是合法的。 所以如何验证公钥是合法的，就是解决问题的关键。
引入证书
什么是证书
上面的问题就是无法发辨认服务器发来的公钥是否合法。 所以就有了证书这个东西。 我们先来看一下证书是什么：
有一些权威CA机构可以颁发CA证书。他们要对全球内的各种网站进行CA认证。服务端在使用HTTPS之前，需要向CA机构申请一份数字证书，数字证书里面就包含了证书申请者信息等等。
申请好了之后，当客户端第一次访问服务器， 服务器就把证书传给浏览器，浏览器从证书里面获取公钥就行了。证书就类似于身份证，具有、权威型。
申请证书一般流程
大体流程就是先从服务器端申请证书，然后CA机构进行审核，完成后签发证书。server有了证书就给客户端返回一个证书，客户端就能验证证书并拿到证书里面有用的信息。
申请证书
服务端要先准备好一套非对称密钥对。
然后确认申请者信息（就是确认域名、申请者、公钥等等）
然后生成请求文件， 这个请求文件不包含私钥信息，只包含申请者信息。
审核
CA机构进行审核，就是查看CA证书里面的工资范围了，干什么的，申请人了等等进行审核。
签发证书
认证合规，就签发证书。签发后，这些证书不是挂在墙上的。而是用在网络上面的。
1，2，3步，都是服务端和客户端交互之间要做的，只需要做一次， 然后三年五年都不需要做。
返回证书
服务器将自己的CA证书返回给客户端，客户端就对证书做验证，是合法的，就说明里面的公钥能用，那么双方再进一步进行密钥协商。
我们客户端要认证一个整数是否合法，我们得知道证书里面有什么。
证书分为两部分，第一部分是明文信息，这一部分就是公开的，不加密。这里面有签发机构，有有效日期等等。 最重要的是这个公钥，公钥就是我们申请证书时里面的公钥。 所以，客户端就能拿到公钥，也就能相信这个公钥。
但是，我们怎么知道，这个证书是没有被篡改过的呢?怎么知道它是权威机构的呢? 也就是证书的合法性，我们就需要知道什么是csr文件和这个签名的作用。
csr文件
在我们申请证书的时候， 我们需要把域名申请者，私钥信息一起打个包，生成csr。csr是由特定算法生成的，也可以使用在线生成来生成。
下面是csr生成的网站界面：
数字签名
我们对大文本、小文本进行hash算法形成一个数据摘要，这个摘要是不可逆的，而且是固定长度的。一旦对原始的文件修改，再重新hash，形成新的摘要，就差别特别大。
把数据指纹，数据摘要经过密钥加密，就能得到数字签名。（这里的这个密钥是CA机构的非对称密钥中的私钥）
签名附在原始的明文数据上面，得到的就是带有数字签名的数据。
这个签名的意义就在于下面这一张图：
得到了签名，就用签名和原始明文数据做hash算法，如果两者之中任意一个改了，那么hash出来的数据，就一定不相同。
但是又有另外一个问题， 如果两个都改了呢?
要理解这个，我们就要知道，CA证书的形成过程，其实CA证书也有自己的公钥和私钥 ——和历史我们讲的CS、BS毫无关系。签名的形成，是通过用户提交的数据，用MD5算法形成散列值，再将散列值用CA自己的私钥对我们的签名进行加密。然后再把签名和数据放到一起就形成证书。
证书的签发过程，用的是CA自己的公钥和私钥。
客户端接收到证书后认证过程
当我们以后用户接收到服务端返回来的证书，要进行认证，认证这个证书是否合法(是否被中间人改动了，是否被中间人调包了)首先就要拿到明文数据。 然后再拿到数字签名。 然后对明文数据使用MD5散列， 对数字签名使用公钥解密。 得到两个值， 对这两个值进行对比。 如下图：
这里的公钥是浏览器内部内置的，并且浏览器只认这些内置的CA公钥，其他的服务器发过来的公钥，浏览器一律不认。所以也就说明了浏览器在对证书里面的签名解密的时候，使用的一定是CA钥。这就导致了只有持有CA私钥的CA官方才能进行数据摘要的加密才能颁发证书!!!!
所以，我们就不需要担心中间人对数据和签名的算改，因为他没有CA私钥。更不用担心中间人直接将CA证书调包了。假如中间人自己申请了一个CA证书，直接将服务器返回的CA证书调包也不用担心，因为服务器的域名是唯一的。
并且CA证书里面都有申请人，所以一旦发生调包，看域名就能看出来，而且能够知道申请人是谁，就能从线上案件，转到线下，采用法律来依法处理。
通信过程
所以， 使用证书来双方通信就是这样的：
客户端先向服务端申请证书， 然后服务端返回证书。然后客户端认证， 认证成功过， 使用S加密向服务端发送C公钥。然后服务端就接收到了C公钥了， 以后使用C双方进行通信就可以了。
——————以上就是本节全部内容哦， 如果对友友们有帮助的话可以关注博主， 方便学习更多知识哦！！！