HTTPS協(xié)議和原理

1、HTTPS協(xié)議和原理2015/05/05 - IT 技術(shù) HTTP, HTTP弦全,百度1前言百度已經(jīng)于近日上線了全站 HTTPS的安全搜索，默認(rèn)會將 HTTP請求跳轉(zhuǎn)成HTTPS本 文重點介紹HTTPS協(xié)議，并簡單介紹部署全站 HTTPS的意義。HTTPS協(xié)議概述HTTPS可以認(rèn)為是HTTP + TLSo HTTP協(xié)議大家耳熟能詳了，目前大部分 WEB應(yīng)用和網(wǎng) 站都是使用HTTP協(xié)議傳輸?shù)摹LS是傳輸層加密協(xié)議，它的前身是 SSL協(xié)議，最早由netscape 公司于1995年發(fā)布, 1999年經(jīng)過IETF討論和規(guī)范后，改名為 TLSo如果沒有特別說明，SSL和TLS說的都 是同一個協(xié)議。H

2、TTP和TLS在協(xié)議層的位置以及TLS協(xié)議的組成如下圖：圖1 TLS協(xié)議格式TLS協(xié)議主要有五部分：應(yīng)用數(shù)據(jù)層協(xié)議，握手協(xié)議，報警協(xié)議，加密消息確認(rèn)協(xié)議，心 跳協(xié)議。TLS協(xié)議本身又是由record 協(xié)議傳輸?shù)?，record協(xié)議的格式如上圖最右所示。目前常用的HTTP協(xié)議是HTTP1.1,常用的TLS協(xié)議版本有如下幾個：TLS1.2, TLS1.1, TLS1.0和SSL3.0。其中SSL3.0由于POODLE攻擊已經(jīng)被證明不安全，但統(tǒng)計發(fā)現(xiàn)依然 有不到1%的瀏覽器使用 SSL3.0。TLS1.0也存在部分安全漏洞，比如 RC4和BEAST攻 擊。TLS1.2和TLS1.1暫時沒有已知的安全漏

3、洞，比較安全，同時有大量擴展提升速度和性 能，推薦大家使用。需要關(guān)注一點的就是 TLS1.3將會是TLS協(xié)議一個非常重大的改革。不管是安全性還是 用戶訪問速度都會有質(zhì)的提升。不過目前沒有明確的發(fā)布時間。同時HTTP2也已經(jīng)正式定稿，這個由 SPDY協(xié)議演化而來的協(xié)議相比 HTTP1.1又是一個 非常重大的變動，能夠明顯提升應(yīng)用層數(shù)據(jù)的傳輸效率。HTTPS功能介紹百度使用HTTPS協(xié)議主要是為了保護用戶隱私，防止流量劫持。HTTP本身是明文傳輸?shù)?，沒有經(jīng)過任何安全處理。例如用戶在百度搜索了一個關(guān)鍵字， 比如“蘋果手機”，中間者完全能夠查看到這個信息，并且有可能打電話過來騷擾用戶。 也有一些用戶投

4、訴使用百度時，發(fā)現(xiàn)首頁或者結(jié)果頁面浮了一個很長很大的廣告，這也肯 定是中間者往頁面插的廣告內(nèi)容。如果劫持技術(shù)比較低劣的話，用戶甚至無法訪問百度。這里提到的中間者主要指一些網(wǎng)絡(luò)節(jié)點，是用戶數(shù)據(jù)在瀏覽器和百度服務(wù)器中間傳輸必須 要經(jīng)過的節(jié)點。比如 WIFI熱點，路由器，防火墻，反向代理，緩存服務(wù)器等。在HTTP協(xié)議下，中間者可以隨意嗅探用戶搜索內(nèi)容，竊取隱私甚至篡改網(wǎng)頁。不過 HTTPS是這些劫持行為的克星，能夠完全有效地防御。總體來說，HTTPS協(xié)議提供了三個強大的功能來對抗上述的劫持行為：1,內(nèi)容加密。瀏覽器到百度服務(wù)器的內(nèi)容都是以加密形式傳輸，中間者無法直接查看原 始內(nèi)容。2,身份認(rèn)證。保證

