HTTPS和SSL

这里主要是想给大家讲一讲HTTPS中的S到底是什么意思，为什么有了HTTP之后还需要HTTPS呢？SSL究竟是什么？

什么是HTTPS协议

首先在这之前我们是需要理解HTTP协议的，就是超文本传输协议，是客户端浏览器或其他程序与WEB服务器之间的应用层通信协议，那么https=http+secrute(SSL/TSL),就是用于安全的数据传输的HTTP协议.这里我们来看两张图片

我们都知道HTTP是应用层协议哈，这个其实就是在应用层和传输层之间增加了一个安全套接层，你也可以叫它安全层。

那么这个安全机制是什么呢？如何实现的呢？
1）.对称加密：有流式和分组两种，加密和解密使用的密钥相同。典型的算法有：DES、AES-GCM、ChaCha20-Poly1305等。
2）.非对称加密：加密过程和解密过程使用的密钥是不相同的。分为公钥和私钥，公钥和算法都是公开的，私钥是保密的。非对称加密算法的性能较低，但是安全性超强。能加密的数据长度也是有限的。经典的算法有：RSA、DSA、ECDSA、 DH、ECDHE。
3）.哈希算法：将任意长度的信息转换为较短的固定长度的值，通常其长度要比信息小得多，且算法不可逆。经典的算法：MD5、SHA-1、SHA-2、SHA-256
4）.数字签名：就是在信息的后面加上一段内容（经过hash计算之后的内容），可以证明信息没有被修改过。其实我们在很多应用协议开发的时候都会遇见这个数字签名的过程，有兴趣的可以了解一下。

HTTP的弊端

1).我们先来看一下HTTP的交互过程

我们可以使用coolwacther抓取一个HTTP的网络数据包，发现HTTP的数据是裸奔在网络上面的，这可以说是相当的危险了，一些别有用心的人很容易从中间拦截数据，就可以向客户端发送任意数据了.就像下图中这样：

可以看见HTTP的数据在网络中传输还是相当危险的，尤其是一些企业数据和绝密数据，一旦泄露后果还是很严重的。

所以加密传输迫在眉睫，人们渴望一种新的协议出来替代HTTP完成加密通信，HTTPS就此登上了历史舞台。最初由浏览器开发商网景公司主导开发，后来被不断完善，目前已经在谷歌微软的大力倡导之下成为了主流。

对称加密

1）.首先人们最先想到的就是对称加密这种模式，先看一下流程：

对称加密简单来说呢就是使用对称密钥来加密信息，它的数据转换使用一个数学算法和一个私有秘钥。这实际上是一种双向的算法，只要有相同的私钥，就可以通过数学算法还原信息。

目前比较常见和通用的加密算法主要有以下几类：AES，Blowfish，DES，三重DES，Serpent，Twofish
我们通过这张图片来更加直观的感受一下对称加密：

由于对称加密有一个不安全的地方，就是密钥分发 。我们如何保证密钥从A分享到B的过程中密钥不会被窃听到呢，由于这个问题无法解决，所以非对称加密就走上了历史舞台。

总结一下对称加密的缺点：
1） 不同的客户端和服务器的数量比较庞大，需要维护的密钥太多，成本太高。
2） 不同客户端服务器的安全级别不同，密钥容易泄露。

非对称加密

先来看一下大致的交互流程：

它与对称加密最大的区别在哪儿呢？我们可以看见客户端采用公钥加密，而服务器端则采用的是私钥加密。

但是这种方法还是不够完美，为什么呢？交互过程中第四步传输的是什么啊？是私钥加密的数据啊朋友们，私钥加密的数据需要用公钥解密啊，但是公钥这玩意是公开的，好事者一旦在第四步进行拦截，数据是不是又泄露了呢？聪明的人类把对称加密和非对称加密结合在一起，就有了我们现在使用的HTTPS协议啦！

先看一下交互流程：

客户端和服务器在第三次交互的时候，客户端说了一句话：服务器啊，咱们以后的通信都拿对称加密的方式进行吧！说完用公钥把这句话传给了服务器。服务器收到数据后用私钥将数据解密之后明白了客户端的意图，就用对称密钥传输了一句：好的，知道啦！然后就开始正常的数据交互了。这里需要注意啊，服务器端的私钥是我们申请注册之后部署上去的。

