HTTPS、证书与使用Charles抓包

 

Q：HTTP协议是明文传输，在凶险的网络世界里裸奔，实在太不安全了！

A：是的，为了解决这个问题，人们搞了个HTTPS协议。

Q：先问一句，HTTPS协议的报文格式和HTTP有什么不一样吗？

A：HTTPS的意思是“HTTP over SSL”，加解密过程放在应用层与传输层之间，对于使用SSL的应用层程序来讲是无感知的，浏览器收发的依然是标准的HTTP报文。

Q：好的，那SSL协议如何完成加密通讯？

A：SSL协议使用RSA非对称加密算法，一个该算法的使用者会生成2个密钥，分别是私钥和公钥，私钥加密的内容只能用配对的公钥解密，反之亦然；加密算法很强没法被破解，且没法经过一个密钥算出另外一个密钥。服务器S在收到客户端C发来的TCP握手后，把本身的公钥发给C；随后C生成本身的公钥和私钥，并把本身的公钥用S的公钥加密后发送给S。这样一来，S和C都互相有对方的公钥啦。

Q：哦，这样一来，S给C发的信息用C的公钥加密，只有C的私钥能解开；C给S发的信息用S的公钥加密，也只有S的私钥能解开。其余人就算拿到了信息也查看不了啦！太棒了！

A：是的。

Q：且慢，有了SSL，只能确保通讯内容是保密的，但要是C的DNS服务被劫持了，C与一个假冒S的钓鱼网站创建了SSL链接，那么就算通讯加了密，敏感信息仍是会落到歹人手里。

A：你说的很对，所以人们又发明了“证书”体系，能够向C证实“与你创建链接的那头确实是S”。

Q：哦？愿闻其详。

A：首先得有一个相似于“公证处”的第三方机构CA（Certification Authority）。S为了防范冒牌货，能够拿着本身的公钥来CA申请认证。CA在验明正身后，会给S一个全局惟一的身份标识，而后生成一个证书（certificate），证书里包含了S的公钥和身份标识。最后，CA用本身的私钥给这个证书加一个数字签名，以证实这个证书确实是CA颁发的。

Q：这样一来，S就拿到了一个CA颁发的证书，证书里有CA的签名，以及S的身份和公钥。

A：是的，如今咱们能够改进以前的通讯流程。首先C得持有CA的公钥，多是系统预置，或者用户手动安装。当S收到C的TCP握手后，把本身的证书发给C，C拿到证书后，先用CA的公钥验证签名真伪，确认该证书确实是CA颁发；而后，从证书里获取身份信息，与对方发来的身份信息相比较，确认该证书里的身份确实就是S的身份。身份验证无误后，就能够确认TCP链接的另外一头确实是S本尊，能够放心地开始SSL通讯啦！

Q：我想一想……证书可能被伪造吗？

A：不可能，除非你有CA的私钥。

Q：听起来是极好的。可要是CA把证书颁给了钓鱼网站，那就没得玩了……

A：是的，CA是整个信任体系的根，在信任CA时，必定要慎重！系统里预置了一些世界上知名的CA根证书（含有CA公钥的证书），用户也能够本身添加。

Q：有意思，我想试着解释一下，为了能让Charles代理手机的https请求，我作了什么操做。首先，Charles在开发机上起了个代理服务器Proxy，Proxy为了能与手机创建https链接，须要有一个证书。一个开发用的小破代理显然没资格也不必去申请什么知名CA的认证，因而Charles本身搞了一个野生的CA，而后用这个CA给Proxy颁发了一个证书。然而手机并不信任这个名不见经传的野生CA，见到Proxy发来的、由野生CA颁发的证书，天然也不会信任，从而拒绝创建TCP链接。为了解决信任问题，就须要我连着Proxy去chls.pro/ssl这个地址下载这个野生CA的根证书，而且在手机里信任它。这一步完成之后，手机在与Proxy创建TCP链接时，Proxy发来的证书就可以被信任并验证，从而顺利创建通讯~

A：很好~顺便说一句，历史上还真有些名气很大的CA被黑客攻破服务器拿到私钥，这些CA也所以变得再也不可信。为此操做系统里还维持着一个“证书吊销列表”，记录这些倒霉的CA。