1. 內(nèi)容加密

加密算法一般分為兩種，對稱加密和非對稱加密。所謂對稱加密（也叫密鑰加密）就是指加密和解密使用的是相同的密鑰。而非對稱加密（也叫公鑰加密）就是指加密和解密使用了不同的密鑰。

非對稱密鑰交換

在非對稱密鑰交換算法出現(xiàn)以前，對稱加密一個很大的問題就是不知道如何安全生成和保管密鑰。非對稱密鑰交換過程主要就是為了解決這個問題，使得對稱密鑰的生成和使用更加安全。
密鑰交換算法本身非常復雜，密鑰交換過程涉及到隨機數(shù)生成，模指數(shù)運算，空白補齊，加密，簽名等操作。
常見的密鑰交換算法有 RSA，ECDHE，DH，DHE 等算法。它們的特性如下：

• RSA：算法實現(xiàn)簡單，誕生于 1977 年，歷史悠久，經(jīng)過了長時間的破解測試，安全性高。缺點就是需要比較大的素數(shù)（目前常用的是 2048 位）來保證安全強度，很消耗 CPU 運算資源。RSA 是目前唯一一個既能用于密鑰交換又能用于證書簽名的算法。

• DH：diffie-hellman 密鑰交換算法，誕生時間比較早（1977 年），但是 1999 年才公開。缺點是比較消耗 CPU 性能。

• ECDHE：使用橢圓曲線（ECC）的 DH 算法，優(yōu)點是能用較小的素數(shù)（256 位）實現(xiàn) RSA 相同的安全等級。缺點是算法實現(xiàn)復雜，用于密鑰交換的歷史不長，沒有經(jīng)過長時間的安全攻擊測試。

• ECDH：不支持 PFS，安全性低，同時無法實現(xiàn) false start。

• DHE：不支持 ECC。非常消耗性能。

百度只支持 RSA 和 ECDH_RSA 密鑰交換算法。原因是：

1. ECDHE 支持 ECC 加速，計算速度更快。支持 PFS，更加安全。支持 false start，用戶訪問速度更快。

2. 目前還有至少 20% 以上的客戶端不支持 ECDHE，我們推薦使用 RSA 而不是 DH 或者 DHE，因為 DH 系列算法非常消耗 CPU（相當于要做兩次 RSA 計算）。
   

需要注意通常所說的 ECDHE 密鑰交換默認都是指 ECDHE_RSA，使用 ECDHE 生成 DH 算法所需的公私鑰，然后使用 RSA 算法進行簽名最后再計算得出對稱密鑰。
非對稱加密相比對稱加密更加安全，但也存在兩個明顯缺點：

1. CPU 計算資源消耗非常大。一次完全 TLS 握手，密鑰交換時的非對稱解密計算量占整個握手過程的 90% 以上。而對稱加密的計算量只相當于非對稱加密的 0.1%，如果應用層數(shù)據(jù)也使用非對稱加解密，性能開銷太大，無法承受。

2. 非對稱加密算法對加密內(nèi)容的長度有限制，不能超過公鑰長度。比如現(xiàn)在常用的公鑰長度是 2048 位，意味著待加密內(nèi)容不能超過 256 個字節(jié)。
   所以公鑰加密目前只能用來作密鑰交換或者內(nèi)容簽名，不適合用來做應用層傳輸內(nèi)容的加解密。

非對稱密鑰交換算法是整個 HTTPS 得以安全的基石，充分理解非對稱密鑰交換算法是理解 HTTPS 協(xié)議和功能的關鍵。
下面分別通俗地介紹一下 RSA 和 ECDHE 在密鑰交換過程中的應用。

• RSA 在密鑰交換過程中的應用
  RSA 算法的原理是乘法不可逆或者大數(shù)因子很難分解。RSA 的推導實現(xiàn)涉及到了歐拉函數(shù)和費馬定理及模反元素的概念，有興趣的讀者可以自行百度。
  RSA 算法是統(tǒng)治世界的最重要算法之一，而且從目前來看，RSA 也是 HTTPS 體系中最重要的算法，沒有之一。 下面用一個簡單的示例介紹一下 RSA 的神奇妙用。
  假設一個網(wǎng)站需要使用 HTTPS 協(xié)議，那么它首先就得申請數(shù)字證書，申請證書之前需要生成一對公鑰和私鑰，為了方便說明問題，假設 server 的密鑰長度只有 8 位，事實上現(xiàn)在的服務器證書至少是 2048 位長。

1. 隨機挑選兩個質(zhì)數(shù) p, q，使得 pq 接近 2 的 8 次方 = 256， 假設 p = 13, q = 19。n = pq = 13*19 = 247。

2. 挑選一個數(shù) e，滿足 1< e < (p-1)(q-1) 并且 e 與 (p-1)(q-1) 互質(zhì)，假設 e = 53。

3. 計算 e 關于 n 的模反元素 , ed≡1 (mod φ(n))， d =

   實際應用中，(n,e) 組成了公鑰對，（n,d）組成了私鑰對。公鑰一般都注冊到了證書里，任何人都能直接查看，比如百度證書的公鑰對如下圖，其中最末 6 個數(shù)字（010001）換算成 10 進制就是 65537，也就是公鑰對中的 e, 取值比較小的原因有兩個：

4. 減小 client 端的計算強度，特別是現(xiàn)在移動終端的計算能力比較弱，較小的公鑰使得 CPU 計算會更快。

