女朋友也是軟體工程專業，因為快要畢業了，最近一邊做畢設一邊學習程式設計。前兩天她問我 https 的問題，本來想直接扔一篇網上的教程給她。後來想了一下，那些文章大多直接介紹概念， 對新手不太友好，於是我乾脆親自給她解釋一下，順便整理了乙份問答錄。
http 協議中的內容都是明文傳輸，https 的目的是將這些內容加密，確保資訊傳輸安全。最後乙個字母 s 指的是 ssl/tls 協議，它位於 http 協議與 tcp/ip 協議中間。
客戶端和伺服器直接的通訊只有自己能看懂，即使第三方拿到資料也看不懂這些資訊的真實含義。
第三方雖然看不懂資料，但可以 xjb 改，因此客戶端和伺服器必須有能力判斷資料是否被修改過。
客戶端必須避免中間人攻擊，即除了真正的伺服器，任何第三方都無法冒充伺服器。
很遺憾的是，目前的 http 協議還不滿足上述三條要求中的任何一條。
是的，我沒開玩笑，你可以暫時別管第三個要求，因為它實際上隸屬於第乙個需求。我們都知道加密需要密碼，密碼不是天下掉下來，也得需要雙方經過通訊才能協商出來。所以乙個設計良好的加密機制必然會防止第三者的干擾和偽造。等搞明白了加密的具體原理，我們自然可以檢驗是否滿足:「任何第三者無法冒充伺服器」這一要求。
對稱加密可以理解為對原始資料的可逆變換。比如hello可以變換成ifmmp，規則就是每個字母變成它在字母表上的後乙個字母，這裡的秘鑰就是1，另一方拿到ifmmp就可以還原成原來的資訊hello了。
引入對稱加密後，https 的握手流程就會多了兩步，用來傳遞對稱加密的秘鑰:
客戶端: 你好，我需要發起乙個 https 請求
伺服器: 好的，你的秘鑰是1。
提到了對稱加密，那麼自然還有非對稱加密。它的思想很簡單，計算兩個質數的乘積很容易，但反過來分解成兩個質數的乘積就很難，要經過極為複雜的運算。非對稱加密有兩個秘鑰，乙個是公鑰，乙個是私鑰。公鑰加密的內容只有私鑰可以解密，私鑰加密的內容只有公鑰可以解密。一般我們把伺服器自己留著，不對外公布的金鑰稱為私鑰，所有人都可以獲取的稱為公鑰。
使用對稱加密一般要比非對稱加密快得多，對伺服器的運算壓力也小得多。
伺服器直接返回明文的對稱加密金鑰是不是不安全。如果有監聽者拿到這個金鑰，不就知道客戶端和伺服器後續的通訊內容了麼？
是這樣，所以不能明文傳遞對稱秘鑰，而且也不能用乙個新的對稱加密演算法來加密原來的對稱秘鑰，否則新的對稱秘鑰同樣無法傳輸，這就是雞生蛋、蛋生雞的悖論。
這裡我們引入非對稱加密的方式，非對稱加密的特性決定了伺服器用私鑰加密的內容並不是真正的加密，因為公鑰所有人都有，所以伺服器的密文能被所有人解析。但私鑰只掌握在伺服器手上，這就帶來了兩個巨大的優勢:
伺服器下發的內容不可能被偽造，因為別人都沒有私鑰，所以無法加密。強行加密的後果是客戶端用公鑰無法解開。
任何人用公鑰加密的內容都是絕對安全的，因為私鑰只有伺服器有，也就是只有真正的伺服器可以看到被加密的原文。
所以傳輸對稱秘鑰的問題就迎刃而解了: 秘鑰不是由伺服器下發，而是由客戶端生成並且主動告訴伺服器。
所以當引入非對稱加密後，https 的握手流程依然是兩步，不過細節略有變化:
客戶端: 你好，我需要發起乙個 https 請求，這是我的 (用公鑰加密後的) 秘鑰。
伺服器: 好的，我知道你的秘鑰了，後續就用它傳輸。
你好像還是沒有解決雞生蛋，蛋生雞的問題。你說客戶端傳送請求時要用公鑰加密對稱秘鑰，那公鑰怎麼傳輸呢？
每乙個使用 https 的伺服器都必須去專門的證書機構註冊乙個證書，證書中儲存了用權威機構私鑰加密的公鑰。這樣客戶端用權威機構的公鑰解密就可以了。
現在 https 協議的握手階段變成了四步:
客戶端: 你好，我要發起乙個 https 請求，請給我公鑰
伺服器: 好的，這是我的證書，裡面有加密後的公鑰
客戶端: 解密成功以後告訴伺服器: 這是我的 (用公鑰加密後的) 對稱秘鑰。
伺服器: 好的，我知道你的秘鑰了，後續就用它傳輸。
那權威機構的公鑰又怎麼傳輸？
所以各個公司要先去權威機構認證，申請證書，然後作業系統只會儲存權威機構的公鑰。因為權威機構數量有限，所以作業系統廠商相對來說容易管理。如果這個權威機構不夠權威，xjb 發證書，就會取消他的資格，比如可憐的沃通。。。。
你說伺服器第一次會返回證書，也就是加密以後的公鑰，那我怎麼知道這個證書是可靠的？
我們都知道雜湊演算法的特點，它可以壓縮資料，如果從函式角度來看，不管多複雜的資料(定義域可以非常大)經過雜湊演算法都會得到乙個值，而且這個值處在某個特定(遠小於定義域的範圍)值域內。相同資料的雜湊結果一定相同，不相同資料的雜湊結果一般不同，不過也有小概率會重複，這叫雜湊衝突。
為了確保原始證書沒有被篡改，我們可以在傳遞證書的同時傳遞證書的雜湊值。由於第三者無法解析資料，只能 xjb 改，那麼修改後的資料在解密後，就不可能通過雜湊。
比如說公鑰就是之前的例子hello，我們假設雜湊演算法是獲取字串的最後乙個字元，那麼hello的雜湊值就是o，所以加密字串是ifmmpp。雖然公鑰已知，每個人都可以解密，解密完也可以篡改，但是因為沒有私鑰， 所以無法正確的加密。所以它再返回給客戶端的資料是無效資料，用公鑰解析後會得到亂碼。即使攻擊者通過多次嘗試碰巧能夠解析，也無法通過雜湊校驗。
首先真正的伺服器下發的內容，無法被別人篡改。他們有權威機構的公鑰，所以可以解密，但是因為沒有私鑰，所以解密以後的資訊無法加密。沒有加密或者錯誤加密的資訊被客戶端用公鑰解密以後，必然無法通過雜湊校驗。
但是，如果你一開始請求的就不是真的伺服器，而是乙個攻擊者，此時的他完全有機會進行中間人攻擊。我們知道第一次握手的時候伺服器會下發用於證明自己身份的證書，這個證書會用預設在裝置上的公鑰來解密。所以要麼是經過認證的證書用權威機構的私鑰加密，再用權威機構解密，要麼是用非權威機構的私鑰加密，然後找不到公鑰解密。
所以如果不小心安裝過非權威機構的根證書，比如黑客提供的惡意證書，這時候裝置上就多了乙個預設的公鑰，那麼用惡意私鑰加密的證書就能被正常解析出來。所以千萬不要隨便裝根證書，這等於是為那些惡意證書留了一扇門。
當然，凡是都有兩面性。我們知道 charles 可以除錯 https 通訊，它的原理就是需要使用者安裝 charles 的根證書，然後我們的請求會被**到 charles 伺服器，它下發的 charles 證書才能被正確解析。另一方面，charles 會作為客戶端，從真正的伺服器**拿到正確的 https 證書並用於後續通訊。幸好 charles 不是流氓軟體，或者它的私鑰一旦洩露，對使用者都會造成很大的影響。
我可以舉乙個例子，證書有多個種類，最貴的叫 ev (extended validation)，它需要公司營業執照等多個檔案才能申請人工審核，好處也很明顯，可以在瀏覽器位址列左側準確顯示公司名稱，比如 bitbucket 的官網:
這是客戶端直連時候的正常現象。但如果你用 charles **，客戶端拿到的是 charles 證書，所以會變成:
tcp 有三次握手，再加上 https 的四次握手，會不會影響效能？
首先，https 肯定會更慢一點，時間主要花費在兩組 ssl 之間的耗時和證書的讀取驗證上，對稱演算法的加解密時間幾乎可以忽略不計。
而且如果不是首次握手，後續的請求並不需要完整的握手過程。客戶端可以把上次的加密情況直接傳送給伺服器從而快速恢復，具體細節可以參考 **ssl/tls協議。
除此以外，ssl 握手的時間並不是只能用來傳遞加密資訊，還可以承擔起客戶端和伺服器溝通 http2 相容情況的任務。因此從 https 切換到 http2.0 不會有任何效能上的開銷，反倒是得益於 http2.0 的多路復用等技術，後續可以節約大量時間。
如果把 https2.0 當做目標，那麼 https 的效能損耗就更小了，遠遠比不上它帶來的安全性提公升。
相信以上九個問題足夠幫助新人了解 https 了，但這只是基本概念，關於 https 的使用(比如 ios 上的一些具體問題)還需要不斷嘗試和研究。
文章最後打乙個求職廣告，長期有效，女朋友今年畢業，考研 380+，簡歷戳這裡，計算機基礎還算紮實，但專案經驗偏少，可以實習 6 個月以上。北京地區如果有想要招實習生的公司，歡迎聯絡我，方向不限，前後端皆可培養，ios 更好(我自己教)。
從入門到熟悉 HTTPS 的 9 個問題
q1 什麼是 https？bs https 是安全的 http http協議中的內容都是明文傳輸,https的目的是將這些內容加密,確保資訊傳輸安全,最後乙個字母s 指的是 ssl tls 協議，它位於 http 協議與 tcp ip 協議中間。q2 你說的資訊傳輸安全是什麼意思 bs 資訊傳輸的安...
九個問題考一考你對HTTPS的熟悉程度
q1 什麼是 https？bs https 是安全的 http http 協議中的內容都是明文傳輸，https 的目的是將這些內容加密，確保資訊傳輸安全。最後乙個字母 s 指的是 ssl tls 協議，它位於 http 協議與 tcp ip 協議中間。q2 你說的資訊傳輸安全是什麼意思 bs 資訊傳...
Kali Linux 從入門到精通 九 漏洞掃瞄
發現弱點 從資訊的維度定義漏洞管理 資訊管理 資訊輸出 弱點掃瞄型別 被動掃瞄 基於agent的掃瞄 漏洞的基本概念 cvss vulerabilty reference cve common vulenrable and exposures cve發布流程 很多廠商維護自己的vulnerabili...