一篇一看就懂的Https的实现过程梳理

结合最近做支付遇到的一些问题,以及查阅的一些资料,整理了一下https的安全实现;希望多家多多支持!
1.Https的产生背景:
我们最开始用的较多的是HTTP协议用于数据传输,但是http数据是明文传输,这对于比如支付、转账等场景是不安全的,
很容易被第三方窃取并篡改参数信息,造成无法挽回的损失.
 
2.Https与http的不同
Https与http最的不同是把下层的协议由 TCP/IP 换成了 SSL/TLS(TLS可以理解为SSL的前身),而SSL/TLS 是信息安全领域中的权威标准,
采用多种先进的加密技术保证通信安全;OpenSSL 是著名的开源密码学工具包,是 SSL/TLS 的具体实现;

一篇一看就懂的Https的实现过程梳理

文章插图
 
3.Https特性及其关键词介绍
特性:
机密性、完整性、身份认证、不可否认; 通常实现了这四个特性,我们就基本可以保证数据传输是‘安全’的了;
机密性:指的是传输的信息不能随意给某人看,只有可信任的人能看到;
完整性:指的是服务器接收到你传输的数据是没有被修改过的,比如去掉了数据的某些部分;
身份认证:指的是发送数据的客户端怎么证明我就是我,不一样的花朵,让接收方(服务器)可以识别你的身份;
不可否认:也是就你发出的数据无法抵赖;
关键词:
对称加密、非对称加密、摘要、数字签名、数字证书
对称加密:也就是加密和解密用的是同一个秘钥,常见对称加密算法:AES、ChaCha20
一篇一看就懂的Https的实现过程梳理

文章插图
 
非对称加密:加密和解密用的不是同一个秘钥,也就是出现了'私钥'和'公钥'的概念,对于服务器私钥只有一个,必须严格保密,而公钥可以有很多个,随意分发给客户端
常用的非对称加密算法:DSA、RSA(常用)、ECC
一篇一看就懂的Https的实现过程梳理

文章插图
 
注意:公钥和私钥有个特别的“单向”性,虽然都可以用来加密解密,但公钥加密后只能用私钥解 密,反过来,私钥加密后也只能用公钥解密 。
这里提个2个问题:
1.为什么有了对称加密还需要非对称加密呢?
2.我们使用的https协议到底是使用对称加密还是非对称加密呢?
问题先放这,原理剖析中会一 一解答;
【一篇一看就懂的Https的实现过程梳理】摘要:这个主要可以保证上面说的数据完整性,也就是数据没有被篡改,生成唯一"指纹",可以与我们常说的"加盐"结合使用;与服务器协商规则即可;
数字签名:可以作为服务器识别用户的真实身份,证明我是我,一般也就是通过秘钥给摘要加密就可以实现;
数字证书:由第三方认证机构颁发,具有高信任度的,由它来给各个公钥签名,用自身的信誉来保证公钥无法伪造,是可信的;
 
4.Http实现原理剖析
=========== 好了,重点来了===========
我们先从上面的问题引入:为什么有了对称加密还需要非对称加密呢?
前面提到 对称加密加密和解密用的是同一个秘钥,基于此如果用对称加密,那如果别黑客拦截,那就可以随意解密我们的数据,
这就要求我们客户端与服务器要约定一种只有对方可以破解的公钥和私钥,也就是非对称的加密方式;
那么问题来了........... 我们如何约定客户端和服务器加密规则呢?何如解决服务器的公钥安全的传输呢?
如果再用非对称进行加密一层呢?那是不是还要一层一层有一层..... 形成俄罗斯套娃啦......
 
直接上结论:我们可以用非对称加码来约定双方的传输秘钥规则,约定好之后就可以通过对称加密来传输数据
流程如下(图片来源网络):
一篇一看就懂的Https的实现过程梳理

文章插图
 
1.客户端发起https请求,服务端返回Ca证书,包含公钥的信息
2.客户端收到返回内容,会对证书进行校验(浏览器自带机制),如果此时被黑客拦截,篡改了证书内容,则会进行告警提示
3.客户端生成随机数+摘要等等信息通过证书中的公钥进行加密传输给服务端,此时即使黑客拦截,因为没有私钥,也无法进行解密
4.服务端解密,并通过客户端传入的随机数构造对称加密算法,对返回结果内容进行加密后传输(这一步就约定好了对称加密算法,完成对称秘钥传输)
5.双方可以通过约定好的算法进行加密传输数据


推荐阅读