C/C++ Linux网络编程11 - 数据加密与https协议

上篇文章:C/C++ Linux网络编程10 - http协议-CSDN博客

代码仓库:橘子真甜 (yzc-YZC) - Gitee.com

http协议传输数据是直接明文传输,如果有人想要攻击/盗取服务器-客户端的数据是很容易的。为了保护传输过程中的数据安全,我们需要使用https协议。

目录

[一. HTTPS协议安全原理](#一. HTTPS协议安全原理)

[1.1 加密与解密](#1.1 加密与解密)

[1.2 加密方式](#1.2 加密方式)

[a 对称加密](#a 对称加密)

[b 非对称加密](#b 非对称加密)

[1.3 数据摘要/数据指纹](#1.3 数据摘要/数据指纹)

[1.4 数据签名](#1.4 数据签名)

[二. HTTPS加密方案](#二. HTTPS加密方案)

[2.1 仅用对称加密](#2.1 仅用对称加密)

[2.2 仅用非对称加密](#2.2 仅用非对称加密)

[2.3 双方非对称加密](#2.3 双方非对称加密)

[2.4 对称加密+非对称加密](#2.4 对称加密+非对称加密)

[三. HTTPS工作原理](#三. HTTPS工作原理)

[3.1 CA证书与HTTPS加密流程](#3.1 CA证书与HTTPS加密流程)


一. HTTPS协议安全原理

1.1 加密与解密

https在http传输数据的基础上,添加了一层加密层。简单来说就是,发送方使用密钥对发送的数据进行加密,接收方使用密钥对数据进行解密。这种密文的解密是几乎不可能的或者需要非常长的时间进行解密。

只要攻击者拿不到双方的密钥,即便拿到了密文,也没有什么用。

中间人如何获取我们的http协议的内容?

很简单,比如我们手机连接了某一个陌生网络(比如校园网,个人WIFI等)。只要我们通过这个网络访问其他服务器,陌生网络的所有者就有可能通过抓包工具获取我们的数据。

1.2 加密方式

a 对称加密

对称加密:使用同一个密钥对数据加密解密。P(明文) -> 密文 P(密文) -> 明文

加密方使用密钥P将明文加密为密文,解密方使用密钥P将密文解密为明文。

对称加密的特点是:算法小,速度快,消耗低。不过只要密钥丢失,双方数据都能破解

b 非对称加密

非对称加密:拥有公钥public_key和私钥private_key。这里简称p p'。

公钥和私钥都能将明文加密为密文。

使用公钥P加密的密文只能使用私钥P'进行解密

使用私钥P'加密的密文只能使用公钥P进行解密

非对称加密一般使用认证,签名。验证信息真正来自私钥。

非对称加密的特点是:算法复杂,速度较慢。不过丢失公钥,不影响我使用公钥加密。丢失私钥,不影响我使用私钥加密。即便某一个密钥被盗取了,无法破解这个密钥加密的数据

1.3 数据摘要/数据指纹

数据摘要是通过哈希算法将数据变为一段字符串,这个字符串是唯一的。所以数据摘要是具有唯一性的。

使用数据 + 数据指纹一起就能验证这个数据的唯一性。

比如我们收到对方的数据 + 数据指纹。首先使用哈希算法对数据转换为字符串摘要,然后对比摘要和数据指纹。二者相等说明这个数据 和 数据指纹是正确的。

如果数据或者指纹一方被更改,对比就会错误。表示这个数据被篡改了。

当然如果数据和数据指纹都被修改了就无法识别了

1.4 数据签名

对数据摘要进行加密,结果就是数据签名。将数据和数据签名发送给对方,只要攻击者拿不到我们的密钥,就能一定保证数据的安全。

为什么?

单独数据+数据指纹有二者都被替换的情况。如果使用数据签名替换数据指纹,如果攻击者替换了整个数据。这个数据是错误的,因为攻击者并没有密钥,它如何进行加密?只要接收方使用密钥进行解密一下就能发现这段数据的乱序或者无法解密的

二. HTTPS加密方案

2.1 仅用对称加密

服务端通过密钥加密将密文传递给客户端,客户端解密后获取明文。客户端通过密钥加密将密文传递给服服务端,服务端使用密钥破解获取明文。

这种方式貌似非常好,问题是双方如何约定密钥?无论是谁生成密钥总要让对方知道吧?如何保证密钥的保护呢?再生成一个对称密钥保护密钥,那密钥的密钥如何保护呢?明显不行

所以在正常传输数据之前,先要保证对方安全接收到我们密钥

2.2 仅用非对称加密

一方生成公钥P和私钥P',将公钥发送给对方。我方使用私钥加密,对方使用公钥加密。

这种方法也是不行的,因为公钥被暴露,直接能够获取私钥加密的密文。

2.3 双方非对称加密

通信双方都产生一对密钥,客户端:C与C' 服务端:S S' 然后将自己的公钥发送给对方,这样一来客户端有服务端的公钥S,服务端有客户端的公钥C

通信的时候,客户端使用S加密,只有服务端才能使用S'解密。同理,服务端发送的响应通过C加密,只有客户端拥有C'进行解密

这种方式貌似不会出错,不过如果中间篡改了公钥呢?比如中间人生成公钥P,私钥P'使用P替换客户端的公钥C呢?

并且非对称加密的加密解密速度太慢了。

2.4 对称加密+非对称加密

这种方式能有效解决非对称加密速度的问题。

1 服务端生成非对称公钥S和私钥S'。然后将公钥发送给客户端。

2 客户端生成对称加密密钥P使用公钥S加密然后发送给服务端。

3 服务端使用私钥S' 拿到对称密钥P,之后双方通过密钥P发送数据。

这种方式由于攻击者没有私钥,无法获取我们的对称密钥P。就能保证双方进行安全的通信,并且密钥使用的对称密钥P,速度快。

接下来的问题是如何解决客户端收到的公钥S是合法的?即解决中间替换公钥S的问题。

三. HTTPS工作原理

对称加密+非对称加密的方式已经非常完美了,仅需要解决验证公钥S合法问题。

3.1 CA证书与HTTPS加密流程

CA证书是由合法的机构颁发的。客户端只要验证证书是否正确就能保证服务器发送的私钥S是合法的。

原理如下:

1 服务端生成公钥S和私钥S',然后将公钥S发送给CA机构生成证书

2 CA机构有自己的公钥CA和私钥CA'。

CA首先对服务端信息(包含公钥S和服务器域名等信息)和自己的信息组合为数据A进行整理并生成一份数据摘要B。并使用私钥CA'加密数据摘要数据签名C。

然后将数据A和签名B以及自己的公钥CA发送给客户端。

3 客户端拿到证书后,首先对证书进行认证。使用CA解密数据签名C获取数据摘要D,然后使用哈希算法对数据A处理获取数据摘要D'。对比D和D'的合法性来保证。

4 如果合法,直接使用证书中的服务端公钥S生成加密的对称密钥P并发送给服务端。之后双方使用对称密钥P进行通信。

这样一来就保证了服务端公钥S被篡改的问题。

分析一下证书被篡改的问题

1 攻击者只篡改证书中的公钥S,这样会导致客户端生成的摘要D'无法对比上CA公钥解密后的D。

2 攻击者使用CA公钥篡改证书中的签名C,同理无法比对D和D'

3 攻击者同时篡改证书数据和签名(即替换假的证书)。由于攻击者无法拿取CA机构的私钥CA', 客户端使用CA解密就可以发现这个签名有问题(无法解密或者解密的数据是随机的乱码)。

HTTPS的加密过程大概就是如此,保证了服务端-客户端之间的通信安全。

相关推荐
知识分享小能手2 小时前
CentOS Stream 9入门学习教程,从入门到精通,CentOS Stream 9 配置网络功能 —语法详解与实战案例(10)
网络·学习·centos
码农12138号2 小时前
Bugku HackINI 2022 Whois 详解
linux·web安全·ctf·命令执行·bugku·换行符
Joren的学习记录2 小时前
【Linux运维进阶知识】Nginx负载均衡
linux·运维·nginx
用户2190326527352 小时前
Java后端必须的Docker 部署 Redis 集群完整指南
linux·后端
专业开发者2 小时前
Wi-Fi®:可持续的优选连接方案
网络·物联网
胡先生不姓胡2 小时前
如何获取跨系统调用的函数调用栈
linux
GIS数据转换器3 小时前
综合安防数智管理平台
大数据·网络·人工智能·安全·无人机
Jtti3 小时前
服务器防御SYN Flood攻击的方法
运维·服务器
一点晖光4 小时前
搭建内网穿透的ngrok服务器
服务器·内网穿透·ngrok
里纽斯4 小时前
RK平台Watchdog硬件看门狗验证
android·linux·rk3588·watchdog·看门狗·rk平台·wtd