刨根問底系列之https究竟是如何防篡改的？面試必備

1.前言

https是一個老生常談的話題了，也是面試過程種常常甚至必然會問到的一個問題 但當問到https爲何安全的時候，不少人的回答就是簡單的回一句：由於他加密了！而後就沒而後了！你也至關於啥都沒回答出來！

2.我爲何要寫這篇文章呢？

1.網上的文章有的不太全面或者不易懂，有的甚至理解有誤差，有可能會給學習的人形成更多的疑惑

2.由於發文章有積分呀！

好，閒言少敘 進入正題

3.說https以前，先說一下http爲何不安全，體如今哪裏？怎麼演示出來？

你們都知道，http是明文傳輸，可是也有很多人這樣想：雖然是明文傳輸，但我也沒遇到什麼不安全的問題呀，因此我也不必搞https！

我只能給出如下幾點解釋

1.你很幸運，沒被盯上

2.你的網站沒啥流量，搞你沒啥價值

3.你的帳號密碼等隱私信息已經被竊取，而你依然渾然不知

接下來我給你們演示一下http爲何不安全

你們都鏈接過公共wifi吧，這裏我就用電腦開個熱點，而後用手機鏈接熱點，而後用手機訪問一個http的登陸界面，並輸入帳號密碼登陸，我在電腦用wireshark抓包

第一步：電腦開啓熱點，並打開wireshark準備抓包

第二步：手機鏈接熱點

第三步：手機訪問登陸頁並登陸

第四步：查看電腦抓的包

問題是否是很明白了，你的帳號密碼都是明文傳輸的（密碼是由於前端md5以後傳的），中間的wifi（準確說是路由器）是直接能夠截取查看的，能截取查看，是否是就能夠篡改？答案固然是確定的

如今試想一下，若是你鏈接的wifi甚至你本地的運營商就有問題（爲了利益），那他是否是就能夠隨心所欲了

好比:

1.竊取你的隱私信息

2.修改服務端返回的信息，加入一個js廣告文件，此時廣告就滿天飛了

3.修改服務端返回信息，直接給你重定向到釣魚或者廣告網站，想想你有沒有遇到過相似狀況：你打開的百度，卻跳轉到了一個」你懂的「的網站

4.修改服務端返回信息，你忽然發現你平時訪問的網站角落裏忽然出現了個「特別吸引眼球的美女」

說到這，是否是足以說明http自己確實存在安全性問題。若是你的回答依然是否認的，建議多看幾遍上面的內容，給本身洗洗腦！

4.https爲何就安全了？他是怎麼保證安全的？

想到安全，你們首先會想到，那就加密唄！因此引來第一個問題，如何加密 在介紹如何加密問題前，先簡單介紹一下加密的大體種類

加密的大體種類：

1. 不可逆加密。 好比 MD五、SHA、HMAC

   典型用途： 密碼總不能明文存到數據庫吧，因此通常加密存起來，只要用戶的輸入通過一樣的加密算法 對比一下就知道密碼是否正確了，因此不必可逆

2. 可逆加密
   • 對稱加密。好比：AES、DES、3DES、IDEA、RC四、RC五、RC6

     典型用途： 用同一個密碼加密和解密，太常見了，我用密碼加密文件發給你，你只能用個人密碼才能解開

   • 非對稱加密（就是公私鑰）。好比：RSA、DSA、ECC

     典型用途： 1.加密（保證數據安全性）使用公鑰加密，需使用私鑰解密。 2.認證（用於身份判斷）使用私鑰簽名，需使用公鑰驗證簽名。

介紹完加密種類，接下來講說如何加密

用不可逆加密可行嗎？

首先不可逆加密的是否是能夠直接排除了，不知道爲啥的，能夠想想本身的目的是什麼哈，若是還不知道，能夠打120了

用對稱加密可行嗎？

若是通訊雙方都各自持有同一個密鑰，且沒有別人知道，這兩方的通訊安全固然是能夠被保證的,然而最大的問題就是這個密鑰怎麼讓傳輸的雙方知曉，同時不被別人知道,想想：是否是無論怎麼傳，中間都有可能被截獲，密鑰都被截獲了，其餘的安全是否是也就無從談起了。看來純粹的對稱加密不能解決http的安全問題

用非對稱加密（rsa）可行嗎？

試想一下：若是服務器生成公私鑰，而後把公鑰明文給客戶端（有問題，下面說），那客戶端之後傳數據用公鑰加密，服務端用私鑰解密就好了，這貌似能保證瀏覽器到服務端的通道是安全的，那服務端到瀏覽器的通道如何保證安全呢？

那既然一對公私鑰能保證，那若是瀏覽器自己也生成一對公私鑰匙，而後把公鑰明文發給服務端，拋開明文傳遞公鑰的問題，那之後是否是能夠安全通訊了，的確能夠！但https自己卻不是這樣作的，最主要的緣由是非對稱加密很是耗時，特別是加密解密一些較大數據的時候有些力不從心，固然還有其餘緣由。既然非對稱加密很是耗時，那隻能再考慮對稱加密了

