RSA算法的安全性是建立在乘法不可逆或者大數因子很難分解的基礎上。RSA的推導和實現涉及到了歐拉函數和費馬定理及模反元素的概念，有興趣的讀者可以自行百度了解一下。

RSA算法是統治世界的最重要算法之一，而且從目前來看，RSA也是HTTPS體系中最重要的算法，沒有之一。

RSA的計算步驟如下：

1. 隨機挑選兩個質數p，q，假設p=13，q=19。n=p*q=13*19=247;

2. ?(n)表示與整數n互質數的個數。如果n等于兩個質數的積，則?(n)=(p-1)(q-1)挑選一個數e，滿足1<e<?(n)并且e與互質，假設e=17;

3. 計算e關于n的模反元素，ed=1 mod ?(n)，由e=17，?(n)=216可得d=89;

4. 求出了e，和d，假設明文m=135，密文用c表示。那么加解密計算如下：

圖1  加解密計算過程

實際應用中，(n，e)組成了公鑰對，（n，d）組成了私鑰對，其中n和d都是一個接近2^2048的大數。即使現在性能很強的CPU，想要計算m≡c^d mod(n)，也需要消耗比較大的計算資源和時間。

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

1. 由c=m^e mod(n)可知，e較小，客戶端CPU計算消耗的資源較少。

2. 加大server端的破解難度。e比較小，私鑰對中的d必然會非常大。所以d的取值空間也就非常大，增加了破解難度。

那為什么(n，e)能做為公鑰公開，甚至大家都能直接從證書中查看到，這樣安全嗎？分析如下：

由于ed≡1mod ?(n)，知道了e和n，想要求出私鑰d，就必須知道?(n)。而?(n)=(p-1)*(q-1)，必須計算出p和q才能確定私鑰d。但是當n大到一定程度時（比如接近2^2048），即使現在最快的CPU也無法進行這個因式分解，即無法知道n是由哪個數p和q乘出來的。所以就算知道了公鑰，整個加解密過程還是非常安全的。

圖2  百度HTTPS證書公鑰

介紹完了RSA的原理，那最終會話所需要的對稱密鑰是如何生成的呢？跟RSA有什么關系？

以TLS1.2為例簡單描述一下，省略跟密鑰交換無關的握手消息。過程如下：

1. 瀏覽器發送client_hello，包含一個隨機數random1。

2. 服務端回復server_hello，包含一個隨機數random2，同時回復certificate，攜帶了證書公鑰P。

3. 瀏覽器接收到random2之后就能夠生成premaster_secrect以及master_secrect。其中premaster_secret長度為48個字節，前2個字節是協議版本號，剩下的46個字節填充一個隨機數。結構如下：

   Struct {byte Version[2];bute random[46];}

   master secrect的生成算法簡述如下：

   Master_key=PRF(premaster_secret，“master secrect”，隨機數1+隨機數2)其中PRF是一個隨機函數，定義如下：PRF(secret，label，seed)=P_MD5(S1，label+seed)XOR P_SHA-1(S2，label+seed)

   從上式可以看出，把premaster_key賦值給secret，“master key”賦值給label，瀏覽器和服務器端的兩個隨機數做種子就能確定地求出一個48位長的隨機數。
   

   而master secrect包含了六部分內容，分別是用于校驗內容一致性的密鑰，用于對稱內容加解密的密鑰，以及初始化向量（用于CBC模式），客戶端和服務端各一份。

   至此，瀏覽器側的密鑰已經完成協商。

4. 瀏覽器使用證書公鑰P將premaster_secrect加密后發送給服務器。

5. 服務端使用私鑰解密得到premaster_secrect。又由于服務端之前就收到了隨機數1，所以服務端根據相同的生成算法，在相同的輸入參數下，求出了相同的master secrect。

RSA密鑰協商握手過程圖示如下：

圖3  RSA密鑰協商過程

可以看出，密鑰協商過程需要2個RTT，這也是HTTPS慢的一個重要原因。而RSA發揮的關鍵作用就是對premaster_secrect進行了加密和解密。中間者不可能破解RSA算法，也就不可能知道premaster_secrect，從而保證了密鑰協商過程的安全性。

ECDHE算法實現要復雜很多，主要分為兩部分：

Diffie-Hellman算法（簡稱為DH）及ECC（橢圓曲線算術）。他們的安全性都是建立在離散對數計算很困難的基礎上。

簡單介紹一下DH算法的實現，先介紹兩個基本概念：

• 本原根：如果整數a是素數p的本原根，則a，a^2，…，a^(p-1)在mod p下都不相同。

• 離散對數：對任意整數b和素數p的本原根a，存在唯一的指數i滿足:

b≡a^I mod p(0≤i≤p-1)

則稱i是b的以a為底的模p的離散對數。

理解這兩個概念，DH算法就非常簡單了，示例如下：