5、用戶訪問的是百度服務(wù)，即使被DNS劫持到了第三方站點，也會提醒用戶沒有訪問百度服務(wù)，有可能被劫持。3,數(shù)據(jù)完整性。防止內(nèi)容被第三方冒充或者篡改。那HTTPS是如何做到上述三點的呢？下面從原理角度介紹一下。HTTPS原理介紹內(nèi)容加密加密算法一般分為兩種，對稱加密和非對稱加密。所謂對稱加密（也叫密鑰加密）就是指 加密和解密使用的是相同的密鑰。而非對稱加密（也叫公鑰加密）就是指加密和解密使用 了不同的密鑰。Baiduhttps加密密文Xynuynxoz一解密Baiduhttps圖2對稱加密Baiduhttps加密一密文LXynuynxoz一解密一Baiduhttps，,密鑰密鑰B圖3非對稱加密對稱內(nèi)

6、容加密強度非常高，一般破解不了。但存在一個很大的問題就是無法安全地生成和 保管密鑰。假如客戶端軟件和服務(wù)器之間每次會話都使用固定的，相同的密鑰加密和解密， 肯定存在很大的安全隱患。如果有人從客戶端獲取到了對稱密鑰，整個內(nèi)容就不存在安全 性了，而且管理海量的客戶端密鑰也是一件很復(fù)雜的事情。非對稱加密主要用于密鑰交換（也叫密鑰協(xié)商），能夠很好地解決這個問題。瀏覽器和服 務(wù)器每次新建會話時都使用非對稱密鑰交換算法協(xié)商出對稱密鑰，使用這些對稱密鑰完成 應(yīng)用數(shù)據(jù)的加解密和驗證，整個會話過程中的密鑰只在內(nèi)存中生成和保存，而且每個會話 的對稱密鑰都不相同（除非會話復(fù)用），中間者無法竊取。非對稱密鑰交換很安全

7、，但同時也是HTTPS性能和速度嚴(yán)重降低的“罪魁禍?zhǔn)住?。想要知道HTTPS為什么影響速度，為什么消耗資源，就一定要理解非對稱密鑰交換的整個過 程。卜面重點介紹一下非對稱密鑰交換的數(shù)學(xué)原理及在TLS握手過程中的應(yīng)用非對稱密鑰交換 在非對稱密鑰交換算法出現(xiàn)以前，對稱加密一個很大的問題就是不知道如何安全生成和保 管密鑰。非對稱密鑰交換過程主要就是為了解決這個問題，使得對稱密鑰的生成和使用更 加安全。密鑰交換算法本身非常復(fù)雜，密鑰交換過程涉及到隨機數(shù)生成，模指數(shù)運算，空白補齊， 加密，簽名等操作。常見的密鑰交換算法有 RSA, ECDHE DH DHE等算法。它們的特性如下：RSA算法實現(xiàn)簡單，誕生于

8、 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)復(fù)雜，用于密鑰交換的歷史不長，沒有 經(jīng)過長時間的安全攻擊測試。ECDH不支持PFS,安全性低，同時無法實現(xiàn) false start 。DHE不支持

9、ECC。非常消耗CPU資源。建議優(yōu)先支持RSA和ECDH_RS臉鑰交換算法。原因是：1, ECDHEZ持ECC加速，計算速度更快。支持 PFS,更加安全。支持 false start ,用 戶訪問速度更快。2,目前還有至少20%以上的客戶端不支持 ECDHE我們推薦使用 RSA而不是DH或者 DHE因為DH系列算法非常消耗 CPU （相當(dāng)于要做兩次 RSA計算）。0 https: www.baidu工om HYPERLINK http:/www.baidu.corn www.baidu.corn 已咤正身盼4FF 直接Q.nSgn Class 3 SecureSe rve i CA - G3

