九個問題從入門到熟悉 HTTPS

2018-03-29 14:53

HTTP 協議中的內容都是明文傳輸,HTTPS 的目的是將這些內容加密,確保信息傳輸安全。最後一個字母 S 指的是 SSL/TLS 協議,它位於 HTTP 協議與 TCP/IP 協議中間。

 

Q2: 你說的信息傳輸安全是什麼意思

BS: 信息傳輸的安全有三個方面:

 

  1. 客戶端和浙江11选五5直接的通信只有自己能看懂,即使第三方拿到數據也看不懂這些信息的真實含義。
  2. 第三方雖然看不懂數據,但可以 XJB 改,因此客戶端和浙江11选五5必須有能力判斷數據是否被修改過。
  3. 客戶端必須避免中間人攻擊,即除了真正的浙江11选五5,任何第三方都無法冒充浙江11选五5。

 

很遺憾的是,目前的 HTTP 協議還不滿足上述三條要求中的任何一條。

 

Q3: 這麼多要求,一個一個去滿足是不是很累?

BS: 不累,第三個要求可以不用管

 

是的,我沒開玩笑,你可以暫時別管第三個要求,因爲它實際上隸屬於第一個需求。我們都知道加密需要密碼,密碼不是天下掉下來,也得需要雙方經過通信才能協商出來。所以一個設計良好的加密機制必然會防止第三者的干擾和僞造。等搞明白了加密的具體原理,我們自然可以檢驗是否滿足:“任何第三者无法冒充服务器”这一要求。

 

Q4: 那怎么加密信息呢

BS: 使用對稱加密技術

 

對稱加密可以理解爲對原始數據的可逆變換。比如 Hello 可以变换成 Ifmmp,規則就是每個字母變成它在字母表上的後一個字母,這裏的祕鑰就是 1,另一方拿到 Ifmmp 就可以还原成原来的信息 Hello 了。

引入對稱加密後,HTTPS 的握手流程就會多了兩步,用來傳遞對稱加密的祕鑰:

 

  • 客戶端: 你好,我需要發起一個 HTTPS 請求
  • 浙江11选五5: 好的,你的祕鑰是 1。

 

提到了對稱加密,那麼自然還有非對稱加密。它的思想很簡單,計算兩個質數的乘積很容易,但反過來分解成兩個質數的乘積就很難,要經過極爲複雜的運算。非對稱加密有兩個祕鑰,一個是公鑰,一個是私鑰。公鑰加密的內容只有私鑰可以解密,私鑰加密的內容只有公鑰可以解密。一般我們把浙江11选五5自己留着,不對外公佈的密鑰稱爲私鑰,所有人都可以獲取的稱爲公鑰。

 

使用對稱加密一般要比非對稱加密快得多,對浙江11选五5的運算壓力也小得多。

 

Q5: 對稱祕鑰如何傳輸

 

浙江11选五5直接返回明文的對稱加密密鑰是不是不安全。如果有監聽者拿到這個密鑰,不就知道客戶端和浙江11选五5後續的通信內容了麼?

 

BS: 利用非對稱加密

 

是這樣,所以不能明文傳遞對稱祕鑰,而且也不能用一個新的對稱加密算法來加密原來的對稱祕鑰,否則新的對稱祕鑰同樣無法傳輸,這就是雞生蛋、蛋生雞的悖論。

 

這裏我們引入非對稱加密的方式,非對稱加密的特性決定了浙江11选五5用私鑰加密的內容並不是真正的加密,因爲公鑰所有人都有,所以浙江11选五5的密文能被所有人解析。但私鑰只掌握在浙江11选五5手上,這就帶來了兩個巨大的優勢:

 

  1. 浙江11选五5下發的內容不可能被僞造,因爲別人都沒有私鑰,所以無法加密。強行加密的後果是客戶端用公鑰無法解開。
  2. 任何人用公鑰加密的內容都是絕對安全的,因爲私鑰只有浙江11选五5有,也就是隻有真正的浙江11选五5可以看到被加密的原文。

 

所以傳輸對稱祕鑰的問題就迎刃而解了: 祕鑰不是由浙江11选五5下發,而是由客戶端生成並且主動告訴浙江11选五5。

所以當引入非對稱加密後,HTTPS 的握手流程依然是兩步,不過細節略有變化:

 

客戶端: 你好,我需要發起一個 HTTPS 請求,這是我的 (用公鑰加密後的) 祕鑰。

浙江11选五5: 好的,我知道你的祕鑰了,後續就用它傳輸。

 

Q5: 那公鑰怎麼傳輸

 

你好像還是沒有解決雞生蛋,蛋生雞的問題。你說客戶端發送請求時要用公鑰加密對稱祕鑰,那公鑰怎麼傳輸呢?

 

BS: 對公鑰加密就行了。。。

 

每一個使用 HTTPS 的浙江11选五5都必須去專門的證書機構註冊一個證書,證書中存儲了用權威機構私鑰加密的公鑰。這樣客戶端用權威機構的公鑰解密就可以了。

 

現在 HTTPS 協議的握手階段變成了四步:

 

  1. 客戶端: 你好,我要發起一個 HTTPS 請求,請給我公鑰
  2. 浙江11选五5: 好的,這是我的證書,裏面有加密後的公鑰
  3. 客戶端: 解密成功以後告訴浙江11选五5: 這是我的 (用公鑰加密後的) 對稱祕鑰。
  4. 浙江11选五5: 好的,我知道你的祕鑰了,後續就用它傳輸。

 