到这你是不是觉得就安全了？NO NO NO ! 这还远远不够，现在还是会有两个遗留问题啊：
1）.既然私钥使我们部署上去的，那么客户端我们不知道是谁啊，有可能是任何人，那么他的公钥应该怎么得到呢？
2）.我们在通信的时候怎么确定服务器就是服务器呢？万一有好事者拿到了公钥和私钥冒充服务器我们该怎么办呢？
带着这个问题，SSL就该登上历史舞台了。

SSL

技术背景

SSL即(Secure Socket Layer) 就是我们刚刚在上面说的安全套接字，可以在应用层和传输层之间建立一个安全的数据传输通道，它有网景公司设计开发，依赖于加密算法。
该安全协议的主要作用：
 提供对用户和服务器的认证
 对传输的数据进行加密和隐藏
 确保数据在传输过程中不会被改变

SSL和TLS之间的关系
 1995年，SSL发布了3.0的版本
 1999年，IEFT在SSL3.0的基础上发布了TLS1.0（安全套接层）协议
 2006年，TLS1.1发布，将AES加入到了对称加密算法集当中去了
 2008年，TLS1.2发布，该版本的主要变更：伪随机函数中的MD5-SHA-1组合被SHA-256替代，可以使用密码套件指定的伪随机函数

目前正在投入使用的SSL/TLS的版本信息：
 SSLV3
 TLS1.0
 TLS1.1
 TLS1.2
 TLS1.3(2018年发布)

原理简析

当客户端准备连接到SSL服务器的时候，也需要SSL服务器告诉客户端一个类似于身份证的凭证，这个凭证就是SSL证书，SSL证书包含当前证书的通用名字，国家省份组织信息，联系人邮箱，证书指纹，颁发机构这些信息。

我们看一下百度的证书信息：

具体的信息我们可以选择导出一个文件下来仔细研究。
我们直接通过一张图来感受一下SSL证书验签和数据传输的整个过程：

我们对上面的这个图做一个简单(又不那么简单)的解释：
1).它省略了TCP三次握手的环节，当然我们可以抓取一个wireshark的数据包，可以看见一个client hello的数据包，它包含支持的协议版本/客户端生成的随机数，后续用于生成对话密钥/客户端支持的加密算法/sessionid，用于保持同一个会话（客户端与服务器建立一个https的连接耗费成本较大，建立完就断开的话这太浪费了）

2)服务端收到请求，然后响应（server hello）确认加密通道协议版本/服务端生成的随机数server.random，后续用于生成对话密钥/确认使用的加密算法/服务器证书

3).客户端收到证书后进行验证，验证的具体内容包含：证书是否是上级CA签发的，一般客户端会调用系统的证书管理器接口对证书路径中的所有证书一级一级的验证，只有路径中所有的证书都是可信的，验证结果才会通过。同时，服务器返回的证书中包含证书的有效期，客户端需要验证证书是否过期或者被吊销了。。。。CA证书在签发证书的时候，会使用自己的私钥对证书进行签名，证书里面的签名算法字段SHA256RSA表示CA机构使用了SHA256对证书进行摘要，然后使用RSA算法对摘要进行私钥签名，在RSA算法中使用私钥签名之后，只有公钥才能验签。这个CA机构的公钥一般都内置在操作系统中用于证书的验签。验签之后得知CA机构使用的SHA256进行证书摘要，然后客户再使用SHA256对证书内容进行一次摘要，如果得到的值和服务器返回的证书验签之后的摘要相同，则证书没有被修改过。

4).验签通过之后，客户端生成一个随机数pre-master secret.客户端根据之前的client.random+server.random+pre-master 生成对称密钥然后使用证书中的公钥进行加密，同时利用前面协商好的加密算法，将握手消息取HASH值。然后将“随机数加密”握手消息+握手消息HASH值（签名），然后传递给服务器端。

5).服务器端收到客户端的加密消息以后，用自己的私钥对秘文解密，得到了client.random+server.random+pre-master，再用随机数密码解密握手消息与HASH值与传过来的握手消息进行对比是否一致。然后用随机密码加密一段握手消息给客户端。

6).客户用随机数解密并计算握手消息的HASH，如果与服务器端发过来的HASH一致，那么握手的过程就结束了。之后所有的通信数据将由之前的生成的client.random+server.random+pre-master 通过算法得到sessionkey 作为后续交互过程中的对称密钥。

结语

第一次在C站做分享，写的不好或者不对的地方欢迎大家批评指正。也可以看看阿光的公众号（学习学个der），会不定时的做一些技术积累和分享！ 今天就到这吧！下面是公众号二维码：