10、ff;瞌證 但金有匕開竄咦出 影 記市信息呼與w7/w.baidu.ci-n=三王;至爰二年了新翼加司牛心該。使用TLS12/曲曲唯用AES_12&.GM進行加密和尋份流 證，并使用ECDHE_RA作為密銅支操機機需要注意通常所說的 ECDHE密鑰交換默認(rèn)都是指 ECDHE_RSA使用ECDHE生成DH算法 所需的公私鑰，然后使用 RSA算法進行簽名最后再計算得出對稱密鑰。非對稱加密相比對稱加密更加安全，但也存在兩個明顯缺點：1, CPU計算資源消耗非常大。一次完全 TLS握手，密鑰交換時的非對稱解密計算量占整 個握手過程的90%以上。而對稱加密的計算量只相當(dāng)于非對稱加密的0.1%,如果應(yīng)用層

11、數(shù)據(jù)也使用非對稱加解密，性能開銷太大，無法承受。2,非對稱加密算法對加密內(nèi)容的長度有限制，不能超過公鑰長度。比如現(xiàn)在常用的公鑰 長度是2048位，意味著待加密內(nèi)容不能超過256個字節(jié)。所以公鑰加密目前只能用來作密鑰交換或者內(nèi)容簽名，不適合用來做應(yīng)用層傳輸內(nèi)容的加 解密。非對稱密鑰交換算法是整個 HTTPS得以安全的基石，充分理解非對稱密鑰交換算法是理 解HTTPS協(xié)議和功能的關(guān)鍵。卜面分別通俗地介紹一下 RSA和ECDHE在密鑰交換過程中的應(yīng)用RSA密鑰協(xié)商RSA 法介紹RSA算法的安全性是建立在乘法不可逆或者大數(shù)因子很難分解的基礎(chǔ)上。RSA的推導(dǎo)和實現(xiàn)涉及到了歐拉函數(shù)和費馬定理及模反元素的概

12、念，有興趣的讀者可以自行百度。RSA算法是統(tǒng)治世界的最重要算法之一，而且從目前來看，RSA也是HTTPS體系中最重要的算法，沒有之一。RSA的計算步驟如下：1,隨機挑選兩個質(zhì)數(shù) p, q ,假設(shè) p = 13, q = 19。 n = p * q = 13 * 19 = 247;2, ?(n)表示與整數(shù)n互質(zhì)數(shù)的個數(shù)。如果 n等于兩個質(zhì)數(shù)的積，則?(n)=(p-1)(q-1) 挑選一個數(shù)e ,滿足1 e ?(n)并且e與互質(zhì)，假設(shè)e = 17;3,計算e關(guān)于n的模反元素，ed=1 mod ?(n),由e = 17 ,?(n) =216 可得d =89;4,求出了 e,和d ,假設(shè)明文m = 1

13、35 ,密文用c表示。那么加解密計算如下：加密過程：底=cmod (兒則c = mod (n)即 c =(247) = 2G0135加整后的密文是200.解密過程；m三泗mod S) j貝m= 200B,mod(247)-B5 解密后得出明文卬=135.實際應(yīng)用中，(n,e)組成了公鑰對，(n,d )組成了私鑰對，其中 n和d都是一個接近 22048的大數(shù)。即使現(xiàn)在性能很強的 CPU,想要計算 m= cAd mod(n),也需要消耗比較大 的計算資源和時間。公鑰對(n, e)一般都注冊到了證書里，任何人都能直接查看，比如百度證書的公鑰對如下圖，其中最末 6個數(shù)字(010001)換算成10進制就

14、是65537,也就是公鑰對中的 e取值比較小的好處有兩個： 1,由c=mAe mod(n)可知，e較小，客戶端CPU計算消耗的資源較少。2,加大server端的破解難度。e比較小，私鑰對中的d必然會非常大。所以d的取 值空間也就非常大，增加了破解難度。那為什么(n,e)能做為公鑰公開，甚至大家都能直接從證書中查看到，這樣安全嗎？分析如下：由于edm1 mod ?(n),知道了 e和n ,想要求出私鑰d ,就必須知道？(n)。而?(n)=(p-1)*(q-1),必須計算出p和q才能確定私鑰d。但是當(dāng)n大到一定程度時(比如接近2A2048 ),即使現(xiàn)在最快的 CPU也無法進行這個因式分解，即無法知