假設client和server需要協商密鑰，p=2579，則本原根a=2。

1. client選擇隨機數Kc=123做為自己的私鑰，計算Yc=a^Kc mod p=2^123 mod 2579=2400，把Yc作為公鑰發送給server。

2. server選擇隨機數Ks=293作為私鑰，計算Ys=a^Ks mod p=s^293 mod 2579=968，把Ys作為公鑰發送給client。

3. client計算共享密鑰：secrect=Ys^Kc mod (p)=968^123 mod(2579) =434

4. server計算共享密鑰：secrect=Yc^Ks mod(p)=2400^293 mod(2579)=434

上述公式中的Ys，Yc，P，a，都是公開信息，可以被中間者查看，只有Ks，Kc作為私鑰沒有公開，當私鑰較小時，通過窮舉攻擊能夠計算出共享密鑰，但是當私鑰非常大時，窮舉攻擊肯定是不可行的。

DH算法有一個比較大的缺陷就是需要提供足夠大的私鑰來保證安全性，所以比較消耗CPU計算資源。ECC橢圓曲線算術能夠很好的解決這個問題，224位的密鑰長度就能達到RSA2048位的安全強度。

ECC的曲線公式描述的其實不是橢圓，只是跟橢圓曲線周長公式形似才叫橢圓曲線加密算術。ECC涉及到了有限域、群等近世代數的多個概念，就不做詳細介紹了。

ECC安全性依賴于這樣一個事實：

上式看起來非常簡單，但有如下約束條件：

1. Q是一個非常大的質數，p，k，q都是橢圓曲線有限域上的離散點。

2. 有限域定義了自己的加法和乘法法則，即使kQ的運算也非常復雜。

ECC應用于Diffie-Hellman密鑰交換過程如下：

1. 定義一個滿足橢圓方程的有限域，即挑選p，a，b滿足如下方程：

   y^2 mod p=(x^3+ax+b)mod p

2. 挑選基點G=(x，y)，G的階為n。n為滿足nG=0的最小正整數。

3. client選擇私鑰Kc(0<Kc<n)，產生公鑰Yc=Kc*G

4. server選擇私鑰Ks并產生公鑰Ys=Ks*G

5. client計算共享密鑰K=Kc*Ys，server端計算共享密鑰Ks*Yc，這兩者的結果是一樣的，因為：

   Kc*Ys=Kc*(Ks*G)=Ks*(Kc*G)=Ks*Yc

由上面描述可知，只要確定p，a，b就能確定一條有限域上的橢圓曲線，由于不是所有的橢圓曲線都能夠用于加密，所以p，a，b的選取非常講究，直接關系曲線的安全性和計算速度。

OpenSSL實現的，也是FIPS推薦的256位素數域上的橢圓曲線參數定義如下：

簡單介紹了ECC和DH算法的數學原理，我們看下ECDHE在TLS握手過程中的應用。

相比RSA，ECDHE需要多發送一個server_key_exchange的握手消息才能完成密鑰協商。

同樣以TLS1.2為例，簡單描述一下過程：

1. 瀏覽器發送client_hello，包含一個隨機數random1，同時需要有2個擴展：

1. Elliptic_curves：客戶端支持的曲線類型和有限域參數。現在使用最多的是256位的素數域，參數定義如上節所述。

2. Ec_point_formats：支持的曲線點格式，默認都是uncompressed。

2. 服務端回復server_hello，包含一個隨機數random2及ECC擴展。

3. 服務端回復certificate，攜帶了證書公鑰。

4. 服務端生成ECDH臨時公鑰，同時回復server_key_exchange，包含三部分重要內容：

1. ECC相關的參數。

2. ECDH臨時公鑰。

3. ECC參數和公鑰生成的簽名值，用于客戶端校驗。

5. 瀏覽器接收server_key_exchange之后，使用證書公鑰進行簽名解密和校驗，獲取服務器端的ECDH臨時公鑰，生成會話所需要的共享密鑰。

   至此，瀏覽器端完成了密鑰協商。

6. 瀏覽器生成ECDH臨時公鑰和client_key_exchange消息，跟RSA密鑰協商不同的是，這個消息不需要加密了。

7. 服務器處理client_key_exchang消息，獲取客戶端ECDH臨時公鑰。

8. 服務器生成會話所需要的共享密鑰。

9. 服務端密鑰協商過程結束。

圖示如下：

圖4  ECDHE密鑰協商過程

非對稱密鑰交換過程結束之后就得出了本次會話需要使用的對稱密鑰。對稱加密又分為兩種模式：流式加密和分組加密。流式加密現在常用的就是RC4，不過RC4已經不再安全，微軟也建議網站盡量不要使用RC4流式加密。

一種新的替代RC4的流式加密算法叫ChaCha20，它是Google推出的速度更快，更安全的加密算法。目前已經被Android和Chrome采用，也編譯進了Google的開源OpenSSL分支—BoringSSL，并且Nginx1.7.4也支持編譯BoringSSL。

