【Linux篇章】穿越数据迷雾:HTTPS构筑网络安全的量子级护盾,重塑数字信任帝国!

发布于:2025-07-29 ⋅ 阅读:(14) ⋅ 点赞:(0)

本篇摘要

  • 本篇文章将从https是什么,为什么需要https角度,基于之前学的http[速戳速通HTTP]认识https,介绍什么是加密等,认识加密的两种方式:对称加密和非对称加密;引出五种不同的通信方加密方式外加渗透证书相关概念!

在这里插入图片描述

欢迎拜访: 点击进入博主主页

本篇主题: 速通HTTPS基础概念

制作日期: 2025.07.28

隶属专栏: 点击进入所属Linux专栏

一· 认识HTTPS

  • HTTPS 也是一个应用层协议. 是在 HTTP 协议的基础上引入了一个加密层,即可以理解成SSL+TLS+HTTP构成!

二· 为何要加密

在这里插入图片描述

所以:因为 http的内容是明文传输的,明文数据会经过路由器、wifi热点、通信服务运营商、代理服务器等多个物理节点,如果信息在传输过程中被劫持,传输的内容就完全暴露了。劫持者还可以篡改传输的信息且不被双方察觉,这就是中间人攻击,所以我们才需要对信息进行加密。

  • 总之,早期的http在网络中明文传递,是暴露的,能被修改!!!

其中

  • 加密就是把明文(要传输的信息)进行一系列变换,生成密文!
  • 解密就是把密文再进行一系列变换,还原成明文!

在这个加密和解密的过程中,往往需要一个或者多个中间的数据,辅助进行这个过程,这样的数据称为密钥(正确发音yue 四声,不过大家平时都读作yao四声)!

因此

HTTPS 就是在 HTTP 的基础上进行了加密,进一步的来保证用户的信息安全!

三. 加密方式

3.1 对称加密

  • 采用单钥密码系统的加密方法,同一个密钥可以同时用作信息的加密和解密

常见对称加密算法(了解):DES、3DES、AES、TDEA、Blowfish、RC2等
特点:算法公开、计算量小、加密速度快、加密效率高

因此

我们只需要记住:加密秘钥和解密秘钥是同一把,这在某种意义上成为了它的缺点!

  • 一个简单的对称加密:按位异或:

假设明文a= 1234,密钥key = 8888则加密a ^ key得到的密文b 为9834,然后针对密文9834再次进行运算b ^key,得到的就是原来的明文1234.(对于字符串的对称加密也是同理,每一个字符都可以表示成一个数字)当然,按位异或只是最简单的对称加密.HTTPS中并不是使用按位异或.

3.2 非对称加密

  • 需要两个密钥来进行加密和解密,这两个密钥是公开密钥(public key,简称公钥)和私有密钥(private key,简称私钥)。

  • 常见非对称加密算法:RSA,DSA,ECDSA

  • 特点:算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂,而使得加密解密速度没有对称加密解密的速度快。

  • 最大的缺点就是运算速度非常慢,比对称加密要慢很多。

因此

这里只需要记住公钥加密只有私钥解开,私钥加密只有公钥解开!

3.3 数据摘要与数据指纹

  • 数字指纹(数据摘要),其基本原理是利用单向散列函数(Hash函数)对信息进行运算,生成一串固定长度的数字摘要。数字指纹并不是一种加密机制,但可以用来判断数据有没有被篡改

  • 摘要常见算法:有 MD5、SHA1、SHA256、SHA512等,算法把无限的映射成有限,因此可能会有碰撞(两个不同的信息,算出的摘要相同,但是概率非常低)。

  • 摘要特征:和加密算法的区别是,摘要严格意义不是加密,因为没有解密,只不过从摘要很难反推原信息,通常用来进行数据对比,比如数据库管理使用摘要。

四. HTTPS加密方式

4.1 只使用对称加密

也就是我们只使用一把秘钥进行通信