15、道n是由哪個數(shù)p和q乘出來的。所以就算知道了公鑰，整個加解密過程還是非常安全的。字度國有效期從81使用者可選名稱基本約束 晶CRL分發(fā)點WriSign Class 3 Secure S.r 201 際雨白日 3:00:00 2015年麗 10日 759:59aidu.corn, service opfr,RSA 12048 BiDNS hJam=Subject Type=End Entity.1CRL Distributton Point: .f2 3f 4d 4a 43 6g 86 W 55 e8 05 35 e7 73 05 15 50 c6 59 71 a9 f7小e2 1e 3b 19

16、 20 78 88 寸 bb 21 d1 6& 0b 40 4f bb f2 06 10 be 5fOd ee 74 +9 蛆 fa ff 62 ed 77 22 2d 90 af db 3c 40 b9 20 28Sa 61 4f Se 2f 45 T S8 凳 05 00 亞 fe H 01 7e 誦 4f 24 ceb5 3a b2 6日 N Oe 371fe4 % 13 c2 2b 86 09 9b 43 07 55 15 aS 37 7d 97 57 y eOf2 29 5b ed cd 97 11 77 35 07 19 4c 7d 1a 3f 90 Ie fe 就 lb 35 d

17、2 28 7f 70 + 41 17 ad 45 72 43 35 1a a4 75 ed 5f母0m df b2 ae 99 31 1d 2cdd 82 Oe 22 la 13 e3 02 .03 01 00 017圖5百度HTTPS證書公鑰握手過程中的RSA密鑰協(xié)商介紹完了 RSA的原理，那最終會話所需要的對稱密鑰是如何生成的呢？跟RSA有什么關(guān)系？ 以TLS1.2為例簡單描述一下，省略跟密鑰交換無關(guān)的握手消息。過程如下：1,瀏覽器發(fā)送client_hello ,包含一個隨機數(shù) random1。2,服務(wù)端回復(fù) server_hello ,包含一個隨機數(shù) random2 ,同時回復(fù) cert

18、ificate ,攜帶 了證書公鑰P。3,瀏覽器接收至U random2 之后就能夠生成 premaster_secrect 以及master_secrect 。其中premaster_secret 長度為48個字節(jié)，前2個字節(jié)是協(xié)議版本號，剩下的 46個 字節(jié)填充一個隨瓦數(shù)。結(jié)構(gòu)如下：1 Struct byte Version2;bute random46;master secrect的生成算法簡述如下：Master_key = PRF(premaster_secret,“master secrect ,隨機數(shù)1+隨機數(shù) 2)其中PRF 是一個隨機函數(shù)，定義如下：PRF(secret, la

19、bel, seed) = P_MD5(S1, label +seed) XOR P_SHA-1(S2, label + seed)而master secrect包含了六部分內(nèi)容，分別是用于校驗內(nèi)容一致性的密鑰，用于對稱內(nèi)容加解密的密鑰，以及初始化向量(用于 CBC模式)，客戶端和服務(wù)端各一份。從上式 可以看出，把 premaster_key 賦值給secret , master key ”賦值給label ,瀏覽器和服務(wù)器端的兩個隨機數(shù)做正子就能確定地求出一個48位長的隨機數(shù)。至此，瀏覽器側(cè)的密鑰已經(jīng)完成協(xié)商。4,瀏覽器使用證書公鑰 P將premaster_secrect加密后發(fā)送給服務(wù)器。5

20、,服務(wù)端使用私鑰解密得到 premaster_secrect 。又由于服務(wù)端之前就收到了隨機數(shù) 1 , 所以服務(wù)端根據(jù)相同的生成算法，在相同的輸入?yún)?shù)下，求出了相同的master secrect 。RSA密鑰協(xié)商握手過程圖示如下：elicit 1 icily用戶隨磯數(shù)1Llipnt iepy eitrhnffeApplication dataWeb serverApplication data圖6 RSA密鑰協(xié)商過程可以看出，密鑰協(xié)商過程需要2個RTT,這也是HTTPS慢的一個重要原因。而 RSA發(fā)揮的關(guān)鍵作用就是對 premaster_secrect進行了加密和解密。中間者不可能破解RSA算