5. 加大 server 端的破解難度。e 比較小，d 必然會非常大。所以 d 的取值空間也會非常大。

   

• ECDHE 算法在密鑰交換中的應用
  ECDHE 算法實現(xiàn)要復雜很多，依賴的數(shù)學原理主要是 ECC 橢圓曲線和離散對數(shù)。詳細概念不做說明，示例介紹一下。

對稱內(nèi)容加密

非對稱密鑰交換過程結(jié)束之后就得出了本次會話需要使用的對稱密鑰。對稱加密又分為兩種模式：流式加密和分組加密。流式加密現(xiàn)在常用的就是 RC4，不過 RC4 已經(jīng)不再安全，微軟也建議網(wǎng)站盡量不要使用 RC4 流式加密。
一種新的替代 RC4 的流式加密算法叫 ChaCha20，它是 google 推出的速度更快，更安全的加密算法。目前已經(jīng)被 android 和 chrome 采用，也編譯進了 google 的開源 openssl 分支---boring ssl，并且 nginx 1.7.4 也支持編譯 boringssl。
分組加密以前常用的模式是 AES-CBC，但是 CBC 已經(jīng)被證明容易遭受 BEAST 和 LUCKY13 攻擊。目前建議使用的分組加密模式是 AES-GCM，不過它的缺點是計算量大，性能和電量消耗都比較高，不適用于移動電話和平板電腦。

數(shù)據(jù)完整性

這部分內(nèi)容比較好理解，跟平時的 md5 簽名類似，只不過安全要求要高很多。openssl 現(xiàn)在使用的完整性校驗算法有兩種：MD5 或者 SHA。由于 MD5 在實際應用中存在沖突的可能性比較大，所以盡量別采用 MD5 來驗證內(nèi)容一致性。SHA 也不能使用 SHA0 和 SHA1，中國山東大學的王小云教授在 2005 年就宣布破解了 SHA-1 完整版算法。
微軟和 google 都已經(jīng)宣布 16 年及 17 年之后不再支持 sha1 簽名證書。

身份認證

身份認證主要涉及到 PKI 和數(shù)字證書。數(shù)字證書有兩個作用：

1. 身份授權。確保瀏覽器訪問的網(wǎng)站是經(jīng)過 CA 驗證的可信任的網(wǎng)站。

2. 分發(fā)公鑰。每個數(shù)字證書都包含了注冊者生成的公鑰。在 SSL 握手時會通過 certificate 消息傳輸給客戶端。

這里簡單介紹一下數(shù)字證書是如何驗證網(wǎng)站身份的，PKI 體系的具體知識不做詳細介紹。
證書申請者首先會生成一對密鑰，包含公鑰和密鑰，然后把公鑰及域名還有 CU 等資料制作成 CSR 格式的請求發(fā)送給 RA，RA 驗證完這些內(nèi)容之后（RA 會請獨立的第三方機構和律師團隊確認申請者的身份）再將 CSR 發(fā)送給 CA，CA 然后制作 X.509 格式的證書。

申請者拿到 CA 的證書并部署在網(wǎng)站服務器端，那瀏覽器發(fā)起握手接收到證書后，如何確認這個證書就是 CA 簽發(fā)的呢？怎樣避免第三方偽造這個證書？
答案就是數(shù)字簽名（digital signature）。數(shù)字簽名可以認為是一個證書的防偽標簽，目前使用最廣泛的 SHA-RSA 數(shù)字簽名的制作和驗證過程如下：

1. 數(shù)字簽名的簽發(fā)。首先是使用哈希函數(shù)對證書數(shù)據(jù)哈希，生成消息摘要，然后使用 CA 自己的私鑰對證書內(nèi)容和消息摘要進行加密。

2. 數(shù)字簽名的校驗。使用 CA 的公鑰解密簽名，然后使用相同的簽名函數(shù)對證書內(nèi)容進行簽名并和服務端的數(shù)字簽名里的簽名內(nèi)容進行比較，如果相同就認為校驗成功。

這里有幾點需要說明：

1. 數(shù)字簽名簽發(fā)和校驗使用的密鑰對是 CA 自己的公私密鑰，跟證書申請者提交的公鑰沒有關系。

2. 數(shù)字簽名的簽發(fā)過程跟公鑰加密的過程剛好相反，即是用私鑰加密，公鑰解密。

3. 現(xiàn)在大的 CA 都會有證書鏈，證書鏈的好處一是安全，保持根 CA 的私鑰離線使用。第二個好處是方便部署和撤銷，即如何證書出現(xiàn)問題，只需要撤銷相應級別的證書，根證書依然安全。

4. 根 CA 證書都是自簽名，即用自己的公鑰和私鑰完成了簽名的制作和驗證。而證書鏈上的證書簽名都是使用上一級證書的密鑰對完成簽名和驗證的。

5. 怎樣獲取根 CA 和多級 CA 的密鑰對？它們是否可信？當然可信，因為這些廠商跟瀏覽器和操作系統(tǒng)都有合作，它們的公鑰都默認裝到了瀏覽器或者操作系統(tǒng)環(huán)境里。比如 firefox 就自己維護了一個可信任的 CA 列表，而 chrome 和 IE 使用的是操作系統(tǒng)的 CA 列表。

文章標題：HTTPS 原理介紹
本文鏈接：http://aaarwkj.com/news/46460.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站營銷、用戶體驗、網(wǎng)站改版、做網(wǎng)站、企業(yè)網(wǎng)站制作、虛擬主機

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)