理想
在这里插入图片描述
实际
在这里插入图片描述

  • 这种理想上被中间人截取的也只能是密文,无利用价值,但是服务端和每个客户端都要有个秘钥来维护,这样就比较麻烦,因此一般采取的是先发送秘钥进行协商,但是这样就被中间人获取秘钥了,因此这种方案是不可行的!

因此就导致了这样
在这里插入图片描述

4.2 双方使用一个非对称加密

  • 服务端发送信息前提是先要和浏览器协商(把公钥发给它)然后用私钥加密,给浏览器,这样信息就暴露了(服务器到浏览器的信息暴露),但是浏览器拿到后,进行发送用公钥加密(只能私钥解密),此时无法暴露,服务器就能正常收到信息!

比如
在这里插入图片描述

4.3 双方都使用非对称加密

  • 交换公钥,公钥加密,私钥解密!

在这里插入图片描述

  • 它们俩互相交换了公钥(用于加密),有没有可能中间人也用公钥进行加密然后比如从客户端发给服务端,这样服务端也就分不清了或者中间人用自己的公钥给客户端,然后进行信息窃取!

总结

  • 因为非对称加密:效率低,而且还有安全问题!

4.4 非对称加密+对称加密

  • 也就是服务端先把公钥给客户端,客户端用它进行对称密钥加密然后给服务端(中间人无私钥,无法解密),最后他俩就用这个对称公钥进行加密

过程如图所示
在这里插入图片描述

  • 这样看似是没有毛病的,但是有没有可能中间人把自己的公钥m给client,然后不就得到了这个被m加密的x了,然后再用s进行加密给服务端这个x,之后s与c用x通信不就被中间人掌握了吗!

结局就成了这样

在这里插入图片描述
因此

  • 关键问题还是防止中间人攻击也就是如何确保client收到的公钥来自server而不是中间人呢?

4.5 两次非对称加密与一次对称加密

引入证书

  • 这种方式的前两次非对称加密都是为了保证最后一次对称加密的安全性

  • 证书=签名+明文

CA认证:

服务端在使用 HTTPS 前,需要向 CA 机构申领一份数字证书,数字证书里含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器,浏览器从证书里获取公钥就行了证书就如身份证,证明服务端公钥的权威性!

下面看一下申请证书过程图

在这里插入图片描述
这里需要记住:

  • 签名只有CA机构能做(因为只有它才有对应私钥)。
  • 签名和解签名的秘钥和服务端的秘钥不是同一种
  • CA的私钥由CA使用进行签名,CA的公钥由浏览器自备进行解签名验证
  • 服务端和客户端通信的时候,客户端会先请求,此时服务端就去CA机构申请一个证书,这个证书就是保证client拿到的一定是server的公钥!
证书有没有可能被篡改

那么此时浏览器拿到证书如何核对有没有在server与client传播过程中被中间人修改呢?

CA机构在形成证书的时候会拿着私钥对明文信息散列后的摘要进行加密作为签名!然后当客户端收到证书后会拿着CA公钥对签名解密拿到的数据和明文信息散列后进行对比;如果相同就证明没有被修改,拿着公钥进行传递对称秘钥!!!被修改了就警告! !! —>保证了client一定拿到server的公钥!!!

如图
在这里插入图片描述
但是如果中间人修改server发给client的证书的明文/签名/或者整体替换呢(中间人如果要想成功传递自己的秘钥必须修改签名)?

  • 修改明文:如果修改了的话,当client拿到证书后会发现不匹配的。

  • 修改签名:中间人没有ca的私钥无法对前面修改。

  • 整体替换:这里整体替换就必须要ca的严格审查,中间人只能按照要求申请新的证书,但是还有域名等等一些信息使得客户端可以识别到是不是对应服务端!

中间人动机

  • 要么把明文里的公钥换成自己的。
  • 要么换成自己的后然后改签名让客户能够获取公钥。

但是,均行不通

永远记住:中间人没有CA私钥,所以对任何证书都无法进行合法修改,包括自己的