21、法，也就不可能知道 premaster_secrect ,從而保證了密鑰協(xié)商過程的安全性。ECDHE密鑰協(xié)商DH與EC峭法原理ECDHEff法實現(xiàn)要復(fù)雜很多，主要分為兩部分：diffie-hellman 算法(簡稱為DH)及ECC(橢圓曲線算術(shù))。他們的安全性都是建立在離散對數(shù)計算很困難的基礎(chǔ)上。簡單介紹一下dh算法的實現(xiàn)，先介紹兩個基本概念：本原根：如果整數(shù) a是素數(shù)p的本原根，則 a, aA2, , aA(p-1)在mod p下都不相同。離散對數(shù)：對任意整數(shù) b和素數(shù)p的本原根a,存在唯一的指數(shù)i滿足：b m aAi mod p (0 i p -1)則稱i是b的以a為底的模p的離散對數(shù)理解

22、這兩個概念，dh算法就非常簡單了，示例如下: 假設(shè)client 和server 需要協(xié)商密鑰，p=2579,則本原根a = 2。Client 選擇隨機數(shù) Kc = 123 做為自己的私鑰，計算 Yc = aAKcmod p = 2A123mod 2579 = 2400 ,把 Yc作為公鑰發(fā)送給 server。Server選擇隨機數(shù) Ks = 293 作為私鑰，計算 Ys = aAKs mod p = $八293 mod 2579 = 968 ,把Ys作為公鑰發(fā)送給 client 。Client 計算共享密鑰：secrect = YsAKc mod (p) = 968A123mod(2579)

23、= 434Server 計算共享密鑰：secrect = YcAKs mod(p) =2400人293 mod(2579) =434上述公式中的Ys,Yc,P, a,都是公開信息，可以被中間者查看，只有Ks,Kc作為私鑰沒有公開，當(dāng)私鑰較小時，通過窮舉攻擊能夠計算出共享密鑰，但是當(dāng)私鑰非常大時，窮舉 攻擊肯定是不可行的。DH算法有一個比較大的缺陷就是需要提供足夠大的私鑰來保證安全性，所以比較消耗CPU計算資源。ECC橢圓曲線算術(shù)能夠很好的解決這個問題，224位的密鑰長度就能達到RSA2048位的安全強度。ECC的曲線公式描述的其實不是橢圓，只是跟橢圓曲線周長公式形似才叫橢圓曲線加密算 術(shù)。EC

24、C涉及到了有限域、群等近世代數(shù)的多個概念，就不做詳細介紹了。ECC安全性依賴于這樣一個事實：P = kQ,已知k, Q 求出P相對簡單，但是已知 P和Q求出k卻非常困難。上式看起來非常簡單，但有如下約束條件：1, Q是一個非常大的質(zhì)數(shù)，p, k, q都是橢圓曲線有限域上的離散點。2,有限域定義了自己的加法和乘法法則，即使 kQ的運算也非常復(fù)雜。ECC應(yīng)用于Diffie-Hellman密鑰交換過程如下：1,定義一個滿足橢圓方程的有限域，即挑選 p, a, b滿足如下方程：yA2 mod p = (xA3+ax +b) mod p2,挑選基點G = (x, y) , G的階為n。n為滿足nG =

25、0 的最小正整數(shù)。Client 選擇私鑰 Kc (0 Kcn ),產(chǎn)生公鑰 Yc =Kc *Gserver 選擇私鑰 Ks并產(chǎn)生公鑰 Ys =Ks*Gclient 計算共享密鑰 K = Kc*Ys , server 端計算共享密鑰 Ks*Yc ,這兩者的結(jié) 果是一樣的，因為：Kc*Ys = Kc*(Ks*G) = Ks*(Kc*G) = Ks*Yc由上面描述可知，只要確定p, a, b就能確定一條有限域上的橢圓曲線，由于不是所有的橢圓曲線都能夠用于加密，所以 p, a, b的選取非常講究，直接關(guān)系曲線的安全性和計算速度。Openssl實現(xiàn)的，也是FIPS推薦的256位素數(shù)域上的橢圓曲線參數(shù)定義