用非對稱加密 + 對稱加密可行嗎？（行也得行，不行也得行，由於也沒有其餘方式了）

上面提到瀏覽器擁有服務器的公鑰，那瀏覽器生成一個密鑰，用服務器的公鑰加密傳給服務端，而後服務端和瀏覽器之後拿這個密鑰以對稱加密的方式通訊不就行了！完美！

因此接下來講一下上面遺留的一個問題：服務端的公鑰是明文傳過去的，有可能致使什麼問題呢？

若是服務端在把明文公鑰傳遞給瀏覽器的時候，被黑客截獲下來，而後把數據包中的公鑰替換成本身僞造的公鑰（固然他本身有本身的私鑰），瀏覽器自己是不知道公鑰真假的，因此瀏覽器仍是傻傻的按照以前的步驟，生成對稱密鑰，而後用假的公鑰加密傳遞給服務端，這個時候，黑客截獲到報文，而後用本身的私鑰解密，拿到其中的對稱密鑰，而後再傳給服務端，就這樣神不知鬼不覺的，對稱密鑰被黑客截取，那之後的通訊其實就是也就全都暴露給黑客了。

臥槽，這也不行，那也不行，到底咋辦？

淡定的考慮一下，上面的流程到底哪裏存在問題，以至使黑客能夠任意冒充服務端的公鑰！ 其實根本緣由就是瀏覽器沒法確認本身收到的公鑰是否是網站本身的

如何保證瀏覽器收到的公鑰必定是該網站的公鑰

現實生活中，若是想證實某身份證號必定是小明的，怎麼辦？看身份證。這裏國家機構起到了「公信」的做用，身份證是由它頒發的，它自己的權威能夠對一我的的身份信息做出證實。互聯網中能不能搞這麼個公信機構呢？給網站頒發一個「身份證」？固然能夠，這就是平時常常說的數字證書

什麼是數字證書?證書都包含什麼?

身份證之因此可信，是由於背後是國家，那數字證書如何纔可信呢？這個時候找CA（Certificate Authority）機構。辦身份證須要填寫本身的各類信息，去CA機構申請證書須要什麼呢？至少應該有如下幾項吧

1. 網站域名
2. 證書持有者
3. 證書有效期
4. 證書頒發機構
5. 服務器公鑰（最主要）
6. 接下來要說的簽名時用的hash算法

那證書如何安全的送達給瀏覽器，如何防止被篡改呢？給證書蓋個章（防僞標記）不就行了，這就又引出另一個概念：數字簽名

什麼是數字簽名？簽名的過程是什麼

簽名的過程其實也很簡單

1. CA機構擁有非對稱加密的私鑰和公鑰
2. CA對證書明文信息進行hash
3. 對hash後的值用私鑰加密，獲得數字簽名

因此呢，總結一下：CA機構頒發的證書包含（證書內容的明文+簽名）

瀏覽器收到服務下發的證書以後，拿到證書明文和簽名，怎麼驗證是否篡改了呢？

你們知道，私鑰簽名，公鑰驗籤。證書裏面的簽名是CA機構用私鑰簽名的，因此我只要用CA機構的公鑰驗證一下簽名不就行了，怎麼驗證呢？

還記得證書裏面的明文包含什麼吧，不記得的話看看上面的內容。

1. 拿到證書裏面明文的hash算法並對明文內容進行hash運算，獲得A
2. 用CA的公鑰解密簽名獲得B
3. 比較A 和 B，若是相等，說明沒有被篡改，不然瀏覽器提示證書不可信

有沒有發現一個問題？CA的公鑰從哪裏獲取呢

這個簡單，CA權威機構原本也沒多少個，因此，瀏覽器內部都內置了各大CA機構的公鑰信息

簡單總結一下

1.若是證書被篡改，瀏覽器就提示不可信，終止通訊，若是驗證經過，說明公鑰沒問題，必定沒被篡改

2.公鑰沒被篡改，那瀏覽器生成的對稱加密用的密鑰用公鑰加密發送給服務端，也只有服務端的私鑰能解開，因此保證了 對稱密鑰不可能被截獲，對稱密鑰沒被截獲，那雙方的通訊就必定是安全的

3.黑客依然能夠截獲數據包，可是全都是通過對稱加密的密鑰加密的，他也能夠篡改，只是沒有任何意義了,黑客也不會作吃力不討好的事了

結語

固然，https自己的加密流程比上面說的還要複雜一些，但主流程大體相同 下次面試再被問到https爲何安全時，不要再簡單的說 」由於加密了「，這是一個很能體現能力的問題，不要浪費掉。 以上是我的的一些理解：我能自圓其說，但並不保證必定是對的，請讀者自行診斷

幾個問題

1. 爲何charles等抓包工具或者瀏覽器控制檯看到的https返回是明文的？
2. 爲何製做數字簽名時須要hash一次？

若是知道的話，能夠留言討論，不知道的話也可自行搜索，固然，你也能夠關注我接下來的一篇刨根問底系列文章之https的詳細握手過程，拜拜！