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。