1. 引入
在 HTTP 協議 章節的 reference 段,曾提到過 HTTPS。這里對HTTPS進行詳細介紹。
HTTPS 是在 HTTP 的基礎上,引入了一個加密層 (SSL)。HTTP 是明文傳輸的 (不安全)。當下所見到的大部分網站都是 HTTPS 的。
起初是拜運營商劫持所賜(篡改 reference……)。但是,即使運營商 不劫持, 如果黑客盯上了, 也是可能會對你的信息安全造成一些影響的。舉個例子:黑客能否用自己的設備偽造一個 “商場 wifi” ,一旦你的數據經過了黑客的設備, 又沒有加密(HTTP 是明文), 就非常危險了,尤其是 “各種密碼之類的”。
解決安全問題,最核心的要點,就是"加密"。加密的成本很低,破解的成本很高。只要破解成本,超出了要保護的數據價值本身,就是安全的。eg:造一個100元的假鈔,成本花了110元
密碼學中的幾個重要概念:
-
明文:要傳輸的真實的數據,要表達的實際的意思。
-
密文:針對明文加密之后,得到的結果。往往是不直觀的,不易理解。
-
明文 變 密文 的過程 加密。
-
密文 變 明文 的過程 解密。
-
加密和解密的過程中,涉及到一個關鍵道具——稱為 密鑰 。
-
對稱加密 : 加密和解密,使用的是同一個密鑰。
-
非對稱加密 : 加密和解密,使用的是兩個密鑰。 這兩個密鑰,k1, k2, 是成對的。使用 k1 來加密,此時就是 k2 解密;也可以使用 k2 加密,此時就是 k1 解密(這個特性的背后有一系列的數學原理)。兩個密鑰,就可以一個公開出去,稱為 “公鑰”,另一個自己保存好,稱為 “私鑰”。手里只有一把的話,是無法知道另一把是什么的(也是有一定的數學原理的)
2. HTTPS 工作過程
只要針對 HTTPS 的數據進行解密了,就能夠得到 HTTP 格式的數據。
上述的運營商劫持,無論是修改 referer 還是修改返回的鏈接(body),本質上都是明文傳輸惹的禍。需要引入加密,對上述傳輸的數據進行保護,主要就是要針對 header 和 body 進行加密。
2.1 引入對稱加密
通過對稱加密的方式,針對傳輸的數據進行加密操作。
網絡上傳輸的內容就是密文了
- 對稱加密的時候,客戶端和服務器需要使用同一個密鑰。
- 不同的客戶端,需要使用不同的密鑰。(如果所有的客戶端密鑰都相同,加密形同虛設,黑客很容易拿到密鑰)
這就意味著,每個客戶端連接到服務器的時候,都需要自己生成一個隨機的密鑰,并且把這個密鑰告知服務器。(不一定非得是客戶端生成,由服務器生成后告訴給客戶端也行)。
這就是問題的關鍵, 密鑰需要傳輸給對方的。一旦黑客拿到了這個密鑰,意味著加密操作就無意義了。
需要考慮,針對密鑰,也進行密文傳輸,但是假設使用對稱加密,引入 key2 針對 key 進行加密,意味著,就需要把 key2 地傳輸給服務器,服務器才能解密拿到 key,還是可能被黑客拿到key2,然后知道 key,進而得到明文。
2.2 引入非對稱加密
使用非對稱加密,主要的目的是為了對對稱密鑰進行加密(確保對稱密鑰的安全性)。
不能使用非對稱加密,針對后續傳輸的各種 header body 等進行加密,而是只能使用非對稱加密去加密對稱密鑰。
非對稱加密的加密解密成本(消耗的 CPU 資源)要遠遠高于對稱加密。少用點,可以。如果大規模使用,就成本很大了。
可讓服務器生成公鑰 私鑰,私鑰只具備服務器自己知道、公鑰可以告訴任何人。由于公鑰本身就是可以公開的,不加密也無所謂,此處就讓服務器持有私鑰(只有服務器知道),客戶端持有公鑰(黑客也能知道)。
客戶端使用公鑰對生成的對稱密鑰進行加密,黑客雖然手里有公鑰,但是密文需要通過私鑰才能解密。黑客無法對這個數據解密,也就不能拿到 888888 對稱密鑰(黑客監聽中間的通信數據,要比黑人服務器這邊容易一些。如果能跟進服務器了,大概率就可以直接拖數據庫了,用戶啥信息都被拿到了)。
只要 888888 安全到達服務器,后續服務器和客戶端之間就可以使用 888888 作為對稱加密的密鑰,此時黑客就無法破解后續的數據了。
上述操作, 其實仍然存在嚴重的漏洞,黑客仍然有辦法破解掉其中的加密操作——中間人攻擊。
服務器可以創建出一對公鈾和私鈾, 黑客, 也可以按照同樣的方式, 創建出一對公鑰和私鑰
冒充自己是服務器(生成公鑰和私鑰的算法都是開放的,服務器能生成,黑客也能生成)。
客戶端拿到pub2 之后,無法區分 pub2 是否是服務器的,于是客戶端拿著pub2 就對 key 加密了。黑客就使用 pri2 對上述數據進行解密,因此黑客就拿到了 key。黑客繼續使用從服務器拿到的 pub1 重新對 key 進行加密,并且傳輸給服務器。服務器拿到數據之后, 使用 pri1 來解密,當然可以解密成功,于是服務器就知道了對稱密鑰是 key 了。
后續的通信, 服務器和客戶端之間仍然會繼續使用 key 作為加密的密鑰,此時后續傳輸的各種數據就都可以被黑客解密了。
2.3 證書
針對上述中間人攻擊問題,如何解決?
最關鍵的一點,客戶端拿到公鑰的時候,要能有辦法驗證,這個公鑰是否是真的,而不是黑客偽造的。
這要求服務器要提供一個"證書",證書是一個結構化的數據(里面包含很多屬性,最終以字符串的形式提供)。證書中會包含一系列的信息,比如:服務器的主域名、公鑰、證書有效期……
證書是搭建服務器的人,要從第三方的公正機構進行申請的(申請的時候當然要提交材料,人家要審核)
一個關鍵問題: 返回證書的時候證書數據也是經過了黑客的設備,此時黑客是否能夠改正書中的公鑰? 將公鑰替換成自己的公鑰呢?
答:不行,客戶端拿到證書之后,會先針對證書驗證真偽。
證書驗證的過程
假設這是一個證書,
證書:
服務器的域名: …
證書的有效時間: …
服務器的公鑰: …
公證機構信息: …
證書的簽名: …
頒布證書的公證機構會在發布證書的時候,給這個證書計算出一個校驗和。然后公證機構使用自己的私鑰(如服務器的私鑰無關),針對校驗和進行加密,此時就得到了證書的簽名。
市面上的公證機構一共也沒多少,這些公證機構持有自己的私鑰,對應的公鑰都包含在常見的系統中。windows 里面就內置了大量的公鑰,(如果沒有,也可以額外安裝)。前面安裝的 fiddler,有一步操作,就是安裝證書(主要就是安裝 fiddler 這邊提供的公鑰)。
此處所謂的"簽名"本質上是一個經過加密的校驗和,把證書中其他的字段通過一系列的算法(CRC, MD5 等),得到一個較短的字符串。=> 校驗和
如果兩份證書內容一樣,此時校驗和,就是相同的,如果校驗和不同,兩份數據的內容則一定不同。(逆否命題)
客戶端拿到證書之后,主要做兩件事:
- 按照同樣的校驗和算法,把證書的其他字段重新算一遍,得到校驗和1
- 使用系統中內容的公證機構公鑰,對證書中的簽名進行解密,得到校驗和2
此時,就可以對比,看這倆校驗和是否一致。如果一致,說明證書是沒有被修改過的,就是原版證書;如果不一致,說明證書被別人篡改過了。(比如黑客如果替換了自己的公鑰,此時算出來的校驗和一定發生改變),此時客戶端就能識別出來了。
證書主要是防止黑客篡改,而不是防止黑客知道,黑客的系統也內置了公證機構的公鑰
黑客也能解密,但是黑客無法修改證書的內容。
-
如果黑客直接修改 公鑰,不修改簽名。
此時,客戶端驗證的校驗和是一定不一樣的。就識別出來了。 -
如果黑客修改公鑰,也嘗試重新生成簽名,由于黑客不知道公證機構的私鑰,所以黑客無法重新生成加密的簽名;
如果黑客拿自己的私鑰加密,客戶端這邊拿著公證機構的公鑰也會解密失敗。
上述操作,就把黑客篡改證書的行為給堵死了。 -
黑客能不能自己去公證機構申請個證書?然后把自己的證書替換掉服務器的證書呢?
不行,域名是唯一的,黑客申請的證書的域名,和服務器的域名肯定不相同。客戶端拿到證書之后,一看域名都不一樣,直接就知道證書是假冒的了,都不用驗證校驗和了。
有時瀏覽器告訴用戶訪問的網站有風險,請謹慎訪問,可能是黑客進行了中間人攻擊,也可能是證書過期了。
當然,上述討論的過程,所謂的安全,也不是絕對的安全。上述的安全本質上都是基于非對稱加密體系。非對稱加密體系,也不是無懈可擊的。只不過破解這樣的加密體系,需要的計算量非常大,隨著算力的提升,尤其是量子計算機崛起,算力又會大幅度提升,對于現有的密碼學體系就會造成重大沖擊。