HTTPS协议

伴随用户的安全意识增强，网络协议也开始向Https过度，目前大多数的网站与APP都是使用的Https协议

HTTP协议

在我之前的博客中由写过http的几种协议的比较，这里就简单介绍一下

HTTP协议的缺点：

  • 通信使用明文
  • 不会对通信方的身份进行验证
  • 无法验证报文的完整性

通信使用明文

也就是说在HTTP协议中所有的数据传输都是在明文情况下进行的，也就导致了如果通信被窃听，窃听者根本无需花费任何成本就能直接查看到我们传输的数据详细内容

不验证通信方身份

不验证通信方的身份会导致通信过程被窃听后，可能遭遇伪装，并且攻击者可以使用伪装身份与己方机型通信

法验证报文的完整性

无法验证报文的完整性，也就意味着数据在传输过程中可能被修改，也就造成了数据的不真实

解决方法

对于明文传输的问题，我们可以使用密文进行传输，这样即使数据被窃听，攻击者依旧需要耗费大量的时间与精力来进行破解，间接提升了数据的安全性

要想对通信方的身份进行验证，我们可以使用与后端相同的方式，在网络数据参数中生成一个token，请求与应答时都通过token来进行身份的验证

验证报文完整性的方法就是使用MD5/SHA1等算法进行完整性验证，对方使用相同的算法生成散列值，通过对比散列值，即可验证数据的完整性

为了解决以上的问题，HTTPS协议就诞生了：

1
https = http + 加密 + 认证 + 完整性验证

加密、认证和完整性验证，这些特点TCP/IP中已经提供了一个用于数据安全传输的协议，即SSL协议（Secure Socket Layer）安全套接层，虽然是基于TCP实现的，但是它并不是应用层的协议，他是位于应用层与传输层之间的协议，其存在的目的就是为上层的应用层协议提供安全的传输通道

因此HTTPS的构成也就变成了

1
Https = Http + SSL

因此所谓的https报文也就是SSL的报文

SSL协议

SSL安全套接层，是一种位于应用层与传输层之间，为网络通信提供安全以及完整性验证的一种网络协议

相对于TCP与HTTP协议，SSL协议要更加复杂，由于建立在TCP协议之上，所以在使用SSL协议之前需要进TCP协议的三次握手来与服务器建立连接，然后再进行SSL的握手

SSL握手

根据上述图片可知，SSL握手阶段如下：

  1. 客户端先向服务端发送一个消息，内容包括：客户端支持的加密方式、客户端支持的压缩方法、SSL的版本号、客户端生成的随机数，以及文本内容等
  2. 服务器接收消息后回发一个文本消息，并携带从客户端支持的加密方式中选择的加密方式，服务端生成的随机数。服务端的SSL版本号等
  3. 随后服务端会给客户端发送一个Certificate（证书）报文，其中包含服务端的公钥证书
  4. 紧接着服务端向客户端发送Server Hello Done，表示最初的协商握手过程结束
  5. 客户端接收到握手结束的消息后，以Client Key Exchange作为回应。此报文中包含通信加密过程中使用的一种被称为Pre-master secret的随机密码串，并使用第三步接收到的公钥证书进行了加密
  6. 接着客户端会发送Client Cipher Spec报文，该报文会告知服务端，在此步骤之后数据将使用第五步中生成的master secret进行加密
  7. 随后客户端会发送Finish报文。此报文会包含连接至今所有报文的整体校验值，以供完整性校验
  8. 服务端接收到客户端发送的Change Cipher Spec报文后，同样以Change Cipher Spec报文作为回应
  9. 接着服务端发送Finish报文给客户端，表示服务端已正确解析客户端发送的整体校验值，至此，SSL握手的过程结束。
  10. 随后开始使用http协议传输使用master secret加密过的数据

描述过程

  1. 前面两个步骤的作用是协商加密算法以及传输各自生成的随机数（为后续的master secret做准备）的过程
  2. 第三步是服务端将自己的证书发送给客户端，这个证书中包含一个数字签名（CA签名）和服务端CA证书的公钥，客户端对证书中包含的服务端信息进行Hash，同时使用接收到的公钥对数字证书进行解密，获取其中的Hash值，与前面计算出的Hash值进行对比。即可验证证书的有效性（完整性&真实性）
  3. 服务端收到客户端发送的Change Cipher Spec（第五步），会使用自己的私钥进行解密，获取报文中的Pre-master secret，这时通信双方都拥有对方的Random（前两步生成的随机码），Pre-master secret，以及自身的Random，将三个数作为种子通过算法生成master secret，用来加密后续Http请求过程中的数据

