https浅析与抓包

Posted 2020-10-11 三蜢

0.HTTP之殇

• 数据明文传输，易嗅探
• 数据完整性无验证，易篡改
• 网站身份无认证，易假冒

由此诞生HTTPS。

---

1.什么是HTTPS

• HTTP + SSL/TLS
• TLS是SSL的升级版

 

 

 

• 作用：防嗅探，防篡改，身份认证

---

2.https握手过程

建立https连接（明文），再用对称加密传输数据。

 

TCP三次握手

C->S:[client hello] C发送hello消息（协议版本，随机数c，加密组件列表等）给S，请求建立SSL会话。

S->C: [server hello]返回响应（确认加密组件，随机数s等）。

S->C: [certificate]返回响应certificate(网站证书)。

S->C: [server key exchange]指定密钥协商（交换）协议(密钥协商方式)，发送密钥协商（交换）算法的公钥给C。

S->C: [server hello done]发送serverhellodone，开始C的密钥协商。

C->S: [clientkeyexchange]C生成密钥协商（交换）算法公私钥，发送公钥给S，此时C和S可以协商出相同的密钥pre master secret，现在C和S可以通过c,s,pre master三个随机数算出对称加密的密钥。（这里本人还看到一个版本是C生成pre master secret 后用密钥交换/协商算法加密发送到S，本人认为不需要发送，S通过C发送的密钥协商的公钥和自己生成的一个随机数xs可以自己计算出这个pre master secret。还有一个版本是对称加密的密钥是C用S的证书公钥加密给S用私钥解密获得，这里本人认为此对称密钥S也可由c,s,pre master自己生成不需要C发送。）

C->S: [changecipherspec]通知S此消息以后C以加密方式发送数据。

C->S: C用生成的对称密钥加密之前所有握手消息hash，发送给S解密验证hash。

S->C: [changecipherspec]通知C此消息后S以加密方式发送数据。

S->C: S用对称密钥加密之前所有握手消息hash，发送给C进行解密验证hash。

========================================

开始对称加密传输数据……（Application Data）

========================================

 

---

 

3.抓包分析https握手流程

以浏览器打开https://www.52pojie.cn为例

　　1. dns解析和tcp三次握手

　　

 

 　　2.clienthello:

　　

可以看出浏览器发送了支持的协议版本TLS1.2，32字节随机数c，加密组件cipher等信息给S。

 　　3. serverhello:

　　

　　

　　可以看出S选择了TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384加密组件，解释如下：
　　密钥交换算法，用于决定客户端与服务器之间在握手的过程中如何认证，用到的算法包括RSA，Diffie-Hellman，ECDH，PSK等，这里选择了ECDHE。

　　加密算法，用于加密消息流，该名称后通常会带有两个数字，分别表示密钥的长度和初始向量的长度，比如　

　　DES 56/56, RC2 56/128, RC4 128/128, AES 128/128, AES 256/256。这里选择了AES。

　　报文认证信息码（MAC）算法，用于创建报文摘要，确保消息的完整性（没有被篡改），算法包括MD5，SHA等。这里选择了SHA384。

　　PRF（伪随机数函数），用于生成“master secret”。

　　S还发送了32字节随机数s。

 　　4.certificate:

　　

　　第一个cert是52pojie网站的证书，第二个cert是颁发者trustasia机构的证书。

　　

　　这里可以获得证书的详细信息

　　5.serverkeyexchange和serverhellodone:

　　

　　可以看出使用ECDH密钥交换算法，指定椭圆曲线secp256r1，还有发送了DH算法协商的公钥给C。

 

　　6. Clientkeyexchange和client change cipher spec:

　　

　　这里C发送了DH算法协商的公钥给S，以及加密了握手消息给S进行验证。

　　

　　7. server change cipher spec:

　　

　　

　　服务端使用Ticket方式存储session状态，在Server Change Cipher Spec之前就需要发送New Session Ticket消息，这部分就不细说了。这里S加密握手消息给

　　C进行验证。

　　8. application data:

　　　　

　　这里可以看出双方握手完毕，以后的消息都进行对称加密，已经无法看出明文了。

 

　　

---

 5.其他

• 由于握手流程导致https速度比http慢，本人认为其带来的安全性更为重要，而速度虽然较慢，但是用户几乎感觉不到，而且有很多优化措施可以提升速度。
• 有了https并不能完全保证网站安全，安全是多因素，多环节的，即使有https，某个‘短板’就可以沦陷一个网站，并且https自身也非安全，如著名的心脏出血漏洞。
• https也非绝对防止MITM，如伪造证书，导出明文密码等。

 

 6.结语

　　简言之，能用https还是用https吧。由于时间仓促，可能有些细节遗漏或不准确，欢迎指正！

7.参考资料

https://xianzhi.aliyun.com/forum/read/2037.html

www.droidsec.cn/浅析https中间人攻击与证书校验/

https://klionsec.github.io/2017/07/31/https-learn/

kb.cnblogs.com/page/530044/

 

 

文章来源：https://laod.cn/hosts/https-capture-analysis.html