Q6: 你在逗我么。。。。

 

那權威機構的公鑰又怎麼傳輸?

 

BS: 存在电脑里

 

這個公鑰不用傳輸,會直接內置在各大操作系統(或者瀏覽器)的出廠設置裏。之所以不把每個浙江11选五5的公鑰內置在電腦裏,一方面是因爲浙江11选五5太多,存不過來。另一方面操作系統也不信任你,憑什麼你說你這個就是百度/淘寶的證書呢?

 

所以各個公司要先去權威機構認證,申請證書,然後操作系統只會存儲權威機構的公鑰。因爲權威機構數量有限,所以操作系統廠商相對來說容易管理。如果這個權威機構不夠權威,XJB 發證書,就會取消他的資格,比如可憐的沃通。。。。

 

Q7: 怎麼知道證書有沒有被篡改?

 

你說浙江11选五5第一次會返回證書,也就是加密以後的公鑰,那我怎麼知道這個證書是可靠的?

 

BS: 將信息 hash 值隨着信息一起傳遞

 

我們都知道哈希算法的特點,它可以壓縮數據,如果從函數角度來看,不管多複雜的數據(定義域可以非常大)經過哈希算法都會得到一個值,而且這個值處在某個特定(遠小於定義域的範圍)值域內。相同數據的哈希結果一定相同,不相同數據的哈希結果一般不同,不過也有小概率會重複,這叫哈希衝突。

 

爲了確保原始證書沒有被篡改,我們可以在傳遞證書的同時傳遞證書的哈希值。由於第三者無法解析數據,只能 XJB 改,那麼修改後的數據在解密後,就不可能通過哈希。

 

比如說公鑰就是之前的例子 Hello,我們假設哈希算法是獲取字符串的最後一個字符,那麼 Hello 的哈希值就是 o,所以加密字符串是 Ifmmpp。雖然公鑰已知,每個人都可以解密,解密完也可以篡改,但是因爲沒有私鑰, 所以無法正確的加密。所以它再返回給客戶端的數據是無效數據,用公鑰解析後會得到亂碼。即使攻擊者通過多次嘗試碰巧能夠解析,也無法通過哈希校驗。

 

Q8: 这样可以防止第三方冒充服务器么

BS: 也許可以

 

首先真正的浙江11选五5下發的內容,無法被別人篡改。他們有權威機構的公鑰,所以可以解密,但是因爲沒有私鑰,所以解密以後的信息無法加密。沒有加密或者錯誤加密的信息被客戶端用公鑰解密以後,必然無法通過哈希校驗。

 

但是,如果你一開始請求的就不是真的浙江11选五5,而是一個攻擊者,此時的他完全有機會進行中間人攻擊。我們知道第一次握手的時候浙江11选五5會下發用於證明自己身份的證書,這個證書會用預設在設備上的公鑰來解密。所以要麼是經過認證的證書用權威機構的私鑰加密,再用權威機構解密,要麼是用非權威機構的私鑰加密,然後找不到公鑰解密。

 

所以如果不小心安裝過非權威機構的根證書,比如黑客提供的惡意證書,這時候設備上就多了一個預設的公鑰,那麼用惡意私鑰加密的證書就能被正常解析出來。所以千萬不要隨便裝根證書,這等於是爲那些惡意證書留了一扇門。

 

當然,凡是都有兩面性。我們知道 Charles 可以調試 HTTPS 通信,它的原理就是需要用戶安裝 Charles 的根證書,然後我們的請求會被代理到 Charles 浙江11选五5,它下發的 Charles 證書才能被正確解析。另一方面,Charles 會作爲客戶端,從真正的浙江11选五5哪裏拿到正確的 https 證書並用於後續通信。幸好 Charles 不是流氓軟件,或者它的私鑰一旦泄露,對用戶都會造成很大的影響。

 

我可以舉一個例子,證書有多個種類,最貴的叫 EV (Extended Validation),它需要公司營業執照等多個文件才能申請人工審覈,好處也很明顯,可以在瀏覽器地址欄左側準確顯示公司名稱,比如 Bitbucket 的官网:

 

 

 

代理模式下無法顯示

Q9: HTTPS 握手會影響性能麼

TCP 有三次握手,再加上 HTTPS 的四次握手,會不會影響性能?

BS: 影響肯定有,但是可以接受

首先,HTTPS 肯定會更慢一點,時間主要花費在兩組 SSL 之間的耗時和證書的讀取驗證上,對稱算法的加解密時間幾乎可以忽略不計。

而且如果不是首次握手,後續的請求並不需要完整的握手過程。客戶端可以把上次的加密情況直接發送給浙江11选五5從而快速恢復,具體細節可以參考 图解SSL/TLS协议。

除此以外,SSL 握手的時間並不是只能用來傳遞加密信息,還可以承擔起客戶端和浙江11选五5溝通 HTTP2 兼容情況的任務。因此從 HTTPS 切換到 HTTP2.0 不會有任何性能上的開銷,反倒是得益於 HTTP2.0 的多路複用等技術,後續可以節約大量時間。

如果把 HTTPS2.0 當做目標,那麼 HTTPS 的性能損耗就更小了,遠遠比不上它帶來的安全性提升。

結語

 

相信以上九個問題足夠幫助新人瞭解 HTTPS 了,但這只是基本概念,關於 HTTPS 的使用(比如 iOS 上的一些具體問題)還需要不斷嘗試和研究。

 

本文來自於簡書 

鏈接:www.jianshu.com/p/072a657337ae