本篇文章為大家展示了如何理解HTTPS加密算法，內(nèi)容簡(jiǎn)明扼要并且容易理解，絕對(duì)能使你眼前一亮，通過(guò)這篇文章的詳細(xì)介紹希望你能有所收獲。

我們提供的服務(wù)有：網(wǎng)站建設(shè)、做網(wǎng)站、微信公眾號(hào)開(kāi)發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、中陽(yáng)ssl等。為數(shù)千家企事業(yè)單位解決了網(wǎng)站和推廣的問(wèn)題。提供周到的售前咨詢(xún)和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的中陽(yáng)網(wǎng)站制作公司

前言

我們將會(huì)詳細(xì)介紹RSA和ECDHE算法的原理以及在HTTPS密鑰交換中的應(yīng)用。

非對(duì)稱(chēng)秘鑰交換

1RSA算法介紹

RSA算法的安全性是建立在乘法不可逆或者大數(shù)因子很難分解的基礎(chǔ)上。RSA的推導(dǎo)和實(shí)現(xiàn)涉及到了歐拉函數(shù)和費(fèi)馬定理及模反元素的概念，有興趣的讀者可以自行百度了解一下。

RSA算法是統(tǒng)治世界的最重要算法之一，而且從目前來(lái)看，RSA也是HTTPS體系中最重要的算法，沒(méi)有之一。

RSA的計(jì)算步驟如下：

1. 隨機(jī)挑選兩個(gè)質(zhì)數(shù)p，q，假設(shè)p=13，q=19。n=p*q=13*19=247;

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

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

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

圖1  加解密計(jì)算過(guò)程

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

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

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

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

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

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

圖2  百度HTTPS證書(shū)公鑰

2握手過(guò)程中的RSA秘鑰協(xié)商

介紹完了RSA的原理，那最終會(huì)話(huà)所需要的對(duì)稱(chēng)密鑰是如何生成的呢？跟RSA有什么關(guān)系？

以TLS1.2為例簡(jiǎn)單描述一下，省略跟密鑰交換無(wú)關(guān)的握手消息。過(guò)程如下：

1. 瀏覽器發(fā)送client_hello，包含一個(gè)隨機(jī)數(shù)random1。

2. 服務(wù)端回復(fù)server_hello，包含一個(gè)隨機(jī)數(shù)random2，同時(shí)回復(fù)certificate，攜帶了證書(shū)公鑰P。

3. 瀏覽器接收到random2之后就能夠生成premaster_secrect以及master_secrect。其中premaster_secret長(zhǎng)度為48個(gè)字節(jié)，前2個(gè)字節(jié)是協(xié)議版本號(hào)，剩下的46個(gè)字節(jié)填充一個(gè)隨機(jī)數(shù)。結(jié)構(gòu)如下：

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

   master secrect的生成算法簡(jiǎn)述如下：

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

   從上式可以看出，把premaster_key賦值給secret，“master key”賦值給label，瀏覽器和服務(wù)器端的兩個(gè)隨機(jī)數(shù)做種子就能確定地求出一個(gè)48位長(zhǎng)的隨機(jī)數(shù)。

   而master secrect包含了六部分內(nèi)容，分別是用于校驗(yàn)內(nèi)容一致性的密鑰，用于對(duì)稱(chēng)內(nèi)容加解密的密鑰，以及初始化向量（用于CBC模式），客戶(hù)端和服務(wù)端各一份。

   至此，瀏覽器側(cè)的密鑰已經(jīng)完成協(xié)商。

4. 瀏覽器使用證書(shū)公鑰P將premaster_secrect加密后發(fā)送給服務(wù)器。

5. 服務(wù)端使用私鑰解密得到premaster_secrect。又由于服務(wù)端之前就收到了隨機(jī)數(shù)1，所以服務(wù)端根據(jù)相同的生成算法，在相同的輸入?yún)?shù)下，求出了相同的master secrect。

RSA密鑰協(xié)商握手過(guò)程圖示如下：

圖3  RSA密鑰協(xié)商過(guò)程

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

3DH與ECC算法原理

ECDHE算法實(shí)現(xiàn)要復(fù)雜很多，主要分為兩部分：

Diffie-Hellman算法（簡(jiǎn)稱(chēng)為DH）及ECC（橢圓曲線(xiàn)算術(shù)）。他們的安全性都是建立在離散對(duì)數(shù)計(jì)算很困難的基礎(chǔ)上。

簡(jiǎn)單介紹一下DH算法的實(shí)現(xiàn)，先介紹兩個(gè)基本概念：

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

• 離散對(duì)數(shù)：對(duì)任意整數(shù)b和素?cái)?shù)p的本原根a，存在唯一的指數(shù)i滿(mǎn)足:

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

