背景

最近基于興趣學學習了下 HTTPS 相干的知識，在此記錄下學習心得。

在上網獲得信息的進程中，我們接觸最多的信息加密傳輸方式也莫過于 HTTPS 了。每當訪問1個站點，閱讀器的地址欄中出現綠色圖標時，意味著該站點支持 HTTPS 信息傳輸方式。我們知道 HTTPS 是我們常見的 HTTP 協議與某個加密協議的混合體，也就是 HTTP+S。這個 S 可以是 TLS（安全傳輸層協議）、也能夠是 SSL（安全套接層），不過我更認可另外一個抽象概括的說法，HTTP+Security。不過要談論 HTTPS 為什么安全，還得從 HTTP 為什么不安全說起。

假定你現在正坐在教室里上課，現在你非常想和走道旁的迷人的 TA 說1些話，1般這個時候你會用“傳紙條”的方式來交換。而這個方式和 TCP/IP 協議基本的工作模式10分相像：

1. 通太小動作引發對方注意；
2. 對方以多種可能的方式（注視、肢體語言等）回應于你；
3. 你確認對方感知到你后，將紙條傳給對方；
4. 對方瀏覽紙條；
5. 對方給予你瀏覽后的反應；

怎樣樣，這個流程是否是很熟習？

如果你要傳遞紙條的 TA 距離你很遠怎樣辦？HTTP 協議就是指你在紙條上寫明你要傳給的 TA 是誰，或 TA 的坐位在哪，接著只需要途徑的同學拿到紙條后根據紙條上的唆使順次將紙條傳過去就 OK 了。

這個時候問題來了：途徑的同學完全可以觀看并知道你在紙條上寫了甚么。

這就是 HTTP 傳輸所面臨的問題之1：中間人攻擊，指消息傳遞的進程中，處在傳遞路徑上的攻擊者可以嗅探或竊聽傳輸數據的內容。

加密

HTTPS 針對這個問題，采取了“加密”的方式來解決。最著名原始的加密方法就是對稱加密算法了，就是雙方約定1個暗號，用甚么字母替換甚么字母之類的。現在1般采取1種叫 AES（高級加密算法）的對稱算法。

對稱加密算法既指加密和解密需要使用的密鑰 key 是1樣的。

AES 在數學上保證了，只要你使用的 key 足夠長，破解幾近是不可能的（除非光子計算機造出來了）

我們先假定在沒有密鑰 key 的情況下，密文是沒法被破解的，然后再回到這個教室。你將用 AES 加密后的內容噌噌噌地寫在了紙條上，正要傳出去的時候你突然想到，TA 沒有 key 怎樣解密內容呀，或說，應當怎樣把 key 給TA？

如果把 key 也寫在紙條上，那末中間人照樣可以破解竊聽紙條內容。或許在現實環境中你有其他辦法可以把 key 通過某種安全的渠道送到 TA 的手里，但是互聯網上的實現難度就比較大了，畢竟不管怎樣，數據都要經過那些路由。

因而聰明的人類發明了另外一種加密算法——非對稱加密算法。這類加密算法會生成兩個密鑰（key1 和 key2）。凡是 key1 加密的數據，key1 本身不能解密，需要 key2 才能解密；凡事 key2 加密的數據，key2 本身不能解密，只有 key1 才能解密。

目前這類算法有很多中，最經常使用的是 RSA。其基于的數學原理是：

兩個大素數的乘積很容易算，但是用這個乘積去算出是哪兩個素數相乘就很復雜了。好在以目前的技術，分解大數的素因確切比較困難，特別是當這個大數足夠大的時候（通常使用2的10次方個2進制位那末大），就算是超級計算機，解密也需要非常長的時間。

現在就把這類非對稱加密的方法利用在我們教室傳紙條的場景里。

