文章目录
本篇要总结的内容是关于https协议的相关内容
什么是https协议
在讲述https协议之前，首先要明确的一点是，在应用层中是允许http协议和https协议同时存在的，那对于https的协议理解，我先借助下面这张图来进行描述
在上述图中，下三层表示的是在内核当中的，严格意义来说传输层和网络层是在操作系统的内部，而数据链路层是在网卡驱动层，因此也就比对了对应的网络协议，网络协议栈，操作系统之间的关系，而其中在前面认识到的套接字和系统调用接口，都是可以帮助程序员进行开发
那之前对于http的协议认识来说，用户的数据是会以http请求或相应来作为载体，之后再进行对应的交付信息，但是http的最大问题是，它的传输是明文传输，是不安全的，这也就意味着中间人都能够有资格去获得对应的http协议想要传递的内容，这是不可被接受的，因此基于这样的原因，数据安全的设计者就在此基础上添加了一层软件层，当数据准备交给操作系统之前，要增加一个ssl加密解密层，用来维护这当中的各种信息，那未来这些信息都会用加密的方式来进行传输，最终传输到对方的信息后，再在对方的应用层进行解析，换句话说，只有双方的应用层才能知道传递的是什么信息
所以此时操作系统其实在发送的消息已经变成了一些毫无意义的二进制信息，但是操作系统不关心，它还是会正常的进行信息的传递过程
所以说，其实核心来说，https协议本质上也是一种应用协议，它核心就是在http的基础上新增了一个加密层，而之前的http协议在进行网络传输的时候使用的都是明文传输，有很大的可能会进行所谓的读取抓包篡改的行为，而为了解决这样的问题，其中一种思路就是让双方一个进行加密，一个进行解密，这样就能做到在传递的时候先加密，然后传递到对方手中再进行解密
为了更好的理解这个过程，我这里举一个例子，比如现在进程a向进程b发送了一个信息是10，那现在在进行网络传输的过程中，很有可能这个过程就会被人劫持，劫持之后对应的信息就都会被发现，那为了解决这样的问题，提前进行一个约定，我们约定在进行数据传输之前要对这个数字按位异或上9876这个数字，那么当传输到网络的时候，实际上此时的数字已经变成了一个没有什么意义的数字，而在传递到对方的手中时，再对这个数字继续进行按位异或上9876，那么就能解析出对应的数据信息了，这就是对于https加密的一个基本理解
信息窃取
不管怎么说，只要信息在网络上没有进行加密，就可能会出现被窃取的可能性，我举一个最简单的例子，比如在局域网中，有一个路由器，当用户的网络连接到这个服务器之后，会通过这个服务器进行各种信息的交互，而这些信息是必然要通过这个路由器向外界进行传输，进而传递到基站，然后传递到更远的位置，那这个路由器就有可能会充当一个信息窃取的角色，它可以对于当前用户的信息进行抓包，甚至进行更改用户想要传递的信息，这样就能做到对于信息窃取的功能，这样就更加突出了比如要对于信息进行保护
常见的加密
基于这样的原因，自然就要对于信息做出一些常见的加密，那么从这里开始就要对于信息的加密方式进行一一列举和分析
对称式加密
所谓对称式加密，最大的特点就是加密和解密都用同样的一个数字，就比如刚才的按位异或的方法就是一个最典型的案例，而除此之外这样的加密特点是速度非常快，这也可以理解，毕竟直接进行运算就可以
非对称加密
那除了上面的加密方式外，还有一种是非对称加密，那所谓非对称加密就是说的是加密和解密用的是不同的数据，有两组数据作为中间数据，进行加密和解密的过程，这个和前面的区别是会出现两套不同的密钥，比如对于客户端的加密可以采用的是公钥进行加密，而传递到服务端进行解析采用的是私钥进行解密，这样的方法原理就是非对称加密，那非对称加密的运行特点是速度很慢，但是由于私钥的存在，所以在世界上只有拥有私钥的人才能对于信息进行解密，所以从某种意义来说私钥是相对比较安全的
数据摘要和数据指纹
在了解了上面的概念后，引入的下一个概念是关于数据摘要和数据指纹，所谓数据摘要，就是利用一些哈希函数，对于当前的信息进行一系列复杂的运算，最终运算出的结果可能是一串固定长度的数字摘要，那这个数字摘要就可以被看做是一种数字指纹，这个内容并不是进行加密，而是被用来判断这份数据到底有没有被进行修改，当这份数据被修改过后，它所形成的数据摘要就会截然不同，根据这个原理就可以判断信息是否被修改和截取
那形成信息摘要的方法，就被叫做是摘要算法，一种常见的算法就是md5算法，这个算法就可以把当前的文本生成一个很小的序列，之后对于文本比对就可以转换为对于这个小序列进行比对，如果这个序列被改变了，那么就一定意味着这个文本被改变过
https的工作过程
为了方便于理解https协议，从本小节开始将会对于信息的加密进行一些设计
只使用对称加密
上图所示的内容就是一个基本的原理，服务器和客户端之间使用一个约定了一个密钥进行沟通，就类似于前面的按位异或9876这样的方案，但是这样的方案并不靠谱，因为这个数字随时可能被客户端进行泄漏，这样就会导致密钥失去它的意义
只使用非对称加密
第二种方法是可以使用非对称的加密方式，具体原理可以看做是，服务器先把公钥传输给浏览器，之后浏览器向服务器传输数据之前都使用公钥加密好再传递给服务器，服务器使用私钥解开公钥加密的数据
这样看似乎好像是安全一些，但是问题还是存在的，服务器会传递给一些信息传递给浏览器，浏览器可以使用服务器最开始传递的公钥来进行加密，但是这是有问题的，如果在最开始服务器把信息传递给浏览器之前，公钥就已经被截取了，那么此时服务器向浏览器发送的信息都可以用公钥进行解析，进而被利用
都使用非对称加密
第三种方法是说，服务器有公钥和私钥，客户端也有公钥和私钥，客户端和服务端进行互换公钥：
客户端向服务端发消息，先对信息用s进行加密，然后传递给服务器，服务器用私钥s'来进行解析
服务端向客户端发消息，先对信息用c进行加密，然后传递给客户端，客户端用私钥c'来进行解析
这样的做法看似可以，但是实际依旧有问题，第一个问题是在传输的时候用私钥进行解析的效率太低，同时也有安全问题，我这里给出一种攻破方案：
由此可见，这样的的方案是不好的，既没有解决效率问题，还没有解决传输安全问题
非对称加密+对称加密
这里先解决效率问题：
这样的解决措施可以解决效率问题，但是对于中间人劫持依旧没有解决措施，因此这样的方案还是不能被采用
证书
那为了解决这个问题，因此引入了证书的概念，服务端在使⽤HTTPS前，需要向CA机构申领⼀份数字证书，数字证书⾥含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书⾥获取公钥就⾏了，证书就如⾝份证，证明服务端公钥的权威性
需要注意的是：申请证书的时候，需要在特定平台⽣成查，会同时⽣成⼀对⼉密钥对⼉，即公钥和私钥。这对密钥对⼉就是⽤来在⽹络通信中进⾏明⽂加密以及数字签名的。其中公钥会随着CSR⽂件，⼀起发给CA进⾏权威认证，私钥服务端⾃⼰保留，⽤来后续进⾏通信（其实主要就是⽤来交换对称秘钥）
数据签名
如何理解数据签名？如下图所示
当服务器申请CA证书的时候，就会对这个服务端进行审核，形成对应的数字签名：
- CA有非对称的密钥a和a'
- CA对于服务端的数据进行hash处理，形成数据摘要
- 然后用私钥a'进行加密，形成数字签名s
在未来，验证的方法非常简单，只需要使用公钥a进行验证就可以了，如果这个证书是伪造的，那么通过公钥a解密后一定不可能还原数据，因为最开始是使用密钥a'进行加密的
https方案
所以基于这样的原因，就可以设计出一个非对称加密+对称加密+证书认证的一套逻辑：
在客户端和服务器建立链接的时候，服务器给客户端返回一个证书，其中包含了之前服务端的公钥，也包含了网站的身份信息，客户端就可以进行验证了，判断有效期是否过期，判断证书的发布机构是否受信任，检验证书是否被篡改，这些方法都可以验证这个证书到底是否安全