則稱(chēng)i是b的以a為底的模p的離散對(duì)數(shù)。

理解這兩個(gè)概念，DH算法就非常簡(jiǎn)單了，示例如下：

假設(shè)client和server需要協(xié)商密鑰，p=2579，則本原根a=2。

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

2. server選擇隨機(jī)數(shù)Ks=293作為私鑰，計(jì)算Ys=a^Ks mod p=s^293 mod 2579=968，把Ys作為公鑰發(fā)送給client。

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

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

上述公式中的Ys，Yc，P，a，都是公開(kāi)信息，可以被中間者查看，只有Ks，Kc作為私鑰沒(méi)有公開(kāi)，當(dāng)私鑰較小時(shí)，通過(guò)窮舉攻擊能夠計(jì)算出共享密鑰，但是當(dāng)私鑰非常大時(shí)，窮舉攻擊肯定是不可行的。

DH算法有一個(gè)比較大的缺陷就是需要提供足夠大的私鑰來(lái)保證安全性，所以比較消耗CPU計(jì)算資源。ECC橢圓曲線(xiàn)算術(shù)能夠很好的解決這個(gè)問(wèn)題，224位的密鑰長(zhǎng)度就能達(dá)到RSA2048位的安全強(qiáng)度。

ECC的曲線(xiàn)公式描述的其實(shí)不是橢圓，只是跟橢圓曲線(xiàn)周長(zhǎng)公式形似才叫橢圓曲線(xiàn)加密算術(shù)。ECC涉及到了有限域、群等近世代數(shù)的多個(gè)概念，就不做詳細(xì)介紹了。

ECC安全性依賴(lài)于這樣一個(gè)事實(shí)：

P=kQ，已知k，Q求出P相對(duì)簡(jiǎn)單，但是已知P和Q求出k卻非常困難。

上式看起來(lái)非常簡(jiǎn)單，但有如下約束條件：

1. Q是一個(gè)非常大的質(zhì)數(shù)，p，k，q都是橢圓曲線(xiàn)有限域上的離散點(diǎn)。

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

ECC應(yīng)用于Diffie-Hellman密鑰交換過(guò)程如下：

1. 定義一個(gè)滿(mǎn)足橢圓方程的有限域，即挑選p，a，b滿(mǎn)足如下方程：

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

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

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

4. server選擇私鑰Ks并產(chǎn)生公鑰Ys=Ks*G

5. client計(jì)算共享密鑰K=Kc*Ys，server端計(jì)算共享密鑰Ks*Yc，這兩者的結(jié)果是一樣的，因?yàn)椋?/p>

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

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

OpenSSL實(shí)現(xiàn)的，也是FIPS推薦的256位素?cái)?shù)域上的橢圓曲線(xiàn)參數(shù)定義如下：

質(zhì)數(shù)p=115792089210356248762697446949407573530086143415290314195533631308867097853951 階n=115792089210356248762697446949407573529996955224135760342422259061068512044369 橢圓曲線(xiàn)的系數(shù)a=0 橢圓曲線(xiàn)的系統(tǒng)b=5ac635d8 aa3a93e7 b3ebbd55 769886bc 651d06b0 cc53b0f63bce3c3e 27d2604b 基點(diǎn) G x = 6b17d1f2 e12c4247 f8bce6e5 63a440f2 77037d81 2deb33a0f4a13945 d898c296 基點(diǎn) G y = 4fe342e2 fe1a7f9b 8ee7eb4a 7c0f9e16 2bce3357 6b315ececbb64068 37bf51f5

4握手過(guò)程中的ECDHE秘鑰協(xié)商

簡(jiǎn)單介紹了ECC和DH算法的數(shù)學(xué)原理，我們看下ECDHE在TLS握手過(guò)程中的應(yīng)用。

相比RSA，ECDHE需要多發(fā)送一個(gè)server_key_exchange的握手消息才能完成密鑰協(xié)商。

同樣以TLS1.2為例，簡(jiǎn)單描述一下過(guò)程：

1. 瀏覽器發(fā)送client_hello，包含一個(gè)隨機(jī)數(shù)random1，同時(shí)需要有2個(gè)擴(kuò)展：

1. Elliptic_curves：客戶(hù)端支持的曲線(xiàn)類(lèi)型和有限域參數(shù)?，F(xiàn)在使用最多的是256位的素?cái)?shù)域，參數(shù)定義如上節(jié)所述。

2. Ec_point_formats：支持的曲線(xiàn)點(diǎn)格式，默認(rèn)都是uncompressed。

2. 服務(wù)端回復(fù)server_hello，包含一個(gè)隨機(jī)數(shù)random2及ECC擴(kuò)展。

3. 服務(wù)端回復(fù)certificate，攜帶了證書(shū)公鑰。

