HTTPS的工作模式
HTTPS协议的总体思路:公钥私钥主要用于传输对称加密的秘钥,而真正的双方大数据量的通信都是对称加密进行的
登录一个网站的时候,由于是HTTPS,客户端会发送Client Hello消息到服务器,以明文传输TLS版本信息、加密套件候选列表、压缩算法候选列表等信息,同时,还有一个随机数,在协商对称密钥的时候使用。
然后,网站返回Server Hello消息,告诉客户端,服务器选择使用的协议版本、加密套件、压缩算法等,还有一个随机数,用于后续的密钥协商。
然后,网站会给你一个服务器端的证书,然后Server Hello Done结束消息返回。
为了验证服务器端的证书,客户端从自己信任的CA仓库中,拿CA的证书里面的公钥去解密网站的证书。如果成功了,则说明访问的网站是可信的。这个过程中,你可能会不断往上追溯CA、CA的CA、CA的CA的CA,反正直到一个授信的CA,就可以了。
证书验证完毕之后,觉得网站可信,于是客户端计算产生随机数字Pre-master,发送Client Key Exchange,用证书中的公钥加密,再发送给服务器,服务器可以通过私钥解密出来。
至此,无论是客户端还是服务器,都有了三个随机数,分别是:自己的、对端的,以及刚生成的Pre-Master随机数。通过这三个随机数,可以在客户端和服务器产生相同的对称密钥。
有了对称密钥,客户端发送Change Cipher Spec,与服务器端确定采用协商的通信密钥和加密算法进行加密通信。
然后发送一个Encrypted Handshake Message,将已经商定好的参数等,采用协商密钥进行加密,发送给服务器用于数据与握手验证。
同样,服务器也可以发送Change Cipher Spec,确定共同协商的通信密钥和加密算法进行加密通信,并且也发送Encrypted Handshake Message的消息试试。当双方握手结束之后,就可以通过对称密钥进行加密传输了。
这是HTTPS的单项认证,也即客户端验证服务端的证书,适用于大部分的场景,也可以在更加严格安全要求的情况下,启用双向认证,双方互相验证证书。
两端随机数和pre-master生成对称密钥的流程: