您现在的位置是:首页 >学无止境 >https通信加密原理网站首页学无止境

https通信加密原理

baby加油_ 2024-08-29 12:01:03
简介https通信加密原理

为什么要用https

HTTP 由于是超文本传输协议,是一个简单的请求-响应协议,它通常运行在TCP之上,它是明文传输,不能保证数据的完整性,不能保证是否被窃听,不能保证数据是否被篡改

https采用了一些加解密,数字证书,数字签名的技术保证了通信的安全,一般我们认为安全的通信需要包括以下四个原则::机密性、完整性,身份认证和不可否认。

  • 机密性:即对数据加密,解决了窃听风险,因为即使被中间人窃听,由于数据是加密的,他也拿不到明文;
  • 完整性:指数据在传输过程中没有被篡改,如果修改,接收方也能识别出来,从来判定接收报文不合法;
  • 身份认证:确认对方的真实身份,这样就解决了冒充风险,用户不用担心访问的是某宝结果却在和钓鱼网站通信的问题;
  • 不可否认: 即不可否认已发生的行为,比如小明向小红借了 1000 元,但没打借条,或者打了借条但没有签名,就会造成小红的资金损失。

HTTPS 通信原理简述

首先要了解有哪些加密算法,都有哪些特点

  1. 对称加密算法
    加解密都用的同一个秘钥,用同一个秘钥加密,同一个秘钥解密
    加解密速度快
    适合加密大量数据
    常用的对称加密算法有 AES、DES、3DES、RC4、SM4 等。
  2. 非对称加密算法
    有一对秘钥,公钥和私钥,公钥加密私钥解密,私钥加密公钥解密
    (注:私钥加密其实这个说法其实并不严谨,准确的说私钥加密应该叫私钥签名。因为私密加密的信息公钥是可以解密的,而公钥是公开的,任何人都可以拿到,用公钥解密叫做验签。)
    加密算法复杂,加密速度慢
    比较安全
    常用的非对称加密算法有RSA、DSA、SM2
  3. 哈希算法,也叫散列算法,也叫摘要算法
    不可逆,只能加密,无法解密
    哈希函数输出长度必须是固定的,并且与输入长度无关
    一般用来验证数据的完整性
    常用的哈希算法有SM3,、md5、SHA1、SHA256

实现对称加密,需要三项,确定对称加密算法,生成对称秘钥(一个随机数,一般一次一秘,每一次的通信都会重新生成),明文
实现非对称加密,也需要三项,确定非对称加密算法,公钥(一般一个网站有一组公私钥对),明文
实现哈希算法,需要两项,确定哈希算法,明文,生成固定长度密文

对称加密报文

既然 HTTP 是明文传输的,那我们给报文加密不就行了,对称加密有具有加解密速度快,性能高的特点,也是 HTTPS 最终采用的加密形式。 所以使用对称加密的方式来给报文进行加解密。
但是这里有一个关键问题:对称加密的通信双方要使用同一把密钥,这个密钥是如何协商出来的?如果通过报文的方式直接传输密钥,之后的通信其实还是在裸奔,因为这个密钥会被中间人截获甚至替换掉,这样中间人就可以用截获的密钥解密报文,甚至替换掉密钥以达到篡改报文的目的。

非对称加密结合对称加密算法

这个时候就用到了非对称算法,解决单向对称密钥的传输问题 公钥加密只能私钥解密,而私钥只有服务器有,不在中间传输。用非对称算法的公钥加密对称秘钥,用对称秘钥加密报文,服务器端先用私钥解密出对称秘钥,再解密出报文,这样就实现了加密传输的安全。

但是问题又来了, server 怎么把公钥安全地传输给 client 呢。如果直接传公钥,也会存在被中间人调包的风险。这个时候就用到了数字证书,解决公钥传输信任问题

数字证书

服务器得去公证人这里先登记,把服务器的公钥、网站域名等等信息报上去,公证人拿到这些信息后,计算一个 Hash 值,然后再用公证人的 私钥 把Hash值进行加密,加密后的结果就是 数字签名。最后,公证人把登记的信息和这个数字签名合在一起,封装了一个新的文件发给服务器,登记就完成了,而这个新的文件就是数字证书

服务器拿到证书后,可要好生保管,因为通信的时候,服务器须要将他们的证书发给我们浏览器验证。我们浏览器拿到证书后,把证书里面的信息也计算一遍Hash,再用提前记录好的 公证人的公钥 把证书里的数字签名进行解密,得到公证人计算的Hash,两个一对比,就知道这证书是不是公证人签发的,以及有没有被篡改过了!只有验证成功才能继续后面的流程,要不然就是冒充的!