4. 服務(wù)端生成ECDH臨時(shí)公鑰，同時(shí)回復(fù)server_key_exchange，包含三部分重要內(nèi)容：

1. ECC相關(guān)的參數(shù)。

2. ECDH臨時(shí)公鑰。

3. ECC參數(shù)和公鑰生成的簽名值，用于客戶(hù)端校驗(yàn)。

5. 瀏覽器接收server_key_exchange之后，使用證書(shū)公鑰進(jìn)行簽名解密和校驗(yàn)，獲取服務(wù)器端的ECDH臨時(shí)公鑰，生成會(huì)話(huà)所需要的共享密鑰。

   至此，瀏覽器端完成了密鑰協(xié)商。

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

7. 服務(wù)器處理client_key_exchang消息，獲取客戶(hù)端ECDH臨時(shí)公鑰。

8. 服務(wù)器生成會(huì)話(huà)所需要的共享密鑰。

9. 服務(wù)端密鑰協(xié)商過(guò)程結(jié)束。

圖示如下：

圖4  ECDHE密鑰協(xié)商過(guò)程

對(duì)稱(chēng)內(nèi)容加密

非對(duì)稱(chēng)密鑰交換過(guò)程結(jié)束之后就得出了本次會(huì)話(huà)需要使用的對(duì)稱(chēng)密鑰。對(duì)稱(chēng)加密又分為兩種模式：流式加密和分組加密。流式加密現(xiàn)在常用的就是RC4，不過(guò)RC4已經(jīng)不再安全，微軟也建議網(wǎng)站盡量不要使用RC4流式加密。

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

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

身份認(rèn)證

身份認(rèn)證主要涉及到PKI和數(shù)字證書(shū)。通常來(lái)講PKI（公鑰基礎(chǔ)設(shè)施）包含如下部分：

• End entity：終端實(shí)體，可以是一個(gè)終端硬件或者網(wǎng)站。

• CA：證書(shū)簽發(fā)機(jī)構(gòu)。

• RA：證書(shū)注冊(cè)及審核機(jī)構(gòu)。比如審查申請(qǐng)網(wǎng)站或者公司的真實(shí)性。

• CRL issuer：負(fù)責(zé)證書(shū)撤銷(xiāo)列表的發(fā)布和維護(hù)。

• Repository：負(fù)責(zé)數(shù)字證書(shū)及CRL內(nèi)容存儲(chǔ)和分發(fā)。

申請(qǐng)一個(gè)受信任的數(shù)字證書(shū)通常有如下流程：

1. 終端實(shí)體生成公私鑰和證書(shū)請(qǐng)求。

2. RA檢查實(shí)體的合法性。如果個(gè)人或者小網(wǎng)站，這一步不是必須的。

3. CA簽發(fā)證書(shū)，發(fā)送給申請(qǐng)者。

4. 證書(shū)更新到repository，終端后續(xù)從repository更新證書(shū)，查詢(xún)證書(shū)狀態(tài)等。

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

1. tbsCertificate(to be signed certificate 待簽名證書(shū)內(nèi)容)，這部分包含了10個(gè)要素，分別是版本號(hào)，序列號(hào)，簽名算法標(biāo)識(shí)，發(fā)行者名稱(chēng)，有效期，證書(shū)主體名，證書(shū)主體公鑰信息，發(fā)行商唯一標(biāo)識(shí)，主體唯一標(biāo)識(shí)，擴(kuò)展等。

2. signature Algorithm，簽名算法標(biāo)識(shí)，指定對(duì)tbsCertificate進(jìn)行簽名的算法。

3. signaturValue（簽名值），使用signatureAlgorithm對(duì)tbsCertificate進(jìn)行計(jì)算得到簽名值。

數(shù)字證書(shū)有兩個(gè)作用：

1. 身份授權(quán)。確保瀏覽器訪(fǎng)問(wèn)的網(wǎng)站是經(jīng)過(guò)CA驗(yàn)證的可信任的網(wǎng)站。

2. 分發(fā)公鑰。每個(gè)數(shù)字證書(shū)都包含了注冊(cè)者生成的公鑰。在SSL握手時(shí)會(huì)通過(guò)certificate消息傳輸給客戶(hù)端。比如前文提到的RSA證書(shū)公鑰加密及ECDHE的簽名都是使用的這個(gè)公鑰。

申請(qǐng)者拿到CA的證書(shū)并部署在網(wǎng)站服務(wù)器端，那瀏覽器發(fā)起握手接收到證書(shū)后，如何確認(rèn)這個(gè)證書(shū)就是CA簽發(fā)的呢？怎樣避免第三方偽造這個(gè)證書(shū)？

答案就是數(shù)字簽名（digital signature）。數(shù)字簽名是證書(shū)的防偽標(biāo)簽，目前使用最廣泛的SHA-RSA數(shù)字簽名的制作和驗(yàn)證過(guò)程如下：

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

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

