簡單粗暴系列之HTTPS原理
一、開篇
簡單粗暴，本文來聊聊HTTPS。
啥是HTTPS? 說白了就是HTTP Over SSL。HTTP呢，就是我們平時上網時，瀏覽器和服務器之間傳輸數據的一項協議。普通情況下，瀏覽器發送的請求會經過若干個網絡中間節點，最後到達服務器；然後服務器又將請求的數據經過若干個網絡中間節點發送回給瀏覽器，這時候瀏覽器就能夠顯示我們想要看到的頁面。
這個過程中，其實並沒有存在什麼太大的問題。問題出在，如果我們需要在網頁上輸入一些敏感信息，如我們的銀行卡賬號和密碼，發送給服務器，就會在中間節點中存在泄漏的風險。HTTPS就是爲了保障傳輸過程中的安全目的而生的。HTTPS保證了數據僅僅只在發送方和目的方雙方可見，而對中間任一一個節點都不可見。這是怎麼實現的？我們來慢慢看。
二、故事
我們首先來看一個故事：
1）流程
有兩個大師，他們需要經常交流研究心得，因此需要頻繁地進行相互信件往來。在信件往來的過程中，我們假設發送方是大師A，而目的方是大師B。A想告訴B一些研究的最新成果，於是將相關的研究成果寫成了一封信，從郵局郵寄給B。這封信通過郵局的若干個快遞員，最終到達了B的手裏。這樣就形成了一個最典型的數據傳輸過程。
2）加密、解密、密鑰、加密算法
現在，大師A覺得，我寫的這封信，要是哪個快遞員打開看過了，我的最新研究成果不就泄漏了嗎？要是這個快遞員拿去賣錢我半輩子努力不就白費了？於是乎大師A就想了個辦法，在書寫的過程中，每個字符都加4。如字符A就寫成E，字符B就寫成F，以此類推。大師B收到了信件後，再把每個字符都減去4，這樣就可以正確得到大師A想傳遞的研究成果的內容。而最重要的是，即使快遞員在中間拆開信件，如果不知道4這個數字，是無法正確的到信件內容的。
我們將大師A每個字符加4的過程，叫做“加密”；大師B每個字符減4的過程，叫做“解密”；而數字4，就是我們常說的密鑰。而這種加密算法，名爲凱撒算法。
3）證書
就這樣，平安地度過了一段時間，直到突然有一天大師B收到一封來自於大師A的信，但是大師B使用之前的方式怎麼也明白不了大師A說的是什麼。於是電話詢問大師A關於這封信的內容。結果大師A說，這不是我寫的啊。這才發現，大師B收到的是一封僞造大師A的來信。爲防止以上事情再次發生，大師A與大師B商量說，以後每封信上，我都會簽上自己特有的簽名，並帶上相關內容的HASH值。
HASH值用來校驗這封信是否有被篡改過，而簽名類似於指紋，用來標示這封信是否真實來自於指紋上所指向的人。一般來說，簽名的內容中會包含這封信的發件方地址等信息。大師B收到信件後第一時間通過內容的HASH值來校驗信件的內容長度；通過簽名來校驗發件方地址和指紋信息是否匹配。只有全部匹配才繼續用之前的密鑰進行解密操作。
這些標明瞭大師A身份信息等信息的簽名，就是我們常說的證書。
經過以上的故事，我們大致明白了密鑰、加密解密、算法等必要的知識了。而HTTPS的過程其實和這個類似，只不過多了一些數學的描述。
三、HTTPS工作原理
HTTPS工作在客戶端和服務器端之間。以上故事中，客戶端可以看作爲大師A，服務器端可以看作爲大師B。客戶端和服務器本身都會自帶一些加密的算法，用於雙方協商加密的選擇項。
1、客戶端首先會將自己支持的加密算法，打個包告訴服務器端。
2、服務器端從客戶端發來的加密算法中，選出一組加密算法和HASH算法（注，HASH也屬於加密），並將自己的身份信息以證書的形式發回給客戶端。而證書中包含了網站的地址，加密用的公鑰，以及證書的頒發機構等；
這裏有提到公鑰的概念是故事中沒有的。我們常見的加密算法一般是一些對稱的算法，如凱撒加密；對稱算法即加密用的密鑰和解密用的密鑰是一個。如故事中的密鑰是4。還有一種加密解密算法稱之爲非對稱算法。這種算法加密用的密鑰（公鑰）和解密用的密鑰（私鑰）是兩個不同的密鑰；通過公鑰加密的內容一定要使用私鑰才能夠解密。
這裏，服務器就將自己用來加密用的公鑰一同發還給客戶端，而私鑰則服務器保存着，用戶解密客戶端加密過後的內容。
3、客戶端收到了服務器發來的數據包後，會做這麼幾件事情：
1）驗證一下證書是否合法。一般來說，證書是用來標示一個站點是否合法的標誌。如果說該證書由權威的第三方頒發和簽名的，則說明證書合法。
2）如果證書合法，或者客戶端接受和信任了不合法的證書，則客戶端就會隨機產生一串序列號，使用服務器發來的公鑰進行加密。這時候，一條返回的消息就基本就緒。
3）最後使用服務器挑選的HASH算法，將剛纔的消息使用剛纔的隨機數進行加密，生成相應的消息校驗值，與剛纔的消息一同發還給服務器。
4、服務器接受到客戶端發來的消息後，會做這麼幾件事情：
1）使用私鑰解密上面第2）中公鑰加密的消息，得到客戶端產生的隨機序列號。
2）使用該隨機序列號，對該消息進行加密，驗證的到的校驗值是否與客戶端發來的一致。如果一致則說明消息未被篡改，可以信任。
3）最後，使用該隨機序列號，加上之前第2步中選擇的加密算法，加密一段握手消息，發還給客戶端。同時HASH值也帶上。
5、客戶端收到服務器端的消息後，接着做這麼幾件事情：
1）計算HASH值是否與發回的消息一致
2）檢查消息是否爲握手消息
6、握手結束後，客戶端和服務器端使用握手階段產生的隨機數以及挑選出來的算法進行對稱加解密的傳輸。
爲什麼不直接全程使用非對稱加密算法進行數據傳輸？這個問題的答案是因爲非對稱算法的效率對比起對稱算法來說，要低得多得多；因此往往只用在HTTPS的握手階段。
以下是我們一些經常使用的加密算法，是不是有熟悉的味道？
非對稱加密算法：RSA, DSA/DSS
對稱加密算法： AES, 3DES
HASH算法：MD5, SHA1, SHA256
這就是HTTPS的基本原理，如果沒有簡單粗暴，請告訴我，以幫助我持續改進；如果真的簡單粗暴，請告訴有需要的人，大家共同進步。