因此总结
中间人无法修改证书和伪造新的证书!

非对称加密+对称加密+证书认证

因此,它来了

这里可以理解成:

首先进证书申请+客户端验证证书(第一次非对称加密以及解密);接着就是client拿到对应的server的公钥,然后进行传递接下来进行非对称加密的秘钥,服务端然后拿着自己的私钥进行解密拿到(第二次非对称加密以及解密);接着就是用这个非对称秘钥进行通信了(非对称加密及解密)!

也就是这样在这里插入图片描述

  • 注意:这里的易混点是签名和解签名只能用CA的私钥和公钥;而不是服务器的的私钥公钥(过程中服务器会泄露公钥但私钥不会泄露)!! !

下面看张更加详细的图

在这里插入图片描述
详细步骤

  • 第一次非对称加密:用于校验证书是否被篡改.服务器持有私钥(私钥在形成CSR文件与申请证书时获得),客户端持有公钥(操作系统包含了可信任的CA认证机构有哪些,同时持有对应的公钥).服务器在客户端请求时,返回携带签名的证书.客户端通过这个公钥进行证书验证,保证证书的合法性,进一步保证证书中携带的服务端公钥权威性。

  • 第二次非对称加密:用于协商生成对称加密的密钥.客户端用收到的CA证书中的公钥(是可被信任的)给随机生成的对称加密的密钥加密,传输给服务器,服务器通过私钥解密获取到对称加密密钥。

  • 对称加密:客户端和服务器后续传输的数据都通过这个对称密钥加密解密。

超详细大白话叙述过程

首先服务器拿着相关信息(域名,csr,明文信息等),然后生产对应的私钥(自己保存),公钥(交给CA)然后向CA申请证书,ca检查严格审核后,拿着自己的专属私钥进行对明文散列后数据签名,接着交给server,最后server把证书给client,client拿着自己内置信任的CA机构的公钥容纳后进行解密签名看是否合法(明文散列是否相同,域名等是否匹配),不合格就发出警告(上报,或者浏览器阻止用户访问等),合格的话就拿到对应服务器的公钥,自己产生对称秘钥,然后发给服务端(中间人稚嫩获得密文,无法解密),然后服务端解密后,他俩就利用对称秘钥进行通信了!

总结
这一切的目的就是保证这个对称秘钥通信的时候是安全的 !

疑问点
  1. 为什么要进行签名加密
  • 如果不签名的话就是直接证书上的就是明文,那么在客户端核对前是有可能被中间人修改的,因此是不安全的。
  1. 为什么明文不直接加密而是先生成摘要呢
  • 缩小签名密文的长度,加快数字签名的验证签名的运算速度
  1. 如何成为中间人:
  • ARP欺骗:在局域网中,hacker经过收到ARP Request广播包,能够偷听到其它节点的(IP,MAC)地址。例,黑客收到两个主机A,B的地址,告诉B(受害者),自己是A,使得B在发送给A的数据包都被黑客截取。

  • ICMP攻击: 由于ICMP协议中有重定向的报文类型,那么我们就可以伪造一个ICMP信息然后发送给局域网中的客户端,并伪装自己是一个更好的路由通路。从而导致目标所有的上网流量都会发送到我们指定的接口上,达到和ARP欺骗同样的效果。

查看浏览器的受信任证书相关信息

  • 首先点击浏览器对应设置
    在这里插入图片描述
  • 接下来点击安全选项
    在这里插入图片描述
  • 可以看到有很多信任的证书,点击可以看到公钥等信息
    在这里插入图片描述

五. 本篇小结

  • 通过本篇对HTTPS的基础认识,建立了大致的了解,知道了它背后的原理等,此次学习虽然是大致的,但是也看到了HTTPS背后的基本原理,为以后对它更加深入的学习奠定了基础,冲冲冲!

请记住:

今日的懒惰成就明日的堕落!


网站公告

今日签到

点亮在社区的每一天
去签到