數字簽名，數字證書，HTTPS

前言

衆所周知https和http相比更加安全一些，是由於https通過了加密。可是https具體是怎樣進行加密來對抗通訊過程當中的各類劫持和篡改呢。它又是怎樣站在用戶的角度保障用戶訪問的頁面是安全的，站在網站的角度一樣會保障網站不會被惡意攻擊。想經過這篇文章大概進行一些梳理。將圍繞如下兩點進行分析：

• 加密的方式
• 加密在具體應用場景中體現出來的安全性

加密的方式

加密有兩種算法：對稱加密和非對稱加密

• 對稱加密：加密和解密的密鑰同樣，好比用123456來加密就用123456進行解密。密碼也都是以數據的形式在網絡中進行傳輸的，這樣的話一旦123456被泄露，中間人截取了這個請求，加密就會直接被攻破。
• 非對稱加密：把密鑰分爲公鑰和私鑰，公鑰是公開的全部人均可以認領，私鑰是保密的只有一我的知道。大部分狀況下，公鑰的做用是對內容自己加密，保證不被其餘人看到。私鑰的做用是證實內容的來源是否可信，公鑰和私鑰是配對關係，公鑰加密就用私鑰解密，反之亦然。接下來咱們逐層的去分析這個加密的過程。

Level 1

A要給B發一封郵件，不想讓其餘人知道郵件內容，因而用B的公鑰對內容進行加密後發送，B在收到郵件後用本身的B私鑰進行解密。這樣一來即便中途這封郵件被中間人攔截，這個中間人沒有B的私鑰也只能獲得一堆亂碼，毫無心義。

可是這樣通訊的問題是B天天會收到各類各樣的郵件，它沒法區分郵件的來源。若是有黑客冒充A的身份，也用B的公鑰加密了一封郵件發送（前面說過公鑰是全部人均可以認領的），此時B解密後的獲得的郵件其實並非A真實的訴求內容。爲了可以區分郵件的來源，A和B換了一種通訊方式：

A爲了保證B收到的郵件都是本身本人發送的，因而用A私鑰加密內容而後發送，B接收的時候用A公鑰解密。這樣因爲A私鑰的惟一性能夠保證只有A能處理這封郵件。可這樣顯然是不妥的，由於A公鑰的公開性，任何劫持到郵件的中間人均可以知道郵件內容了。

顯然，這種單方面用公鑰或是私鑰加密行爲不管怎樣都會出現漏洞，因此他們引入了數字簽名來進行進階版的加密傳輸，也就是Level 2。

Level 2 （數字簽名）

既然用公鑰活私鑰來傳輸都有漏洞，那就把公鑰和私鑰結合起來使用。A先把郵件用A私鑰加密一次，再用B公鑰加密一次，兩層加密後發送。B在收到郵件後先用B私鑰進行解密，再用A公鑰進行解密。這樣一來，中間人既沒有B的私鑰去破解郵件內容，也沒有A的私鑰去冒充A的身份。這個傳輸過程顯然比Level 1更加嚴謹。可是這樣有一個弊端：

對文件自己加密多是個耗時過程，好比這封郵件足夠大，那麼用A私鑰加密整個文件以及拿到文件後的解密無疑是巨大的開銷。其實A私鑰的此次加密只是爲了證實信息來源是否可信，因此大可沒必要對所有內容進行加密。因而A先對整個文章執行哈希運算獲得一個hash值。針對這個hash值用A私鑰加密，附加到郵件的後面。這就是咱們常說的數字簽名了。而後再把全部內容用B公鑰進行加密後發送。

B收到郵件後的步驟：首先用B私鑰進行解密，獲得郵件內容和A的數字簽名。再用A公鑰解密數字簽名獲得hash值1。最後B對郵件內容執行一次哈希運算也獲得一個hash值2。用這個hash值2對比數字簽名的hash值1，若是同樣就說明文件內容沒有被篡改過，近乎完美又不失性能。

但是即使這樣，依然是有漏洞的。若是中間人C就是想作點壞事，他能夠去B的電腦上把A公鑰悄悄換成本身的C公鑰（畢竟公鑰是有公開性的，人人能夠拿到）。接下來生成本身的數字簽名。B那邊接收的時候層層校驗都會經過。最後C仍然能夠冒充A的身份去欺騙B。

這種防不勝防的感受是否是有點崩潰，堅持一下，就要差最後一步就要成功了。如今咱們整個加密，傳輸環環相扣。惟一的問題就出在了A公鑰太容易被替換了。那怎樣來保障A公鑰呢，就是咱們接下來要說的數字證書了。

Level 3 (數字證書)

A要保護本身的A公鑰進而保護傳輸的安全性，首先A去找"證書中心"（certificate authority，簡稱CA）爲A公鑰作認證。證書中心用本身的私鑰，對A公鑰和一些相關信息一塊兒加密，生成"數字證書"。而後A發給B的郵件後面除了數字簽名還會加上這個數字證書。

B接受到之後首先用CA獲得公鑰解密校驗數字證書，獲得A的公鑰，拿到A的公鑰後的解密步驟就和Level 2同樣了。

這樣下來A公鑰多了一層加密程序。想要在A公鑰上動手腳除非拿到CA的私鑰。CA的私鑰就成了如今的安全漏洞了。若是中間人如今又拿到了CA的私鑰怎麼辦呢。

他拿不到！CA是一個頗有權威的社會機構了，能夠默認它的私鑰是不會泄露的，若是有一天CA私鑰泄露了應該會後果不堪設想。至此，就真的完美了。

加密在具體應用場景中體現出來的安全性

大概捋順了加密的過程，可是在用戶訪問咱們的網站的時候面對大量的請求，具體是怎樣校驗這些請求是否包含惡意請求的。用戶又怎麼避免訪問到惡意網站呢

暫時沒捋清楚，後面及時來更新哈哈哈。