密钥

在我们对信息进行加密的时候，会分为两个类别，一类是对称加密，二另一类是非对称加密

  • 对称加密： 即双方使用约定好的解密/加密方式进行加密，双方方式一致，即为对称加密，对称加密是很早提出来的方式，而现在在数据传输中面临的问题是我们如何将密钥发送给对方，在密钥的传输过程中很容易就会被黑客截获密钥，此时我们传输的密文信息也就是形同虚设
  • 非对称加密： 非对称加密是为了解决对称加密的密钥易被截获的缺点而提出来的方案，当A和B进行数据传输时，A通过非对称加密生成两个密钥，一个用于加密的公钥，一个用于解密的私钥，A在传输时将公钥交给了B，B在数据传输时使用公钥加密而A使用密钥解密，这样就形成了非对称加密，也就是说哪怕黑客截取了公钥与信息页无从得知具体的信息内容。

但是事实上非对称加密的速度要慢于对称加密，因此我们一般都是用非对称加密的方式传输对称加密中生成的密钥

在上面的介绍中其实页存在两个问题：

  • 怎样保证A给B的公钥是正确的，即公钥没有被黑客篡改？
  • 怎样保证A收到B的信息是正确的？

对于第二个问题在网络中我们一般使用了第三方公证处的方法，A生成公钥以后不仅交给B一份，也会在第三方公证处进行一次认证，将公钥交给第三方，B拿到公钥后去公证处认证对比一次就会知道公钥的对错，但是这样就形成了一个新的问题：如果去第三方认证时被黑客拦截了，去假的公证处拿到一个假的密钥怎么办？

对这个问题涉及到以下几点：

  • 摘要算法（MD5）
  • 数字证书与数字签名
  • 自签名证书与跟证书
  • 证书链

证书链与摘要算法

根据非对称加密算法，公钥加密的数据只能使用私钥进行解密，相反的私钥加密的数据也就只能使用公钥进行解密。

所有的操作系统在出厂时都会安装一个根证书，我们可以先忽略证书的意义，值知道里面存放有公钥，这个我们可以认为是最顶级的机构 （CA Certificate Authority, 证书认证机构） 的公钥。

当服务端想要提价自己的公钥时，就会去计算机中证书的发放机构进行认证，这时机构会将服务端的公钥以及证书信息（颁发者时间等）生成摘要，然后再用根证书对应机构的密钥加密这段摘要，这个操作也就是数字签名，然后回返回一个证书给服务端，随后服务端将这个证书给浏览器，浏览器使用公钥解密后可以得到服务器的公钥、证书的数字签名、签名的计算方法，重新对签名进行计算后对比就可以知道证书有没有被修改过，也就保证了通信安全

当然不可能我们每一次都要直接请求根证书的发放机构，这种情况下就产生了一级CA、二级CA等，这些CA本身就是通过了根证书CA的认证，他们也拥有自己的密钥，根证书的CA也给他发放了一个证书，包含了根证书机构对应的信息，并使用私钥完成了数字签名，而一级CA发放给服务端的证书里面也包含有这一份证书，浏览器接收证书后，判断这是否是一个一级证书，使用根证书的公钥对一级证书的摘要进行解密对比，就可以验证一级证书的有效性，随后获得一级证书的公钥对服务器信息的摘要进行解密对比，验证服务器信息的有效性，以此类推到二级、三级证书，也就形成了证书链。

简述通信过程

其实详细的通信过程就是上面SSL的通信过程，这里使用简短的概括说一下加入证书后的HTTPS通信

  1. 服务端向CA机构申请数字证书，里面包含有自己的公钥以及证书链
  2. 服务端将自己的证书交给浏览器
  3. 浏览器对证书链进行层层验证，最终获得服务端的公钥
  4. 浏览器生成对称加密算法的密钥，并通过服务端公钥加密后发送给服务端
  5. 服务端使用私钥解析后获得对称加密的密钥
  6. 浏览器与服务器开始使用密钥进行通信

总结

HTTPS的过程基本就如上面所述，HTTPS协议对于前端来说是一个非常重要的概念，这里阐述的可能也并不详细，参考了一些掘金的文章

希望这些对读者了解HTTPS能够有所帮助！