26、如下：質(zhì)數(shù)p =115792089210356248762697446949407573530086143415290314195533631308867097853951 階n =115792089210356248762697446949407573529996955224135760342422259061068512044369SEED = c49d3608 86e70493 6a6678e1 139d26b7 819f7e90c = 7efba166 2985be9403cb055c 75d4f7e0 ce8d84a9 c5114abcaf317768 0104fa0d橢圓曲線的系數(shù)

27、 a = 0 橢圓曲線的系統(tǒng) b = 5ac635d8 aa3a93e7 b3ebbd55 769886bc 651d06b0 cc53b0f63bce3c3e 27d2604b 基點 G x = 6b17d1f2 e12c4247 f8bce6e5 63a440f2 77037d812deb33a0f4a13945 d898c296 基點 G y = 4fe342e2 fe1a7f9b 8ee7eb4a 7c0f9e162bce3357 6b315ececbb64068 37bf51f54.1,1,2.2 握手過程中的ECDHE密鑰協(xié)商簡單介紹了 ECC和DH算法的數(shù)學(xué)原理，我們看下 ECD

28、HE在TLS握手過程中的應(yīng)用。相比RSA, ECDHE需要多發(fā)送一個 server_key_exchange的握手消息才能完成密鑰協(xié)商。同樣以TLS1.2為例，簡單描述一下過程：1,瀏覽器發(fā)送client_hello ,包含一個隨機數(shù)random1 ,同時需要有2個擴展：Elliptic_curves :客戶端支持的曲線類型和有限域參數(shù)?，F(xiàn)在使用最多的是256位的素數(shù)域，參數(shù)定義如上節(jié)所述。Ec_point_formats : 支持的曲線點格式，默認(rèn)者B是uncompressed。2,服務(wù)端回復(fù)server_hello ,包含一個隨機數(shù) random2及ECC擴展。3,服務(wù)端回復(fù)certifi

29、cate ,攜帶了證書公鑰。4,服務(wù)端生成 ECDH臨時公鑰，同時回復(fù) server_key_exchange ,包含三部分重要內(nèi)容：ECC相關(guān)的參數(shù)。ECDH臨時公鑰。ECC參數(shù)和公鑰生成的簽名值，用于客戶端校驗。5,瀏覽器接收server_key_exchange 之后，使用證書公鑰進行簽名解密和校驗，獲取服 務(wù)器端的ECDH臨時公鑰，生成會話所需要的共享密鑰。至此，瀏覽器端完成了密鑰協(xié)商。消息，跟RSA密鑰協(xié)商不同的ECDH臨時公鑰。6,瀏覽器生成ECDH臨時公鑰和client_key_exchange 是，這個消息不需要加密了。7,服務(wù)器處理client_key_exchang 消息，

30、獲取客戶端8,服務(wù)器生成會話所需要的共享密鑰 9, Server端密鑰協(xié)商過程結(jié)束。圖示如下:圖7 ECDHE密鑰協(xié)商過程4.1.2對稱內(nèi)容加密非對稱密鑰交換過程結(jié)束之后就得出了本次會話需要使用的對稱密鑰。對稱加密又分為兩種模式：流式加密和分組加密。流式加密現(xiàn)在常用的就是RC4,不過RC4已經(jīng)不再安全,微軟也建議網(wǎng)站盡量不要使用 RC4流式加密。一種新的替代RC4的流式加密算法叫ChaCha20,它是google推出的速度更快，更安全 的加密算法。目前已經(jīng)被 android 和chrome采用，也編譯進了 google 的開源 openssl 分支 boring ssl , 并且 nginx