分組加密以前常用的模式是AES-CBC，但是CBC已經被證明容易遭受BEAST和LUCKY13攻擊。目前建議使用的分組加密模式是AES-GCM，不過它的缺點是計算量大，性能和電量消耗都比較高，不適用于移動電話和平板電腦。

身份認證主要涉及到PKI和數字證書。通常來講PKI（公鑰基礎設施）包含如下部分：

• End entity：終端實體，可以是一個終端硬件或者網站。

• CA：證書簽發機構。

• RA：證書注冊及審核機構。比如審查申請網站或者公司的真實性。

• CRL issuer：負責證書撤銷列表的發布和維護。

• Repository：負責數字證書及CRL內容存儲和分發。

申請一個受信任的數字證書通常有如下流程：

1. 終端實體生成公私鑰和證書請求。

2. RA檢查實體的合法性。如果個人或者小網站，這一步不是必須的。

3. CA簽發證書，發送給申請者。

4. 證書更新到repository，終端后續從repository更新證書，查詢證書狀態等。

目前百度使用的證書是X509v3格式，由如下三個部分組成：

1. tbsCertificate(to be signed certificate 待簽名證書內容)，這部分包含了10個要素，分別是版本號，序列號，簽名算法標識，發行者名稱，有效期，證書主體名，證書主體公鑰信息，發行商唯一標識，主體唯一標識，擴展等。

2. signature Algorithm，簽名算法標識，指定對tbsCertificate進行簽名的算法。

3. signaturValue（簽名值），使用signatureAlgorithm對tbsCertificate進行計算得到簽名值。

數字證書有兩個作用：

1. 身份授權。確保瀏覽器訪問的網站是經過CA驗證的可信任的網站。

2. 分發公鑰。每個數字證書都包含了注冊者生成的公鑰。在SSL握手時會通過certificate消息傳輸給客戶端。比如前文提到的RSA證書公鑰加密及ECDHE的簽名都是使用的這個公鑰。

申請者拿到CA的證書并部署在網站服務器端，那瀏覽器發起握手接收到證書后，如何確認這個證書就是CA簽發的呢？怎樣避免第三方偽造這個證書？

答案就是數字簽名（digital signature）。數字簽名是證書的防偽標簽，目前使用最廣泛的SHA-RSA數字簽名的制作和驗證過程如下：

1. 數字簽名的簽發。首先是使用哈希函數對待簽名內容進行安全哈希，生成消息摘要，然后使用CA自己的私鑰對消息摘要進行加密。

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

圖5  數字簽名生成及校驗

這里有幾點需要說明：

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

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

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

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

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

這部分內容比較好理解，跟平時的MD5簽名類似，只不過安全要求要高很多。OpenSSL現在使用的完整性校驗算法有兩種：MD5或者SHA。由于MD5在實際應用中存在沖突的可能性比較大，所以盡量別采用MD5來驗證內容一致性。SHA也不能使用SHA0和SHA1，中國山東大學的王小云教授在2005年就宣布破解了SHA-1完整版算法。

微軟和Google都已經在16年及17年之后不再支持SHA1簽名證書。

HTTPS的使用成本和額外開銷，完全不用太過擔心。

一般來講，使用HTTPS前大家可能會非常關注如下問題：

1. 證書費用以及更新維護。大家覺得申請證書很麻煩，證書也很貴，可是證書其實一點都不貴，便宜的一年幾十塊錢，最多也就幾百。而且現在也有了免費的證書機構，比如著名的Mozilla發起的免費證書項目：Let’s Encrypt（https://letsencrypt.org/）就支持免費證書安裝和自動更新。這個項目已于15年中旬投入正式使用。

   數字證書的費用其實也不高，對于中小網站可以使用便宜甚至免費的數字證書服務（可能存在安全隱患），像著名的Verisign公司的證書一般也就幾千到幾萬塊一年不等。當然如果公司對證書的需求比較大，定制性要求高，可以建立自己的CA站點，比如Google，能夠隨意簽發Google相關證書。

2. HTTPS降低用戶訪問速度。HTTPS對速度會有一定程度的降低，但是只要經過合理優化和部署，HTTPS對速度的影響完全可以接受。在很多場景下，HTTPS速度完全不遜于HTTP，如果使用SPDY，HTTPS的速度甚至還要比HTTP快。

   大家現在使用百度HTTPS安全搜索，有感覺到慢嗎？

3. HTTPS消耗CPU資源，需要增加大量機器。前面介紹過非對稱密鑰交換，這是消耗CPU計算資源的大戶，此外，對稱加解密，也需要CPU的計算。

同樣地，只要合理優化，HTTPS的機器成本也不會明顯增加。對于中小網站，完全不需要增加機器也能滿足性能需求。