本篇文章為大家展示了如何理解HTTPS加密算法,內(nèi)容簡明扼要并且容易理解,絕對能使你眼前一亮,通過這篇文章的詳細(xì)介紹希望你能有所收獲。
前言
我們將會詳細(xì)介紹RSA和ECDHE算法的原理以及在HTTPS密鑰交換中的應(yīng)用。
非對稱秘鑰交換
1RSA算法介紹
RSA算法的安全性是建立在乘法不可逆或者大數(shù)因子很難分解的基礎(chǔ)上。RSA的推導(dǎo)和實現(xiàn)涉及到了歐拉函數(shù)和費馬定理及模反元素的概念,有興趣的讀者可以自行百度了解一下。
RSA算法是統(tǒng)治世界的最重要算法之一,而且從目前來看,RSA也是HTTPS體系中最重要的算法,沒有之一。
RSA的計算步驟如下:
隨機挑選兩個質(zhì)數(shù)p,q,假設(shè)p=13,q=19。n=p*q=13*19=247;
?(n)表示與整數(shù)n互質(zhì)數(shù)的個數(shù)。如果n等于兩個質(zhì)數(shù)的積,則?(n)=(p-1)(q-1)挑選一個數(shù)e,滿足1<e<?(n)并且e與互質(zhì),假設(shè)e=17;
計算e關(guān)于n的模反元素,ed=1 mod ?(n),由e=17,?(n)=216可得d=89;
求出了e,和d,假設(shè)明文m=135,密文用c表示。那么加解密計算如下:
圖1 加解密計算過程
實際應(yīng)用中,(n,e)組成了公鑰對,(n,d)組成了私鑰對,其中n和d都是一個接近2^2048的大數(shù)。即使現(xiàn)在性能很強的CPU,想要計算m≡c^d mod(n),也需要消耗比較大的計算資源和時間。
公鑰對(n,e)一般都注冊到了證書里,任何人都能直接查看,比如百度證書的公鑰對如下圖,其中最末6個數(shù)字(010001)換算成10進制就是65537,也就是公鑰對中的e。e取值比較小的好處有兩個:
由c=m^e mod(n)可知,e較小,客戶端CPU計算消耗的資源較少。
加大server端的破解難度。e比較小,私鑰對中的d必然會非常大。所以d的取值空間也就非常大,增加了破解難度。
那為什么(n,e)能做為公鑰公開,甚至大家都能直接從證書中查看到,這樣安全嗎?分析如下:
由于ed≡1mod ?(n),知道了e和n,想要求出私鑰d,就必須知道?(n)。而?(n)=(p-1)*(q-1),必須計算出p和q才能確定私鑰d。但是當(dāng)n大到一定程度時(比如接近2^2048),即使現(xiàn)在最快的CPU也無法進行這個因式分解,即無法知道n是由哪個數(shù)p和q乘出來的。所以就算知道了公鑰,整個加解密過程還是非常安全的。
圖2 百度HTTPS證書公鑰
2握手過程中的RSA秘鑰協(xié)商
介紹完了RSA的原理,那最終會話所需要的對稱密鑰是如何生成的呢?跟RSA有什么關(guān)系?
以TLS1.2為例簡單描述一下,省略跟密鑰交換無關(guān)的握手消息。過程如下:
瀏覽器發(fā)送client_hello,包含一個隨機數(shù)random1。
服務(wù)端回復(fù)server_hello,包含一個隨機數(shù)random2,同時回復(fù)certificate,攜帶了證書公鑰P。
瀏覽器接收到random2之后就能夠生成premaster_secrect以及master_secrect。其中premaster_secret長度為48個字節(jié),前2個字節(jié)是協(xié)議版本號,剩下的46個字節(jié)填充一個隨機數(shù)。結(jié)構(gòu)如下:
Struct {byte Version[2];bute random[46];} |
master secrect的生成算法簡述如下:
Master_key=PRF(premaster_secret,“master secrect”,隨機數(shù)1+隨機數(shù)2)其中PRF是一個隨機函數(shù),定義如下:PRF(secret,label,seed)=P_MD5(S1,label+seed)XOR P_SHA-1(S2,label+seed) |
從上式可以看出,把premaster_key賦值給secret,“master key”賦值給label,瀏覽器和服務(wù)器端的兩個隨機數(shù)做種子就能確定地求出一個48位長的隨機數(shù)。
而master secrect包含了六部分內(nèi)容,分別是用于校驗內(nèi)容一致性的密鑰,用于對稱內(nèi)容加解密的密鑰,以及初始化向量(用于CBC模式),客戶端和服務(wù)端各一份。
至此,瀏覽器側(cè)的密鑰已經(jīng)完成協(xié)商。
瀏覽器使用證書公鑰P將premaster_secrect加密后發(fā)送給服務(wù)器。
服務(wù)端使用私鑰解密得到premaster_secrect。又由于服務(wù)端之前就收到了隨機數(shù)1,所以服務(wù)端根據(jù)相同的生成算法,在相同的輸入?yún)?shù)下,求出了相同的master secrect。
RSA密鑰協(xié)商握手過程圖示如下:
圖3 RSA密鑰協(xié)商過程
可以看出,密鑰協(xié)商過程需要2個RTT,這也是HTTPS慢的一個重要原因。而RSA發(fā)揮的關(guān)鍵作用就是對premaster_secrect進行了加密和解密。中間者不可能破解RSA算法,也就不可能知道premaster_secrect,從而保證了密鑰協(xié)商過程的安全性。
3DH與ECC算法原理
ECDHE算法實現(xiàn)要復(fù)雜很多,主要分為兩部分:
Diffie-Hellman算法(簡稱為DH)及ECC(橢圓曲線算術(shù))。他們的安全性都是建立在離散對數(shù)計算很困難的基礎(chǔ)上。
簡單介紹一下DH算法的實現(xiàn),先介紹兩個基本概念:
本原根:如果整數(shù)a是素數(shù)p的本原根,則a,a^2,…,a^(p-1)在mod p下都不相同。
離散對數(shù):對任意整數(shù)b和素數(shù)p的本原根a,存在唯一的指數(shù)i滿足:
b≡a^I mod p(0≤i≤p-1)
則稱i是b的以a為底的模p的離散對數(shù)。
理解這兩個概念,DH算法就非常簡單了,示例如下:
假設(shè)client和server需要協(xié)商密鑰,p=2579,則本原根a=2。
client選擇隨機數(shù)Kc=123做為自己的私鑰,計算Yc=a^Kc mod p=2^123 mod 2579=2400,把Yc作為公鑰發(fā)送給server。
server選擇隨機數(shù)Ks=293作為私鑰,計算Ys=a^Ks mod p=s^293 mod 2579=968,把Ys作為公鑰發(fā)送給client。
client計算共享密鑰:secrect=Ys^Kc mod (p)=968^123 mod(2579) =434
server計算共享密鑰:secrect=Yc^Ks 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ù)。ECC涉及到了有限域、群等近世代數(shù)的多個概念,就不做詳細(xì)介紹了。
ECC安全性依賴于這樣一個事實:
P=kQ,已知k,Q求出P相對簡單,但是已知P和Q求出k卻非常困難。 |
上式看起來非常簡單,但有如下約束條件:
Q是一個非常大的質(zhì)數(shù),p,k,q都是橢圓曲線有限域上的離散點。
有限域定義了自己的加法和乘法法則,即使kQ的運算也非常復(fù)雜。
ECC應(yīng)用于Diffie-Hellman密鑰交換過程如下:
定義一個滿足橢圓方程的有限域,即挑選p,a,b滿足如下方程:
y^2 mod p=(x^3+ax+b)mod p |
挑選基點G=(x,y),G的階為n。n為滿足nG=0的最小正整數(shù)。
client選擇私鑰Kc(0<Kc<n),產(chǎn)生公鑰Yc=Kc*G
server選擇私鑰Ks并產(chǎn)生公鑰Ys=Ks*G
client計算共享密鑰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ù)定義如下:
質(zhì)數(shù)p=115792089210356248762697446949407573530086143415290314195533631308867097853951 階n=115792089210356248762697446949407573529996955224135760342422259061068512044369 橢圓曲線的系數(shù)a=0 橢圓曲線的系統(tǒng)b=5ac635d8 aa3a93e7 b3ebbd55 769886bc 651d06b0 cc53b0f63bce3c3e 27d2604b 基點 G x = 6b17d1f2 e12c4247 f8bce6e5 63a440f2 77037d81 2deb33a0f4a13945 d898c296 基點 G y = 4fe342e2 fe1a7f9b 8ee7eb4a 7c0f9e16 2bce3357 6b315ececbb64068 37bf51f5 |
4握手過程中的ECDHE秘鑰協(xié)商
簡單介紹了ECC和DH算法的數(shù)學(xué)原理,我們看下ECDHE在TLS握手過程中的應(yīng)用。
相比RSA,ECDHE需要多發(fā)送一個server_key_exchange的握手消息才能完成密鑰協(xié)商。
同樣以TLS1.2為例,簡單描述一下過程:
瀏覽器發(fā)送client_hello,包含一個隨機數(shù)random1,同時需要有2個擴展:
Elliptic_curves:客戶端支持的曲線類型和有限域參數(shù)。現(xiàn)在使用最多的是256位的素數(shù)域,參數(shù)定義如上節(jié)所述。
Ec_point_formats:支持的曲線點格式,默認(rèn)都是uncompressed。
服務(wù)端回復(fù)server_hello,包含一個隨機數(shù)random2及ECC擴展。
服務(wù)端回復(fù)certificate,攜帶了證書公鑰。
服務(wù)端生成ECDH臨時公鑰,同時回復(fù)server_key_exchange,包含三部分重要內(nèi)容:
ECC相關(guān)的參數(shù)。
ECDH臨時公鑰。
ECC參數(shù)和公鑰生成的簽名值,用于客戶端校驗。
瀏覽器接收server_key_exchange之后,使用證書公鑰進行簽名解密和校驗,獲取服務(wù)器端的ECDH臨時公鑰,生成會話所需要的共享密鑰。
至此,瀏覽器端完成了密鑰協(xié)商。
瀏覽器生成ECDH臨時公鑰和client_key_exchange消息,跟RSA密鑰協(xié)商不同的是,這個消息不需要加密了。
服務(wù)器處理client_key_exchang消息,獲取客戶端ECDH臨時公鑰。
服務(wù)器生成會話所需要的共享密鑰。
服務(wù)端密鑰協(xié)商過程結(jié)束。
圖示如下:
圖4 ECDHE密鑰協(xié)商過程
對稱內(nèi)容加密
非對稱密鑰交換過程結(jié)束之后就得出了本次會話需要使用的對稱密鑰。對稱加密又分為兩種模式:流式加密和分組加密。流式加密現(xiàn)在常用的就是RC4,不過RC4已經(jīng)不再安全,微軟也建議網(wǎng)站盡量不要使用RC4流式加密。
一種新的替代RC4的流式加密算法叫ChaCha20,它是Google推出的速度更快,更安全的加密算法。目前已經(jīng)被Android和Chrome采用,也編譯進了Google的開源OpenSSL分支—BoringSSL,并且Nginx1.7.4也支持編譯BoringSSL。
分組加密以前常用的模式是AES-CBC,但是CBC已經(jīng)被證明容易遭受BEAST和LUCKY13攻擊。目前建議使用的分組加密模式是AES-GCM,不過它的缺點是計算量大,性能和電量消耗都比較高,不適用于移動電話和平板電腦。
身份認(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ù)字證書及CRL內(nèi)容存儲和分發(fā)。
申請一個受信任的數(shù)字證書通常有如下流程:
終端實體生成公私鑰和證書請求。
RA檢查實體的合法性。如果個人或者小網(wǎng)站,這一步不是必須的。
CA簽發(fā)證書,發(fā)送給申請者。
證書更新到repository,終端后續(xù)從repository更新證書,查詢證書狀態(tài)等。
目前百度使用的證書是X509v3格式,由如下三個部分組成:
tbsCertificate(to be signed certificate 待簽名證書內(nèi)容),這部分包含了10個要素,分別是版本號,序列號,簽名算法標(biāo)識,發(fā)行者名稱,有效期,證書主體名,證書主體公鑰信息,發(fā)行商唯一標(biāo)識,主體唯一標(biāo)識,擴展等。
signature Algorithm,簽名算法標(biāo)識,指定對tbsCertificate進行簽名的算法。
signaturValue(簽名值),使用signatureAlgorithm對tbsCertificate進行計算得到簽名值。
數(shù)字證書有兩個作用:
身份授權(quán)。確保瀏覽器訪問的網(wǎng)站是經(jīng)過CA驗證的可信任的網(wǎng)站。
分發(fā)公鑰。每個數(shù)字證書都包含了注冊者生成的公鑰。在SSL握手時會通過certificate消息傳輸給客戶端。比如前文提到的RSA證書公鑰加密及ECDHE的簽名都是使用的這個公鑰。
申請者拿到CA的證書并部署在網(wǎng)站服務(wù)器端,那瀏覽器發(fā)起握手接收到證書后,如何確認(rèn)這個證書就是CA簽發(fā)的呢?怎樣避免第三方偽造這個證書?
答案就是數(shù)字簽名(digital signature)。數(shù)字簽名是證書的防偽標(biāo)簽,目前使用最廣泛的SHA-RSA數(shù)字簽名的制作和驗證過程如下:
數(shù)字簽名的簽發(fā)。首先是使用哈希函數(shù)對待簽名內(nèi)容進行安全哈希,生成消息摘要,然后使用CA自己的私鑰對消息摘要進行加密。
數(shù)字簽名的校驗。使用CA的公鑰解密簽名,然后使用相同的簽名函數(shù)對待簽名證書內(nèi)容進行簽名并和服務(wù)端數(shù)字簽名里的簽名內(nèi)容進行比較,如果相同就認(rèn)為校驗成功。
圖5 數(shù)字簽名生成及校驗
這里有幾點需要說明:
數(shù)字簽名簽發(fā)和校驗使用的密鑰對是CA自己的公私密鑰,跟證書申請者提交的公鑰沒有關(guān)系。
數(shù)字簽名的簽發(fā)過程跟公鑰加密的過程剛好相反,即是用私鑰加密,公鑰解密。
現(xiàn)在大的CA都會有證書鏈,證書鏈的好處一是安全,保持根CA的私鑰離線使用。第二個好處是方便部署和撤銷,即如果證書出現(xiàn)問題,只需要撤銷相應(yīng)級別的證書,根證書依然安全。
根CA證書都是自簽名,即用自己的公鑰和私鑰完成了簽名的制作和驗證。而證書鏈上的證書簽名都是使用上一級證書的密鑰對完成簽名和驗證的。
怎樣獲取根CA和多級CA的密鑰對?它們是否可信?當(dāng)然可信,因為這些廠商跟瀏覽器和操作系統(tǒng)都有合作,它們的公鑰都默認(rèn)裝到了瀏覽器或者操作系統(tǒng)環(huán)境里。比如firefox就自己維護了一個可信任的CA列表,而Chrome和IE使用的是操作系統(tǒng)的CA列表。
數(shù)據(jù)完整性
這部分內(nèi)容比較好理解,跟平時的MD5簽名類似,只不過安全要求要高很多。OpenSSL現(xiàn)在使用的完整性校驗算法有兩種:MD5或者SHA。由于MD5在實際應(yīng)用中存在沖突的可能性比較大,所以盡量別采用MD5來驗證內(nèi)容一致性。SHA也不能使用SHA0和SHA1,中國山東大學(xué)的王小云教授在2005年就宣布破解了SHA-1完整版算法。
微軟和Google都已經(jīng)在16年及17年之后不再支持SHA1簽名證書。
HTTPS使用成本
HTTPS的使用成本和額外開銷,完全不用太過擔(dān)心。
一般來講,使用HTTPS前大家可能會非常關(guān)注如下問題:
證書費用以及更新維護。大家覺得申請證書很麻煩,證書也很貴,可是證書其實一點都不貴,便宜的一年幾十塊錢,最多也就幾百。而且現(xiàn)在也有了免費的證書機構(gòu),比如著名的Mozilla發(fā)起的免費證書項目:Let’s Encrypt(https://letsencrypt.org/)就支持免費證書安裝和自動更新。這個項目已于15年中旬投入正式使用。
數(shù)字證書的費用其實也不高,對于中小網(wǎng)站可以使用便宜甚至免費的數(shù)字證書服務(wù)(可能存在安全隱患),像著名的Verisign公司的證書一般也就幾千到幾萬塊一年不等。當(dāng)然如果公司對證書的需求比較大,定制性要求高,可以建立自己的CA站點,比如Google,能夠隨意簽發(fā)Google相關(guān)證書。
HTTPS降低用戶訪問速度。HTTPS對速度會有一定程度的降低,但是只要經(jīng)過合理優(yōu)化和部署,HTTPS對速度的影響完全可以接受。在很多場景下,HTTPS速度完全不遜于HTTP,如果使用SPDY,HTTPS的速度甚至還要比HTTP快。
大家現(xiàn)在使用百度HTTPS安全搜索,有感覺到慢嗎?
HTTPS消耗CPU資源,需要增加大量機器。前面介紹過非對稱密鑰交換,這是消耗CPU計算資源的大戶,此外,對稱加解密,也需要CPU的計算。
同樣地,只要合理優(yōu)化,HTTPS的機器成本也不會明顯增加。對于中小網(wǎng)站,完全不需要增加機器也能滿足性能需求。
國內(nèi)外的大型互聯(lián)網(wǎng)公司基本都已經(jīng)啟用了全站HTTPS,這也是互聯(lián)網(wǎng)的趨勢。百度搜索全站部署HTTPS,對國內(nèi)互聯(lián)網(wǎng)的全站HTTPS進程有著巨大的推動作用。
上述內(nèi)容就是如何理解HTTPS加密算法,你們學(xué)到知識或技能了嗎?如果還想學(xué)到更多技能或者豐富自己的知識儲備,歡迎關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道。
網(wǎng)站標(biāo)題:如何理解HTTPS加密算法-創(chuàng)新互聯(lián)
URL鏈接:http://www.chinadenli.net/article44/disghe.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供小程序開發(fā)、網(wǎng)站導(dǎo)航、網(wǎng)站設(shè)計公司、靜態(tài)網(wǎng)站、面包屑導(dǎo)航、搜索引擎優(yōu)化
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)
猜你還喜歡下面的內(nèi)容