blog
blog copied to clipboard
网络篇 - HTTPS 与 TLS 握手
what is https
-
https
全称(Hyper Text Transfer Protocol over Secure Socket Layer)
,也就是在原http
协议下,添加SSL(Secure Socket Layer)
层 -
https
最大的亮点就是SSL
层加对数据的加密
why use https?
💸 从原来的
http
协议缺点来看:
-
明文传输
传输的时候使用明文
传参,极其容易被第三方截取。https使用的是加密传输。 -
MITM 中间人冒充服务器
没有访问发起者的身份认证机制,第三方即可以十分容易地使用终端发起大量伪请求。 -
报文容被篡改
报文段被部分篡改,http服务器端也无法识别。
HTTPS 与 HTTP的不同点
-
http
的URL
以http://
开头,https
以https://
开头 -
HTTP
采用的是明文传输,而HTTPS
使用的是SSL\TSL
进行加密传输 -
HTTP
的默认端口是80
,而HTTPS
的默认端口是443
<=牢记 -
HTTPS
需要CA
证书,http
不需要。 - http 的连接很简单,是无状态的,
https
协议是由SSL+http
协议构建的可进行加密传输、身份认证的网络协议 要比http
协议安全
对称加密 和 非对称加密
- 非对称加密中
公钥
加密只有私钥
可以解开,私钥
加密只有公钥
能够解开 - 对称加密速度快,可以加密的信息量较大
- 非对称加密算法复杂,加密解密速度慢,一般用于少量信息加密
https的劣势
- 因为加密的需要,常见的三握手就要多几个来回,要还密钥和确认加密算法的需要,所以首次建立连接会慢一丢丢。(但是相较于安全性来说,是值得的) 并且使用http2.x之后,tcp的复用,会大大减少握手带来的消耗。
- 因为对传输进行加密,会一定程度增加
cpu
消耗,相同负载下会增加带宽和服务器投入成本。 - 功能越强大的证书就越贵,加大了项目的投资成本。
- 在某些政治或者其他原因下,
CA
公司信息泄露,那么SSL
的证书安全就无从谈起。
SSL 与 TSL
-
SSL
(Security Socket Layer)是一种广泛运用在互联网上的资料加密协议;TLS
是SSL
的下一代协议 -
SSL
证书 (Certificate) 像身分证一般可以在互联网上证明自己的身份。在资料的加密传输开始之前,服务器透过“有效”的SSL
证书告诉用户端自己是值得信赖的服务器 - 目前
SSL
大部分是收费的,但是自己生成的SSL
证书又不能被浏览器所信任,即不安全。
前提工作
本段中(A与A',B与B')表示两对非对称加密的公钥和私钥。
- 服务端会将准备用于通信加密的公钥(A)送到权威证书机构(CA),CA会用一个证书将这把送过来的公钥(A)使用非对称私钥(B')进行加密。
- 权威机构也会在客户的操作系统中预先安装证书,里面存放着该机构的公钥(B),用于验证服务器发过来的证书是否合法。
- 这里还有一个服务端私钥(A'),会在传输
pre-master
中用到。
SSL\TSL 握手流程
1️⃣ Client Hello
客户端向服务器发送准备链接的信息(相当于打招呼), 并且告诉服务器自己支持哪些加密套件
参数:
- 随机数 Random1
- 客户端支持的加密套件(Support Ciphers)
2️⃣ Server Hello
服务器响应 客户端的打招呼,返回包括
参数
- 服务器从客户端发过来的套件中,选择了具体的一个加密套件
- 随机数
Random2
3️⃣ Certificate
这一步是服务端将自己的证书下发给客户端,让客户端验证自己的身份,客户端验证通过后取出证书中的公钥。
参数
- (服务端 ==> 客户端 )证书
- 客户端取出证书中的公钥
4️⃣ Certificate Request & Server Hello Done
Certificate Request 是服务端要求客户端上报证书(可选)
Server Hello Done 通知客户端 Server Hello 过程结束
5️⃣ Certificate Verify
-
客户端收到服务端的证书,使用CA机构在客户端中内置的证书公钥尝试解开证书,若不能解开,则说明证书不是真正的服务器发出的,或者证书被篡改过。
-
若验证通过(解得开证书),则取出证书中的服务端公钥,准备用于非对称加密
pre-master
。
注意:这里若证书合法性验证失败,则会告知用户改证书有风险。
各自生成对称加密套件 & Client Key Exchange
-
生成随机数
pre-master
,并用服务端公钥(非对称加密) 加密,并发送给服务端。 -
双方用之前约定好的的加密套件,以 (random1 + random2 + pre-master) 作为盐,生成对称加密的会话秘钥
-
接下来准备开始,进行测试加密传输。
6️⃣ Change Cipher Spec & Encrypted Handshake Message (客户端测试加密连接)
首先是客户端通知服务端后面再发送的消息都会使用前面协商出来的秘钥加密了,是一条事件消息。
再是客户端将前面的握手消息生成摘要再用协商好的秘钥加密,这是客户端发出的第一条加密消息。
7️⃣ Change Cipher Spec & Encrypted Handshake Message (服务端测试加密连接)
首先是服务端通知客户端后面再发送的消息都会使用加密,也是一条事件消息
再是服务端也会将握手过程的消息生成摘要再用秘钥加密,这是服务端发出的第一条加密消息
- 使用加密套件的私钥进行解密,获得随机数
- 服务端使用对称加密算法,对获取到的随机数进行对称加密,得到“指定加密算法” + “随机生成数” 结合的一个特殊令牌
- 服务器使用这个令牌加密需要保护的内容主体,一并发送给客户端
8️⃣ 正式发送加密数据
使用各自生成的对称秘钥public key
正式进行对称加密数据传输。
优化
握手过程优化
并不是每一次的传输都需要进行这么繁杂的握手过程,每隔一定的时间才回进行重新SSL握手。
首次的client hello
就附带了上一次的session ID
,服务端接受到这个session ID,若能够复用则不进行重新握手。
协议优化
- 使用
http2.0
与https
结合,加入多路复用、服务端推送等优势。 - 直接使用SPDY
小结
参考文章
[1] SSL/TLS 握手过程详解
[2] 从http 到 https项目迁移
[3] IEEE 802.1X-PEAP认证过程分析(抓包)