[网络协议] 为什么要用https协议

开发: C++知识库 Java知识库 JavaScript Python PHP知识库人工智能区块链大数据移动开发嵌入式开发工具数据结构与算法开发测试游戏开发网络协议系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑笔记本显卡显示器固态硬盘硬盘耳机手机 iphone vivo oppo 小米华为单反装机图拉丁

-> 网络协议 -> 为什么要用https协议 -> 正文阅读

[网络协议]为什么要用https协议

文章目录

前言

在C-S架构或者 B-S架构中，我们通信双方的报文如果采用http协议进行传输，通常涉及到保密性的问题，保密性是什么意思呢？即双方通信的报文如果被第三方捕获是否可以解析，如下进行演示(非原理篇):

准备工作

1.加密算法

非对称加密算法：RSA，DSA/DSS
公钥加密私钥解密, 私钥加密公钥解密
对称加密算法：AES，RC4，3DES
公共key加密，公共key解密
HASH算法：MD5，SHA1，SHA256
无法解密

2.文章关键字备注

角色

角色说明
Client 客户端
中间人黑客程序
Server 服务端
CA 第三方电子认证

密钥

密钥	说明
C_key	Client的对称加密key
B_key	中间人的对称加密key
S_key	Server的对称加密key
B_Public_Key	中间人公钥
B_Private_Key	中间人密钥
S_Public_Key	Server公钥
S_Private_Key	Server密钥
CA_public_Key	CA公钥
CA_Private_Key	CA密钥

其他

名称说明
certificate 许可证

通信方式

1. 明文传输

不安全, 随便抓到一个报文都可以解析

2.对称加密 (同一个密钥)

首先Server不可能给每一个Client都配不同的key, 这样服务端负载过重, 所以通用key用于所有Client
Server给每个Client发一个S_key，拿到key就可以解析报文，所以中间人也能拿到这个S_key

Client Server S_key 对称加密传输可能中间人攻击 S_key 对称加密传输 Client Server

3.非对称加密(密钥对)

Server端的密钥对(S_Public_Key, S_Private_Key), Server端S_Private_Key加密解密, Client端S_Public_Key加密解密, 中间人依然可以模仿Client获取到S_Public_Key，所以服务端到客户端这一步中间人依然可以拦截解析

Client Server Client索要S_Public_Key 返回S_Public_Key S_Public_Key非对称加密传输数据 S_Private_Key解密 S_Private_Key加密非对称加密传输可能中间人攻击 S_Public_Key解密 Client Server

4.混合加密(对称加密+非对称加密)

原理
1. 对称加密-如果每个Client都有一个key, 那可以防止中间人攻击, 但是Server不可能去保存这个key；
2. 非对称加密-只有服务端发送数据到客户端这一步才可能被冒充Client的中间人伪装解密；
3. 可以把这个key保留到客户端即C_key, 通过非对称加密Client->Server来告知Server这一C_key
流程

Client Server Client端指定C_key 索要S_Public_Key 返回S_Public_Key S_Public_Key非对称加密 C_key 传输数据给Server端 S_Private_Key解密, 获得客户端 C_key C_key对称加密通信 C_key对称加密通信 Client Server
思考
至此,在密码学的角度来说，貌似已经非常安全了，万无一失，但是-没有绝对安全的系统，如果中间人一开始在Client索取公钥时就介入呢？即中间人既冒充Client也冒充Server
中间人攻击

Client(C) 中间人(B) Server(S) Client端指定C_key 索要B_Public_Key 返回B_Public_Key B_Public_Key非对称加密 C_key 传输数据给Server端 B_Private_Key解密, 获得Client端 C_key 中间人指定B_key 索要S_Public_Key 返回S_Public_Key S_Public_Key非对称加密 B_key 传输数据给Server端 S_Private_Key解密, 获得中间人B_key 之后的通信可能如下 Client端 C_key 对称加密报文通信中间人 C_key 解密报文中间人拿着解密后的报文 B_key 对称加密报通信 Server端 B_key解密报文 Server端 B_key 对称加密返回中间人中间人 B_key 解密中间人伪造报文 C_key 加密返回Client端 Client(C) 中间人(B) Server(S)

如何解决中间人问题？
在这个过程中最大的问题就是中间人可以冒充Server端的密钥对, 然后捕获信息再冒充Client去和Server交互，有什么办法能让避免这个局面么？引入第三方CA(权威机构)由CA签发数字认证。看下节

5.https

原理
1.CA有自己的公钥和私钥分别为 CA_public_Key、CA_Private_Key
2.CA对Server端的 S_Private_Key 用CA_Private_Key进行加密生成 certificate
3.Client端请求Server端的 S_Public_Key前先获取 licence,然后用 CA_public_Key对 certificate进行解密，获取到Server端的 S_Public_Key
后面的步骤就跟第4节一致了
粗略流程

Client Serve CA_Private_Key加密S_Public_Key 生成 certificate Client端指定C_key 获取 certificate 返回 certificate CA_Public_Key 验证 certificate，并获取到Server的S_Public_Key S_Public_Key非对称加密 C_key 传输数据给Server端 S_Private_Key解密, 获得客户端 C_key C_key对称加密通信 C_key对称加密通信 Client Serve
中间人攻击
可以说只要有经过网络获取公钥的过程，就存在中间人攻击的可能,那么为避免中间人攻击，CA证书一般是写死到操作系统的；
安全了么(纯纯的智商考验啊)？
其实在Server返回的certificate时候，如果中间人干预，那中间人用CA_Public_Key 解析certificate，并获取到Server的S_Public_Key，并篡改certificate，用自己的 B_Public_Key替换Server的S_Publick_Key 那还是会中招啊…
怎么办怎么办，无解了么？
数字摘要+数字签名
首先CA对certificate进行散列算法计算,如 HASH算法，计算出一份数字摘要,这个数字摘要是不可逆的唯一标识，然后再用CA_Private_Key进行签名生成一份数字签名到certificate,Client在拿到certificate之后，首先用CA_Public_Key解析数字签名。用解析到的数字摘要验证certificate正确性，防止篡改！ beautiful!!! nice !!!