我們知道 https 其實就是 http + ssl/tls 的合體，它其實還是 http 協議，只是在外面加了一層，ssl 是一種加密安全協議，引入 ssl 的目的是為了解決 http 協議在不可信網路中使用明文傳輸資料導致的安全性問題。可以說，整個網際網路的通訊安全，都是建立在 ssl/tls 的安全性之上的。
tcp 在建立連線時的三次握手，之所以需要 tcp 三次握手，是因為網路中存在延遲的重複分組，可能會導致伺服器重複建立連線造成不必要的開銷。ssl/tls 協議在建立連線時與此類似，也需要客戶端和伺服器之間進行握手，但是其目的卻大相徑庭，在 ssl/tls 握手的過程中，客戶端和伺服器彼此交換並驗證證書，並協商出乙個 「對話金鑰」 ，後續的所有通訊都使用這個 「對話金鑰」 進行加密，保證通訊安全。
整個 ssl/tls 的握手和通訊過程，簡單來說，其實可以分成下面三個階段：
打招呼當使用者通過瀏覽器訪問 https 站點時，瀏覽器會向伺服器打個招呼（clienthello），伺服器也會和瀏覽器打個招呼（serverhello）。所謂的打招呼，實際上是告訴彼此各自的 ssl/tls 版本號以及各自支援的加密演算法等，讓彼此有乙個初步了解。
表明身份、驗證身份
第二步是整個過程中最複雜的一步，也是 https 通訊中的關鍵。為了保證通訊的安全，首先要保證我正在通訊的人確實就是那個我想與之通訊的人，伺服器會傳送乙個證書來表明自己的身份，瀏覽器根據證書裡的資訊進行核實（為什麼通過證書就可以證明身份呢？怎麼通過證書來驗證對方的身份呢？這個後面再說）。如果是雙向認證的話，瀏覽器也會向伺服器傳送客戶端證書。
雙方的身份都驗證沒問題之後，瀏覽器會和伺服器協商出乙個 「對話金鑰」 ，要注意這個 「對話金鑰」 不能直接發給對方，而是要用一種只有對方才能懂的方式發給他，這樣才能保證金鑰不被別人截獲（或者就算被截獲了也看不懂）。
通訊至此，握手就結束了。雙方開始聊天，並通過 「對話金鑰」 加密通訊的資料。
握手的過程大致如此
https 協議之所以複雜，是為了保證通訊過程中資料的安全性，而要保證通訊安全，它在協議中運用了大量的密碼學原理，可以說 https 是集密碼學之大成。無論是在 ssl/tls 握手的過程中，還是在加密通訊的過程中，https 都涉及了大量的密碼學概念，譬如，在證書的數字簽名中使用了雜湊演算法和非對稱加密演算法，在加密通訊的過程中使用了對稱加密演算法，為了防止傳輸的資料被篡改和重放還使用了 mac（訊息認證碼）等。
要想深入了解 https 的工作原理，下面這些概念還是得好好研究下，網上已經有很多文章介紹這些概念了，我在這裡總結一下。
對稱加密
非對稱加密
數字證書
簡單來說，數字證書就好比介紹信上的公章，有了它，就可以證明這份介紹信確實是由某個公司發出的，而證書可以用來證明任何乙個東西的身份，只要這個東西能出示乙份證明自己身份的證書即可，譬如可以用來驗證某個**的身份，可以驗證某個檔案是否可信等等。《數字證書及 ca 的掃盲介紹》 和 《數字證書原理》 這篇部落格對數字證書進行了很通俗的介紹。
知道了證書是什麼之後，我們往往更關心它的原理，在上面介紹 ssl/tls 握手的時候留了兩個問題：為什麼通過證書就可以證明身份呢？怎麼通過證書來驗證對方的身份呢？
這就要用到上面所說的非對稱加密了，非對稱加密的乙個重要特點是：使用公鑰加密的資料必須使用私鑰才能解密，同樣的，使用私鑰加密的資料必須使用公鑰解密。正是因為這個特點，**就可以在自己的證書中公開自己的公鑰，並使用自己的私鑰將自己的身份資訊進行加密一起公開出來，這段被私鑰加密的資訊就是證書的數字簽名，瀏覽器在獲取到證書之後，通過證書裡的公鑰對簽名進行解密，如果能成功解密，則說明證書確實是由這個**發布的，因為只有這個**知道他自己的私鑰（如果他的私鑰沒有洩露的話）。
在非對稱加密演算法中，最出眾的莫過於 rsa 演算法，關於 rsa 演算法的數學細節，可以參考阮一峰的《rsa演算法原理（一）》和《rsa演算法原理（二）》這兩篇部落格，強烈推薦。
當然，如果只是簡單的對數字簽名進行校驗的話，還不能完全保證這個證書確實就是**所有，黑客完全可以在中間進行劫持，使用自己的私鑰對**身份資訊進行加密，並將證書中的公鑰替換成自己的公鑰，這樣瀏覽器同樣可以解密數字簽名，簽名中身份資訊也是完全合法的。這就好比那些地攤上偽造公章的小販，他們可以偽造出和真正的公章完全一樣的出來以假亂真。為了解決這個問題，資訊保安的專家們引入了 ca 這個東西，所謂 ca ，全稱為 certificate authority ，翻譯成中文就是證書授權中心，它是專門負責管理和簽發證書的第三方機構。因為證書頒發機構關係到所有網際網路通訊的身份安全，因此一定要是乙個非常權威的機構，像 geotrust、globalsign 等等，這裡有乙份常見的 ca 清單。如果乙個**需要支援 https ，它就要乙份證書來證明自己的身份，而這個證書必須從 ca 機構申請，大多數情況下申請數字證書的**都不菲，不過也有一些免費的證書供個人使用，像最近比較火的 let's encrypt 。從安全性的角度來說，免費的和收費的證書沒有任何區別，都可以為你的**提供足夠高的安全性，唯一的區別在於如果你從權威機構購買了付費的證書，一旦由於證書安全問題導致經濟損失，可以獲得一筆鉅額的賠償。
如果使用者想得到乙份屬於自己的證書，他應先向 ca 提出申請。在 ca 判明申請者的身份後，便為他分配乙個公鑰，並且 ca 將該公鑰與申請者的身份資訊綁在一起，並為之簽字後，便形成證書發給申請者。如果乙個使用者想鑑別另乙個證書的真偽，他就用 ca 的公鑰對那個證書上的簽字進行驗證，一旦驗證通過，該證書就被認為是有效的。通過這種方式，黑客就不能簡單的修改證書中的公鑰了，因為現在公鑰有了 ca 的數字簽名，由 ca 來證明公鑰的有效性，不能輕易被篡改，而黑客自己的公鑰是很難被 ca 認可的，所以我們無需擔心證書被篡改的問題了。
下圖顯示了證書的申請流程（來自劉坤的技術部落格）：
ca 證書可以具有層級結構，它建立了自上而下的信任鏈，下級 ca 信任上級 ca ，下級 ca 由上級 ca 頒發證書並認證。 譬如 google 的證書鏈如下圖所示：
最後總結一下，其實上面說的這些，什麼非對稱加密，數字簽名，ca 機構，根證書等等，其實都是 pki 的核心概念。pki（public key infrastructure）中文稱作公鑰基礎設施，它提供公鑰加密和數字簽名服務的系統或平台，方便管理金鑰和證書，從而建立起乙個安全的網路環境。而數字證書最常見的格式是 x.509 ，所以這種公鑰基礎設施又稱之為 pkix 。
https加密過程（SSL握手）
https在http的基礎上多了ssl加密層。https的加密過程也就是ssl的握手過程。mac金鑰相當於資料校驗，是為了保證資料完整性而存在的。ssl將資料流分割成記錄，每條記錄都會附上乙個mac，然後再對 記錄 mac值 進行加密。比如客戶端要向服務端傳送資料，對於資料的每個記錄，客戶端都會用它...
https握手過程
瀏覽器將自己的ssl加密元件 ras加密演算法 對稱加密演算法 hash摘要演算法 金鑰長度 傳送給請求 會從中選出一組加密演算法和hash演算法，並將自己的身份資訊以證書的方式發回瀏覽器。瀏覽器驗證證書的正確性，或者使用者接收了不受信任的證書，瀏覽器會生成一串隨機的密碼，並用證書的公鑰加密，同時使...
HTTPS握手過程
加密方案 非對稱加密 ssl握手過程 伺服器發動 server hello done 的報文通知客戶端，最初階段的ssl握手協商結束。ssl第一次握手結束之後，客戶端解析證書 客戶端的tls完成 如果證書有問題，就發出警告。拿到服務端的公鑰。以 client key exchange 報文作為回應。...