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。