圖5  數(shù)字簽名生成及校驗(yàn)

這里有幾點(diǎn)需要說(shuō)明：

1. 數(shù)字簽名簽發(fā)和校驗(yàn)使用的密鑰對(duì)是CA自己的公私密鑰，跟證書(shū)申請(qǐng)者提交的公鑰沒(méi)有關(guān)系。

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

3. 現(xiàn)在大的CA都會(huì)有證書(shū)鏈，證書(shū)鏈的好處一是安全，保持根CA的私鑰離線(xiàn)使用。第二個(gè)好處是方便部署和撤銷(xiāo)，即如果證書(shū)出現(xiàn)問(wèn)題，只需要撤銷(xiāo)相應(yīng)級(jí)別的證書(shū)，根證書(shū)依然安全。

4. 根CA證書(shū)都是自簽名，即用自己的公鑰和私鑰完成了簽名的制作和驗(yàn)證。而證書(shū)鏈上的證書(shū)簽名都是使用上一級(jí)證書(shū)的密鑰對(duì)完成簽名和驗(yàn)證的。

5. 怎樣獲取根CA和多級(jí)CA的密鑰對(duì)？它們是否可信？當(dāng)然可信，因?yàn)檫@些廠(chǎng)商跟瀏覽器和操作系統(tǒng)都有合作，它們的公鑰都默認(rèn)裝到了瀏覽器或者操作系統(tǒng)環(huán)境里。比如firefox就自己維護(hù)了一個(gè)可信任的CA列表，而Chrome和IE使用的是操作系統(tǒng)的CA列表。

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

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

微軟和Google都已經(jīng)在16年及17年之后不再支持SHA1簽名證書(shū)。

HTTPS使用成本

HTTPS的使用成本和額外開(kāi)銷(xiāo)，完全不用太過(guò)擔(dān)心。

一般來(lái)講，使用HTTPS前大家可能會(huì)非常關(guān)注如下問(wèn)題：

1. 證書(shū)費(fèi)用以及更新維護(hù)。大家覺(jué)得申請(qǐng)證書(shū)很麻煩，證書(shū)也很貴，可是證書(shū)其實(shí)一點(diǎn)都不貴，便宜的一年幾十塊錢(qián)，最多也就幾百。而且現(xiàn)在也有了免費(fèi)的證書(shū)機(jī)構(gòu)，比如著名的Mozilla發(fā)起的免費(fèi)證書(shū)項(xiàng)目：Let’s Encrypt（https://letsencrypt.org/）就支持免費(fèi)證書(shū)安裝和自動(dòng)更新。這個(gè)項(xiàng)目已于15年中旬投入正式使用。

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

2. HTTPS降低用戶(hù)訪(fǎng)問(wèn)速度。HTTPS對(duì)速度會(huì)有一定程度的降低，但是只要經(jīng)過(guò)合理優(yōu)化和部署，HTTPS對(duì)速度的影響完全可以接受。在很多場(chǎng)景下，HTTPS速度完全不遜于HTTP，如果使用SPDY，HTTPS的速度甚至還要比HTTP快。

   大家現(xiàn)在使用百度HTTPS安全搜索，有感覺(jué)到慢嗎？

3. HTTPS消耗CPU資源，需要增加大量機(jī)器。前面介紹過(guò)非對(duì)稱(chēng)密鑰交換，這是消耗CPU計(jì)算資源的大戶(hù)，此外，對(duì)稱(chēng)加解密，也需要CPU的計(jì)算。

同樣地，只要合理優(yōu)化，HTTPS的機(jī)器成本也不會(huì)明顯增加。對(duì)于中小網(wǎng)站，完全不需要增加機(jī)器也能滿(mǎn)足性能需求。

國(guó)內(nèi)外的大型互聯(lián)網(wǎng)公司基本都已經(jīng)啟用了全站HTTPS，這也是互聯(lián)網(wǎng)的趨勢(shì)。百度搜索全站部署HTTPS，對(duì)國(guó)內(nèi)互聯(lián)網(wǎng)的全站HTTPS進(jìn)程有著巨大的推動(dòng)作用。

上述內(nèi)容就是如何理解HTTPS加密算法，你們學(xué)到知識(shí)或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識(shí)儲(chǔ)備，歡迎關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道。

網(wǎng)站標(biāo)題：如何理解HTTPS加密算法-創(chuàng)新互聯(lián)
URL鏈接：http://jinyejixie.com/article44/disghe.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供小程序開(kāi)發(fā)、網(wǎng)站導(dǎo)航、網(wǎng)站設(shè)計(jì)公司、靜態(tài)網(wǎng)站、面包屑導(dǎo)航、搜索引擎優(yōu)化

廣告

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