• 你在寫紙條內容之前先用 RSA 技術生成了1對密鑰 k1 和 k2。
• 你把 k1 用明文傳了出去，路經或許有人會截取，但是沒有用，k1 加密的數據需要 k2 才可以破解，而 k2 在你自己手中。
• k1 傳到了目的人，目的人會去準備1個接下來準備用于對稱加密（AES）的傳輸密鑰 key，然后用收到的 k1 把 key 加密，傳給你。
• 你用手上的 k2 解出 key 后，全教室只有你和你的目的人具有這個對稱加密的 key，你們倆就能夠縱情聊天不怕竊聽啦~

這里或許你會有問題，為何不直接用非對稱加密來加密信息，而是加密 AES 的 key 呢？
由于非對稱加密和解密的平均消耗時間比較長，為了節省時間提高效力，我們通常只是用它來交換密鑰，而非直接傳輸數據。

但是使用非對稱加密真的可以防范中間人攻擊嗎？
雖然看上去很安全，但是實際上卻擋不住可惡的中間人攻擊。

假定你是 A，你的目的地是 B，現在要途徑1個歹意同學M。

中間人的歹意的地方在于它會假裝成你的目標。

• 當你要和 B 完成第1次密鑰交換的時候，M 把紙條扣了下來，偽裝自己是B并捏造了1個 key，然后用你發來的 k1 加密了 key 發回給你。
• 你以為你和 B 完成了密鑰交換，實際上你是和 M 完成了密鑰交換。
• 同事 M 和 B 完成1次密鑰交換，讓 B 以為和 A 你完成了密鑰交換。
• 現在整體的加密流程變成了A（加密鏈接1）->M(明文)->B(加密鏈接2)的情況了，這時候候 M 仍然可以知道A和B傳輸的全部消息。

這個時候就是體現 HTTPS 和傳紙條的區分了。在教室里，你是和1位與你身份幾近對等的的對象來通訊；而在訪問網站時，對方常常是1個比較大（或知名）的服務者，他們有充分的資源，也許他們可以向你證明他們的合法性。

此時我們需要引入1個非常權威的第3方，1個專門用來認證網站合法性的組織，可以叫做 CA（Certificate Authority）。各個網站服務商可以向 CA 申請證書，使得他們在建立安全連接時可以帶上 CA 的簽名。而 CA 得安全性是由操作系統或閱讀器來認證的。

你的 Windows、Mac、Linux、Chrome、Safari 等會在安裝的時候帶上1個他們認為安全的 CA 證書列表，只有和你建立安全連接的網站帶有這些CA的簽名，操作系統和閱讀器才會認為這個鏈接是安全的，否則就有可能遭到中間人攻擊。

1旦某個 CA 頒發的證書被用于的非法途徑，那末這個 CA 之前頒發過的所有證書都將被視為不安全的，這讓所有 CA 在頒發證書時都10分謹慎，所以 CA 證書在通常情況下是值得信任的。

總結

使 HTTP 后面增加1個S（Security）的技術，正是 對稱加密 + 非對稱加密 + CA 認證 這3種技術的混合體。固然這個主要是 HTTPS 的基本原理，真正實際中的 HTTPS 的協議是比以上的描寫更加復雜1些的，并且其中任何1步稍有閃失，全部流程都將不再安全。

這也是為何 HTTPS 協議從 SSL 1.0升級到 SSL 3.0，再被 TLS 1.0 現在被 TLS 1.3取代，其背后都是1個個細節上的優化，以防有任何閃失。

TLS 協議相比 SSL 協議增加了傳輸層的安全保證。

更多精彩內容歡迎關注Bugly的微信公眾賬號：

騰訊 Bugly是1款專為移動開發者打造的質量監控工具，幫助開發者快速，便捷的定位線上利用崩潰的情況和解決方案。智能合并功能幫助開發同學把每天上報的數千條 Crash 根據根因合并分類，逐日日報會列出影響用戶數最多的崩潰，精準定位功能幫助開發同學定位到出問題的代碼行，實時上報可以在發布后快速的了解利用的質量情況，適配最新的 iOS, Android 官方操作系統，鵝廠的工程師都在使用，快來加入我們吧！