31、1.7.4也支持編譯 boringssl 。分組加密以前常用的模式是 AES-CBC,但是CBC已經(jīng)被證明容易遭受 BEAST口 LUCKY13 攻擊。目前建議使用的分組加密模式是AES-GCM不過它的缺點是計算量大，性能和電量消耗都比較高，不適用于移動電話和平板電腦。4.2身份認(rèn)證身份認(rèn)證主要涉及到 PKI和數(shù)字證書。通常來講 PKI （公鑰基礎(chǔ)設(shè)施）包含如下部分：End entity :終端實體，可以是一個終端硬件或者網(wǎng)站。CA證書簽發(fā)機構(gòu)。RA證書注冊及審核機構(gòu)。比如審查申請網(wǎng)站或者公司的真實性。CRL issuer :負(fù)責(zé)證書撤銷列表的發(fā)布和維護。Repository :負(fù)責(zé)數(shù)字證書及

32、CRL內(nèi)容存儲和分發(fā)。申請一個受信任的數(shù)字證書通常有如下流程：1,終端實體生成公私鑰和證書請求。RA檢查實體的合法性。如果個人或者小網(wǎng)站，這一步不是必須的。CA簽發(fā)證書，發(fā)送給申請者。4,證書更新到repository ,終端后續(xù)從repository更新證書，查詢證書狀態(tài)等。目前百度使用的證書是 X509v3格式，由如下三個部分組成：tbsCertificate（to be signed certificate待簽名證書內(nèi)容），這部分包含了 10 個要素，分別是版本號，序列號，簽名算法標(biāo)識，發(fā)行者名稱，有效期，證書主體名，證書 主體公鑰信息，發(fā)行商唯一標(biāo)識，主體唯一標(biāo)識，擴展等。signat

33、ureAlgorithm ,簽名算法標(biāo)識，指定對 tbsCertificate進行簽名的算法。3, signaturValue 得到簽名值。（簽名值），使用 signatureAlgorithm 對 tbsCertificate進行計算數(shù)字證書有兩個作用：1,身份授權(quán)。確保瀏覽器訪問的網(wǎng)站是經(jīng)過CA驗證的可信任的網(wǎng)站。2,分發(fā)公鑰。每個數(shù)字證書都包含了注冊者生成的公鑰。在 SSL握手時會通過certificate消息傳輸給客戶端。比如前文提到的RSA證書公鑰加密及ECDHE的簽名者B是使用的這個公鑰。申請者拿到CA的證書并部署在網(wǎng)站服務(wù)器端，那瀏覽器發(fā)起握手接收到證書后，如何確認(rèn)這個證書就是

34、CA簽發(fā)的呢？怎樣避免第三方偽造這個證書？答案就是數(shù)字簽名(digital signature )。數(shù)字簽名是證書的防偽標(biāo)簽，目前使用最廣 泛的SHA-RSA數(shù)字簽名的制作和驗證過程如下：1,數(shù)字簽名的簽發(fā)。首先是使用哈希函數(shù)對待簽名內(nèi)容進行安全哈希，生成消息摘要，然后使用CA自己的私鑰對消息摘要進行加密。tbsCertificate哈希函數(shù)2,數(shù)字簽名的校驗。使用 CA的公鑰解密簽名，然后使用相同的簽名函數(shù)對待簽名證書 內(nèi)容進行簽名并和服務(wù)端數(shù)字簽名里的簽名內(nèi)容進行比較，如果相同就認(rèn)為校驗成功。數(shù)字簽名 tb sCcrtificctcca公鑰解能哈希函數(shù)計算簽名值101010010消息摘要證書數(shù)字簽名圖8數(shù)字簽名生成及校驗 這里有幾點需要說明:.數(shù)字簽名簽發(fā)和校驗使用的密鑰對是CA自己的公私密鑰，跟證書申請者提交的公鑰沒有關(guān)系。.數(shù)字簽名的簽發(fā)過程跟公鑰加密的過程剛好相反，即是用私鑰加密，公鑰解密。.現(xiàn)在大的CA都會有證書鏈，證書鏈的好處一是安全，保持根 CA的私鑰離線使用。 第二個好處是方便部署和撤銷，即如果證書出現(xiàn)問題，只需要撤銷相應(yīng)級別的證書， 根證書依然安全。.根CA證書都是自簽名，即用