HTTP一般基于TCP协议,而HTTPS就是在这之间加了SSL/TLS协议,那么在TCP三次握手建立TCP连接后,就需要TLS握手建立SSL/TLS连接。
(1)首先,客户端向服务器发起加密通信请求-ClientHello请求,该请求包括
① 生成随机数(用于后续会话密钥);
② 客户端支持的密码套件列表,如RSA加密算法。
③ 客户端支持的TLS协议版本;
(2)服务器收到后,作出响应-ServerHello,响应包括
① 生成随机数(用于后续会话密钥);
② 确认密码套件列表;
③ 确认TLS协议版本;
同时发送Certificate信息,携带服务器的数字证书。
(3)客户端收到响应后,先通过浏览器或OS中的CA公钥确认数字证书真实合法,再取出数字证书中服务器的公钥,使用其加密报文,发送往服务器:
① 一个随机数;
② 传递后续通信都以【会话密钥】加密通信的信息;
③ 客户端握手结束通知;
④ 把之前所有发送数据做个摘要,并用【会话密钥】加密,以保证可用和信息未被篡改过。
综上的三个随机数,通过前面双方协商的加密算法,客户端生成本次通信的【会话密钥】
(4)服务器收到后,也会计算出本次通信的【会话密钥】,然后向客户端发送信息:
① 传递后续通信都以【会话密钥】加密通信的信息;
② 服务器握手结束通知
③ 把之前所有发送数据做个摘要,并用【会话密钥】加密,以保证可用和信息未被篡改过。
到这里TLS握手结束!
不,内容还没。
RSA比较传统的密钥交换算法不具前向安全的性质目前使用较少ECDHE前向安全目前广泛使用
(1)ECDHE支持前向保密
(2)使用ECDHE可不需等最后一次TLS握手,就可以提前发送加密的HTTP数据,节省一个消息时间
(3)ECDHE在第2次握手,会出现服务器发出Server Key Exchange信息
以上RSA都达不到该效果。
第三次握手生成的【会话密钥】是对称的还是非对称的?
考虑非对称加密计算耗时量大,在HTTPS后续通信中使用的会话密钥是对称加密的。
要求一个密钥仅可访问它所保护的数据;用来产生密钥的元素一次一换,不能再产生其他密钥;一个密钥被破解,并不影响其他密钥的安全性。
因为RSA每次对称加密传递信息,都是基于公钥加密,私钥解密的,若干服务器私钥被截取了,那么通信数据将轻而易举地被解密。
关键在于客户端服务端都生成一对公私钥,且密钥是实时生成的。客户端服务器均为生成随机数作为私钥,据特殊公式算出各自的公钥,然后双方据持有的数据算出一个一样随机数用于后续对称加密的密钥。
到此这篇关于关于HTTPS的TSL握手的文章就介绍到这了,更多相关HTTPS的TSL握手内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!