HTTPS 详细解析 (超详细,半小时搞懂HTTPS)

yedaoxiaodi 2019-12-29

https S 代表的是SSL/TLS

先做个实验: 在浏览器的地址栏上输入 http:\\www.meituan.com  

用http header LIVE  抓个包如下

HTTPS 详细解析 (超详细,半小时搞懂HTTPS)

过程如下:

浏览器先以HTTP协议来连接服务器。服务器因配置了HTTPS,所以使用了302跳转至https页面,浏览器再去连接服务器的443端口。

上述小实验只是https步骤的第一步 ,接下来先进行TCP三次握手,然后进行SSL/TLS四次握手

接下来就是难点了。再讲难点之前,先讲难点细分讨论  

什么是对称加密

只有一个密钥,它可以对内容进行加密,也可以用该密钥对密文进行解密。

但问题来了,密钥如何保护呢?  

什么是公钥加密  (非对称加密)

有两把密钥,一把公钥,一把私钥,公钥加密的内容必须用私钥才能解开,私钥加密的内容必须用公钥解开

单个公钥私钥,只能保障单方向的安全性,为什么这么说呢

服务器将他的公钥明文发送给浏览器,浏览器将数据用公钥加密发给服务器,只有服务器有私钥可以查看数据。

服务器将数据用私钥加密发送给浏览器,浏览器用公钥解密

想想看,公钥是一开始是明文传输的,意味着只要截获了公钥就可以查看服务器发送的消息,那怎样可以保障双方向的通信安全呢?

服务器一对公钥私钥,浏览器一对公钥私钥

服务器明文传输自己的公钥A给浏览器,浏览器明文传输自己的公钥B给服务器

以后浏览器给服务器发送的数据都用公钥A加密,服务器给浏览器发送的数据用公钥B加密,这样就保障了双向通信的安全性

但非对称性加密非常耗时,如何解决呢 ?

对称加密+非对称加密结合

浏览器用公钥A将自己的对称密钥X发送给服务器

服务器用私钥A解密获得对称密钥X

双方用对称密钥X进行数据交换

这样看起来很安全,但其实还要一个小问题

在发送自己的公钥给对面时,有个中间人截获双方的公钥,并且把自己的公钥发送给浏览器和服务器

这时候中间人就可以收到用中间人的公钥加密的对称密钥X,这样看来,还是很危险,客户端根本不知道接受的公钥是否可信

数字证书

数字证书是网站的身份证,有了证书就可以证明该网站的合法性;

网站在使用HTTPS之前,需要向CA机构申请一份数字证书,数字证书里有持有者和网站公钥的信息,服务器只需要把证书传给浏览器即可

但如何证明证书的真伪性呢?

数字签名

把证书的内容生成一份签名,对比证书的内容和签名是否一致

签名如何制作呢: 将证书的明文信息用hash函数加密一次得到一个固定长度的序列,称消息摘要,哈希值,然后CA用私钥进行加密得数字签名   明文和数字签名组成数字证书

如何验证呢:用CA机构的公钥对数字签名进行解密,得到哈希值,用证书里的hash算法对证书明文进行hash ,查看两次得到的hash是否相同

CA公钥是否可信?

操作系统,浏览器会默认安装信任的证书,证书里包含信任的公钥

现在来理解一下四次握手:

HTTPS 详细解析 (超详细,半小时搞懂HTTPS)

1.创建一个属于浏览器与服务器之间的session,避免多次重复验证

2.服务器将自己的证书发送给浏览器

3.浏览器发送对称密钥给服务器

4.安全的会话建立,数据采用私钥加密

https中涉及的数据包

client hello报文:

TSL版本

SID(session id):保持会话;扩展:不过只保留在一台服务器上,如果请求域名的流量很大的时候,往往右很多的服务器提供服务,就无法恢复对话。采用session ticket

密文族:密钥交换算法-对称加密算法-哈希算法

server_name:请求访问的域名

服务器在收到client hello报文后,会回复三个数据包

server hello:session id 、选择的密文族、选择的TSL版本

Certificate报文:服务器的数字证书

server hello done 和server key exchange

客户端验证证书的真伪: 根据数字签名

密钥交换:客户端通过服务器的证书将非对称加密的密钥发送给服务器

到此建立TSL连接结束了 ,其中还要很多细节之处由于水平有限,未能提出

相关推荐