HTTPS安全通信机制
RSA握手(单向)
- TLS第一次握手
- 客户端通过发送Client Hello报文开始SSL通信,报文中包含TLS指定版本加密组件列表和生成的随机数Client Random
- TLS第二次握手
- 确认TLS版本是否支持,服务器可进行SSL通信时,会以Server Hello报文作为应答,报文中包含SSL指定版本和加密组件,加密组件是从接收到客户端报文里的加密组件列表中选一个出来,还会生成一个随机数Server Random,加密组件的基本形式为:密钥交换算法+签名算法+对称加密算法+摘要算法
- 服务器发送Certificate报文,报文内包含公钥证书
- 服务器发送Server Hello Done报文通知客户端服务器发送结束
- TLS第三次握手
- 客户端验证完证书(详见下文客户端验证证书)后会生成一个新的随机数pre-master,用服务器的RSA公钥加密该随机数(详见下文客户端服务端通信过程),通过Client Key Exchange报文传给服务端
- 服务端收到后,用RSA私钥解密,得到客户端发来的随机数,至此服务端和客户端都得到了三个随机数Client Random, Server Random, pre-master,通过这三次随机数去生成会话密钥,也就是对称密钥,用于后续HTTP请求/响应的加解密
- 然后客户端发送Change Cipher Spec, 告诉服务端开始使用加密方法发送消息,这一步之前传输的数据都是明文传输的,之后都是对称加密的密文
- 客户端发送Finished报文,把之前发送的数据做个摘要,再用会话密钥加密一下,让服务器做个验证,验证加密通信是否可用和之前的握手信息是否有被中途篡改过。
- 服务器也是同样发送Change Cipher Spec 和Finished报文验证,如果双方加解密都没有问题,则握手完成,从此处开始进行HTTP请求/响应
客户端服务端通信过程
- 服务端将自己的公钥登录到数字证书认证机构(CA),然后数字证书认证机构用自己的私钥对服务器公钥署数字签名并颁发公钥证书,数字证书权威机构已经将事先将其公钥植入到浏览器,然后客户端拿到服务器的公钥证书后用植入的权威机构公钥进行解密确认服务器公钥真实性,然后用服务器公钥加密后发送报文,服务器用私钥解密
HTTPS使用的是混合加密机制
- 非对称密钥加密处理效率很低,所以通信时用对称加密,交换密钥才用非对称加密。
先使用非对称密钥加密方式安全的交换稍后对称密钥所需的密钥,然后确保密钥安全的前提下用对称加密进行通信。
客户端验证证书
- 数字证书和CA机构:
一个数字证书中通常包含了持有者公钥、持有者信息、权威机构(CA)、CA对这份文件的数字签名及使用的算法、证书有效期、一些额外的信息 - 数字证书签发和验证流程
- 会将信息打成一个包然后对其进行hash计算得到一个hash值
- 然后CA会用自己的私钥对其进行hash加密生成Certificate Signature,也就是进行数字签名
- 最后将Certificate Signature添加到文件证书上,形成数字证书
- 验证流程: 客户端用同样的hash算法获取证书的hash值h1(在证书的元数据中有写明用的hash算法和签名算法),然后浏览器与操作系统集成了CA的公钥信息,浏览器收到证书后可用CA公钥解密得到另一个hash值h2,如果h1和h2相等,则认为证书可信。
RSA算法的缺点
- 使用RSA密钥协商算法的最大问题是不支持前向保密,因为客户端传递随机数给服务器用的是公钥加密,如果服务器私钥泄露了,就会导致对称密钥被破解,第三方截获的所有TLS通讯密文都会破解。
前向保密
- 前向安全性:也称为完美前向保密,指即使密钥被泄露后,过去的通信内容也不会被破解。
- 原理: 前向安全性的实现通常依赖于一次性密钥或者临时密钥,在每次会话开始时,双方都会生成一个新的临时密钥,并使用这个密钥进行加密通信,等到通会话结束后密钥失效,由于临时密钥只能在一次会话中使用,所有即使未来被泄露,也只能破解那次会话的数据,而不能解密其他数据。
ECDHE握手(单向)
- TLS第一次握手
- 客户端会先发送一次Client Hello的报文消息,消息里有TLS版本信息,支持的加密组件列表和一个生成的随机数
- TLS第二次握手
- 服务器在收到客户端报文后,返回ServerHello报文消息,消息里面有服务器确认TLS版本信息,生成一个随机数和从客户端的发送的加密组件列表中选择一个加密组件。
- 服务端发送Certificate报文,将证书发送过去
- 服务端接着发送Server Key Exchange报文,这一步和RSA算法有很大区别,这个过程做了三件事:① 选择椭圆曲线(也选好了基点G)② 生成随机数作为椭圆曲线的私钥,保留到本地 ③ 根据G点计算出椭圆曲线的公钥,这个会公开给客户端。
为了保证这个椭圆曲线公钥不被第三方篡改,服务端会用RSA签名算法给服务端的椭圆曲线做个签名 - 发送Server Hello Done报文,至此,第二次握手结束,明文共享了几个信息:Client随机码,Server随机码,椭圆曲线,椭圆曲线基点G,服务器椭圆曲线公钥。
- TLS第三次握手
- 客户端收到服务端证书后会验证证书是否合法,如果合法客户端会生成一个随机数作为客户端椭圆曲线私钥,然后再根据服务器前面给的信息,生成客户端的椭圆曲线公钥,然后发送Client Key Exchange报文和公钥发送给服务器。
至此,双方都有对方的椭圆曲线公钥,自己的椭圆曲线私钥,椭圆曲线G点,于是,双方都计算出点(x,y),其中x双方是一样的。而最终的会话密钥就是用客户端随机数 + 服务端随机数 + x 合成的。 - 客户端发送Change Cipher Spec和Encrypted Handshake Message报文,表示开始使用密钥加密通信和把之前发送的数据做一个摘要,让服务器验证一下,验证下本次生成的对称密钥是否可以正常使用。
- TLS第四次握手
- 服务端也有一个相同的操作,发送Change Cipher Spec和Encrypted Handshake Message报文,用密钥将之前发送的数据做个摘要,让客户端验证一下,如果没有问题,则握手正式完成,可以正常收发HTTP请求/响应了。
RSA和ECDHE握手过程的区别
- RSA密钥协商算法不支持前向保密,而ECDHE密钥协商算法支持前向保密
- 使用了RSA密钥协商算法,TLS完成四次握手后才可以进行应用数据传输通信,而对于ECDHE算法,客户端可以不用等到最后一次握手,就可以提前发送HTTP数据通信,节省了一个RTT往返时间
- 使用ECDHE算法,在TLS第二次握手中,会出现服务器发送Server Key Exchange报文消息,而RSA没有
RSA握手(双向)
ECDHE握手(双向)
评论