由于只有 CA 的公钥才能解密签名,如果客户端收到一个假的证书,使用 CA 的公钥是无法解密的,如果客户端收到了真的证书,但证书上的内容被篡改了,摘要比对不成功的话,客户端也会认定此证书非法。如果中间人也向CA申请了证书,劫持客户端的请求,返回自己的证书,也是行不通的,因为客户端会验证网站域名等信息,这一下总算解决了中间人冒充的问题。

抓包

charles 这些中间人为啥能抓到明文的包呢?其实就是用了证书调包这一手法,想想看,在用 charles 抓 HTTPS 的包之前我们先要做什么,当然是安装 charles 的证书。
这个证书里有 charles 的公钥,这样的话 charles 就可以将 server 传给 client 的证书调包成自己的证书,client 拿到后就可以用你安装的 charles 证书来验签等,验证通过之后就会用 charles 证书中的公钥来加密对称密钥了。整个流程如下:

在这里插入图片描述
由此可知,charles 这些中间人能抓取 HTTPS 包的前提是信任它们的 CA 证书,然后就可以通过替换证书的方式进行瞒天过海,所以我们千万不要随便信任第三方的证书,避免安全风险。

证书链

我们可以向 CA 申请证书,但全世界的顶级 CA(Root CA) 就那么几个,每天都有很多人要向它申请证书,它也忙不过来。这个时候用到了证书链,它会授权下一级,下下级 ,这样我们就只要找一级/二级/三级 CA 申请证书即可。怎么证明这些证书被 Root CA 授权过了呢,小一点的 CA 可以让大一点的 CA 来签名认证。比如一级 CA 让 Root CA 来签名认证,二级 CA 让一级 CA 来签名认证,Root CA 没有人给他签名认证,只能自己证明自己了,这个证书就叫「自签名证书」或者「根证书」,我们必须信任它,不然证书信任链是走不下去的(这个根证书其实是内置在操作系统中的,在浏览器中可以看到根证书和中间证书和SSL证书,及证书链)
现在我们看看如果站点申请的是二级 CA 颁发的证书,client 收到之后会如何验证这个证书呢,实际上 service 传了传给二级 CA 的证书外,还会把证书信任链也一起传给客户端,这样客户端会按如下步骤进行验证:

  1. 浏览器就使用信任的根证书(根公钥)解析证书链的根证书得到一级证书的公钥+摘要验签;
  2. 拿一级证书的公钥解密一级证书,拿到二级证书的公钥和摘要验签;
  3. 再然后拿二级证书的公钥解密 server 传过来的二级证书,得到服务器的公钥和摘要验签,验证过程就结束了。

HTTPS 通信过程

发起请求、验证身份、协商秘钥、加密会话

一、 客户端向服务端发起ssl请求

  1. 告诉服务器自己支持哪些加密算法
  2. 客户端生成随机数R1发送给服务端

二、 服务端向客户端发送数字证书(ssl证书)

  1. 服务端生成随机数R2
  2. 选择一种双方都支持的加密算法
  3. 服务端把证书、公钥、随机数R2、会话密钥生成算法,一同发给客户端

三、 客户端验证数字证书

  1. 验证数字证书的有效性,首先验证数字证书上的CA证书的根证书是否存在,再使用CA根证书的公钥解密证书签名数据,得到CA机构计算的摘要。然后通过证书里提供的摘要算法对数据(证书中的相关的明文信息)采用相同的散列函数(Hash算法)计算得到信息摘要,然后通过自己生成的摘要与CA机构的摘要比对。如果一致,则可以确认证书的合法性,即公钥合法
  2. 验证证书合法性,包括证书是否吊销、是否到期、域名是否匹配,通过后则进行后面的流程
  3. 获得证书的公钥、会话密钥生成算法、随机数R2
  4. 生成一个随机数R3(预主密钥)。
  5. 根据会话密钥算法使用R1、R2,和预主密钥R3生成会话密钥;
  6. 用服务端证书的公钥加密随机数R3并发送给服务端。

四、 服务器得到会话密钥

  1. 服务器用私钥解密客户端发过来的随机数R3
  2. 根据会话秘钥算法使用R1、R2,和预主密钥R3生成会话密钥;

五、 客户端与服务端开始进行加密会话

  1. 客户端发送加密数据给服务端
  2. 服务端响应客户端( 解密接收数据:服务端用会话密钥解密客户端发送的数据; 加密响应数据:用会话密钥把响应的数据加密发送给客户端。)
  3. 客户端用会话密钥解密服务端响应的数据

六、 客户端与服务端开始进行加密会话

在这里插入图片描述

风语者!平时喜欢研究各种技术,目前在从事后端开发工作,热爱生活、热爱工作。