本篇文章為大家展示了將全站進(jìn)行HTTPS化優(yōu)勢(shì)是什么，內(nèi)容簡(jiǎn)明扼要并且容易理解，絕對(duì)能使你眼前一亮，通過(guò)這篇文章的詳細(xì)介紹希望你能有所收獲。

成都創(chuàng)新互聯(lián)成都網(wǎng)站建設(shè)定制網(wǎng)站開(kāi)發(fā)，是成都網(wǎng)站維護(hù)公司,為成都酒樓設(shè)計(jì)提供網(wǎng)站建設(shè)服務(wù),有成熟的網(wǎng)站定制合作流程，提供網(wǎng)站定制設(shè)計(jì)服務(wù)：原型圖制作、網(wǎng)站創(chuàng)意設(shè)計(jì)、前端HTML5制作、后臺(tái)程序開(kāi)發(fā)等。成都網(wǎng)站營(yíng)銷推廣熱線：18982081108

在HTTPS項(xiàng)目的開(kāi)展過(guò)程中明顯感覺(jué)到目前國(guó)內(nèi)互聯(lián)網(wǎng)對(duì)HTTPS并不是很重視，其實(shí)也就是對(duì)用戶隱私和網(wǎng)絡(luò)安全不重視。從保護(hù)用戶隱私的角度出發(fā)，簡(jiǎn)單描述現(xiàn)在存在的用戶隱私泄露和流量劫持現(xiàn)象，然后進(jìn)一步說(shuō)明為什么HTTPS能夠保護(hù)用戶安全以及HTTPS使用過(guò)程中需要注意的地方。

1，用戶隱私泄露的風(fēng)險(xiǎn)很大
人們的生活現(xiàn)在已經(jīng)越來(lái)越離不開(kāi)互聯(lián)網(wǎng)，不管是社交、購(gòu)物還是搜索，互聯(lián)網(wǎng)都能帶給人們很多的便捷。與此同時(shí)，用戶“裸露”在互聯(lián)網(wǎng)的信息也越來(lái)越多，另一個(gè)問(wèn)題也日益嚴(yán)重，那就是隱私和安全。
幾乎所有的互聯(lián)網(wǎng)公司都存在用戶隱私泄露和流量劫持的風(fēng)險(xiǎn)。BAT樹大招風(fēng)，這方面的問(wèn)題尤其嚴(yán)重。比如用戶在百度搜索一個(gè)關(guān)鍵詞，“人流”，很快就會(huì)有醫(yī)院打電話過(guò)來(lái)推銷人流手術(shù)廣告，不知情的用戶還以為是百度出賣了他的手機(jī)號(hào)和搜索信息。同樣地，用戶在淘寶搜索的關(guān)鍵詞也很容易被第三方截獲并私下通過(guò)電話或者其他廣告形式騷擾用戶。而QQ和微信呢，顯然用戶不希望自己的聊天內(nèi)容被其他人輕易知道。為什么BAT不可能出賣用戶隱私信息給第三方呢？因?yàn)楸Ｗo(hù)用戶隱私是任何一個(gè)想要長(zhǎng)期發(fā)展的互聯(lián)網(wǎng)公司的安身立命之本，如果用戶發(fā)現(xiàn)使用一個(gè)公司的產(chǎn)品存在嚴(yán)重的隱私泄露問(wèn)題，顯然不會(huì)再信任該公司的產(chǎn)品，最終該公司也會(huì)因?yàn)橛脩舸罅苛魇Ф萑胛C(jī)。所以任何一家大型互聯(lián)網(wǎng)公司都不可能因?yàn)槎唐诶娑鲑u甚至忽視用戶隱私。
那既然互聯(lián)網(wǎng)公司都知道用戶隱私的重要性，是不是用戶隱私就得到了很好的保護(hù)呢？現(xiàn)實(shí)卻并不盡如人意。由于目前的WEB應(yīng)用和網(wǎng)站絕大部分是基于HTTP協(xié)議，國(guó)內(nèi)沒(méi)有任何一家大型互聯(lián)網(wǎng)公司采用全站HTTPS方案來(lái)保護(hù)用戶隱私（排除支付和登陸相關(guān)的網(wǎng)站或者頁(yè)面以及PC端的微信）。因?yàn)镠TTP協(xié)議簡(jiǎn)單方便，易于部署，并且設(shè)計(jì)之初也沒(méi)有考慮安全性，所有內(nèi)容都是明文傳輸，也就為現(xiàn)在的安全問(wèn)題埋下了隱患。用戶在基于HTTP協(xié)議的WEB應(yīng)用上的傳輸內(nèi)容都可以被中間者輕易查看和修改。
比如你在百度搜索了一個(gè)關(guān)鍵詞“https“，中間者通過(guò)tcpdump或者wireshark等工具就很容易知道發(fā)送請(qǐng)求的全部?jī)?nèi)容。wireshark的截圖如下：

這里所謂的中間者是指網(wǎng)絡(luò)傳輸內(nèi)容需要經(jīng)過(guò)的網(wǎng)絡(luò)節(jié)點(diǎn)，既有硬件也有軟件，比如中間代理服務(wù)器、路由器、小區(qū)WIFI熱點(diǎn)、公司統(tǒng)一網(wǎng)關(guān)出口等。這里面最容易拿到用戶內(nèi)容的就是各種通信服務(wù)運(yùn)營(yíng)商和二級(jí)網(wǎng)絡(luò)帶寬提供商。而最有可能被第三方黑客動(dòng)手腳的就是離用戶相對(duì)較近的節(jié)點(diǎn)。
中間者為什么要查看或者修改用戶真實(shí)請(qǐng)求內(nèi)容呢？很簡(jiǎn)單，為了利益。常見(jiàn)的幾種危害比較大的中間內(nèi)容劫持形式如下：
獲取無(wú)線用戶的手機(jī)號(hào)和搜索內(nèi)容并私下通過(guò)電話廣告騷擾用戶。為什么能夠獲取用戶手機(jī)號(hào)？呵呵，因?yàn)楦\(yùn)營(yíng)商有合作。
獲取用戶帳號(hào)cookie，盜取帳號(hào)有用信息。
在用戶目的網(wǎng)站返回的內(nèi)容里添加第三方內(nèi)容，比如廣告、釣魚鏈接、植入木馬等。
總結(jié)來(lái)講，由于HTTP明文傳輸，同時(shí)中間內(nèi)容劫持的利益巨大，所以用戶隱私泄露的風(fēng)險(xiǎn)非常高。

2，HTTPS能有效保護(hù)用戶隱私
HTTPS就等于HTTP加上TLS（SSL)，HTTPS協(xié)議的目標(biāo)主要有三個(gè)：
數(shù)據(jù)保密性。保證內(nèi)容在傳輸過(guò)程中不會(huì)被第三方查看到。就像快遞員傳遞包裹時(shí)都進(jìn)行了封裝，別人無(wú)法知道里面裝了什么東西。
數(shù)據(jù)完整性。及時(shí)發(fā)現(xiàn)被第三方篡改的傳輸內(nèi)容。就像快遞員雖然不知道包裹里裝了什么東西，但他有可能中途掉包，數(shù)據(jù)完整性就是指如果被掉包，我們能輕松發(fā)現(xiàn)并拒收。
身份校驗(yàn)。保證數(shù)據(jù)到達(dá)用戶期望的目的地。就像我們郵寄包裹時(shí)，雖然是一個(gè)封裝好的未掉包的包裹，但必須確定這個(gè)包裹不會(huì)送錯(cuò)地方。
通俗地描述上述三個(gè)目標(biāo)就是封裝加密，防篡改掉包，防止身份冒充，那TLS是如何做到上述三點(diǎn)的呢？我分別簡(jiǎn)述一下。
2.1 數(shù)據(jù)保密性
2.1.1 非對(duì)稱加密及密鑰交換
數(shù)據(jù)的保密性主要是通過(guò)加密完成的。加密算法一般分為兩種，一種是非對(duì)稱加密（也叫公鑰加密），另外一種是對(duì)稱加密（也叫密鑰加密）。所謂非對(duì)稱加密就是指加密和解密使用的密鑰不一樣，如下圖：

HTTPS使用非對(duì)稱加解密主要有兩個(gè)作用，一個(gè)是密鑰協(xié)商，另外可以用來(lái)做數(shù)字簽名。所謂密鑰協(xié)商簡(jiǎn)單說(shuō)就是根據(jù)雙方各自的信息計(jì)算得出雙方傳輸內(nèi)容時(shí)對(duì)稱加解密需要使用的密鑰。
公鑰加密過(guò)程一般都是服務(wù)器掌握私鑰，客戶端掌握公鑰，私鑰用來(lái)解密，公鑰用來(lái)加密。公鑰可以發(fā)放給任何人知道，但是私鑰只有服務(wù)器掌握，所以公鑰加解密非常安全。當(dāng)然這個(gè)安全性必須建立在公鑰長(zhǎng)度足夠大的基礎(chǔ)上，目前公鑰最低安全長(zhǎng)度也需要達(dá)到2048位。大的CA也不再支持2048位以下的企業(yè)級(jí)證書申請(qǐng)。因?yàn)?024位及以下的公鑰長(zhǎng)度已經(jīng)不再安全，可以被高性能計(jì)算機(jī)比如量子計(jì)算機(jī)強(qiáng)行破解。計(jì)算性能基本會(huì)隨著公鑰的長(zhǎng)度而呈2的指數(shù)級(jí)下降。
既然如此為什么還需要對(duì)稱加密？為什么不一直使用非對(duì)稱加密算法來(lái)完成全部的加解密過(guò)程？主要是兩點(diǎn)：
非對(duì)稱加解密對(duì)性能的消耗非常大，一次完全TLS握手，密鑰交換時(shí)的非對(duì)稱解密計(jì)算量占整個(gè)握手過(guò)程的95%。而對(duì)稱加密的計(jì)算量只相當(dāng)于非對(duì)稱加密的0.1%，如果應(yīng)用層數(shù)據(jù)也使用非對(duì)稱加解密，性能開(kāi)銷太大，無(wú)法承受。
非對(duì)稱加密算法對(duì)加密內(nèi)容的長(zhǎng)度有限制，不能超過(guò)公鑰長(zhǎng)度。比如現(xiàn)在常用的公鑰長(zhǎng)度是2048位，意味著待加密內(nèi)容不能超過(guò)256個(gè)字節(jié)。
目前常用的非對(duì)稱加密算法是RSA，想強(qiáng)調(diào)一點(diǎn)的就是RSA是整個(gè)PKI體系及加解密領(lǐng)域里最重要的算法。如果想深入理解HTTPS的各個(gè)方面，RSA是必需要掌握的知識(shí)點(diǎn)。它的原理主要依賴于三點(diǎn)：
乘法的不可逆特性。即我們很容易由兩個(gè)乘數(shù)求出它們的積，但是給定一個(gè)乘積，很難求出它是由哪兩個(gè)乘數(shù)因子相乘得出的。
歐拉函數(shù)。歐拉函數(shù).varphi(n)是小于或等于n的正整數(shù)中與n互質(zhì)的數(shù)的數(shù)目
費(fèi)馬小定理。假如a是一個(gè)整數(shù)，p是一個(gè)質(zhì)數(shù)，那么a^p - a 是p的倍數(shù)。
RSA算法是第一個(gè)也是目前一個(gè)既能用于密鑰交換又能用于數(shù)字簽名的算法。另外一個(gè)非常重要的密鑰協(xié)商算法是diffie-hellman(DH).DH不需要預(yù)先知道通信雙方的信息就能完成密鑰的協(xié)商，它使用一個(gè)素?cái)?shù)P的整數(shù)乘法群以及原根G，理論依據(jù)就是離散對(duì)數(shù)。
openssl目前只支持如下密鑰交換算法：RSA，DH，ECDH, DHE，ECDHE。各個(gè)算法的性能和對(duì)速度的影響可以參考后面章節(jié)，由于篇幅有限，具體實(shí)現(xiàn)不再做詳細(xì)介紹。
2.1.2 對(duì)稱加密
對(duì)稱加密就是加密和解密都使用的是同一個(gè)密鑰。如下圖：

采用非對(duì)稱密碼算法的密鑰協(xié)商過(guò)程結(jié)束之后就已經(jīng)得出了本次會(huì)話需要使用的對(duì)稱密鑰。對(duì)稱加密又分為兩種模式：流式加密和分組加密。流式加密現(xiàn)在常用的就是RC4，不過(guò)RC4已經(jīng)不再安全，微軟也建議網(wǎng)站盡量不要使用RC4流式加密。支付寶可能沒(méi)有意識(shí)到這一點(diǎn)，也可能是由于其他原因，他們?nèi)匀辉谑褂肦C4算法和TLS1.0協(xié)議。

一種新的替代RC4的流式加密算法叫ChaCha20，它是google推出的速度更快，更安全的加密算法。目前已經(jīng)被android和chrome采用，也編譯進(jìn)了google的開(kāi)源openssl分支---boring ssl，并且nginx 1.7.4也支持編譯boringssl。我目前還沒(méi)有比較這種算法的性能，但部分資料顯示這個(gè)算法對(duì)性能的消耗比較小，特別是移動(dòng)端提升比較明顯。 
分組加密以前常用的模式是AES-CBC，但是CBC已經(jīng)被證明容易遭受BEAST和LUCKY13攻擊。目前建議使用的分組加密模式是AES-GCM，不過(guò)它的缺點(diǎn)是計(jì)算量大，性能和電量消耗都比較高，不適用于移動(dòng)電話和平板電腦。盡管如此，它仍然是我們的優(yōu)先選擇。
2.2 數(shù)據(jù)完整性
這部分內(nèi)容相對(duì)比較簡(jiǎn)單，openssl現(xiàn)在使用的完整性校驗(yàn)算法有兩種：MD5或者SHA。由于MD5在實(shí)際應(yīng)用中存在沖突的可能性比較大，所以盡量別采用MD5來(lái)驗(yàn)證內(nèi)容一致性。SHA也不能使用SHA0和SHA１，中國(guó)山東大學(xué)的王小云教授在2005年就牛逼地宣布破解了SHA-1完整版算法。建議使用SHA２算法，即輸出的摘要長(zhǎng)度超過(guò)224位。
2.3 身份驗(yàn)證和授權(quán)
這里主要介紹的就是PKI和數(shù)字證書。數(shù)字證書有兩個(gè)作用：
身份驗(yàn)證。確保客戶端訪問(wèn)的網(wǎng)站是經(jīng)過(guò)CA驗(yàn)證的可信任的網(wǎng)站。
分發(fā)公鑰。每個(gè)數(shù)字證書都包含了注冊(cè)者生成的公鑰。在SSL握手時(shí)會(huì)通過(guò)certificate消息傳輸給客戶端。
這里簡(jiǎn)單介紹一下數(shù)字證書是如何驗(yàn)證網(wǎng)站身份的。
證書申請(qǐng)者首先會(huì)生成一對(duì)密鑰，包含公鑰和密鑰，然后把公鑰及域名還有CU等資料制作成CSR格式的請(qǐng)求發(fā)送給RA，RA驗(yàn)證完這些內(nèi)容之后（RA會(huì)請(qǐng)獨(dú)立的第三方機(jī)構(gòu)和律師團(tuán)隊(duì)確認(rèn)申請(qǐng)者的身份）再將CSR發(fā)送給CA，CA然后制作X.509格式的證書。
那好，申請(qǐng)者拿到CA的證書并部署在網(wǎng)站服務(wù)器端，那瀏覽器訪問(wèn)時(shí)接收到證書后，如何確認(rèn)這個(gè)證書就是CA簽發(fā)的呢？怎樣避免第三方偽造這個(gè)證書？
答案就是數(shù)字簽名（digital signature）。數(shù)字簽名可以認(rèn)為是一個(gè)證書的防偽標(biāo)簽，目前使用最廣泛的SHA-RSA數(shù)字簽名的制作和驗(yàn)證過(guò)程如下：
數(shù)字簽名的簽發(fā)。首先是使用哈希函數(shù)對(duì)證書數(shù)據(jù)哈希，生成消息摘要，然后使用CA自己的私鑰對(duì)證書內(nèi)容和消息摘要進(jìn)行加密。
數(shù)字簽名的校驗(yàn)。使用CA的公鑰解密簽名，然后使用相同的簽名函數(shù)對(duì)證書內(nèi)容進(jìn)行簽名并和服務(wù)端的數(shù)字簽名里的簽名內(nèi)容進(jìn)行比較，如果相同就認(rèn)為校驗(yàn)成功。
圖形表示如下：

這里有幾點(diǎn)需要說(shuō)明：
數(shù)字簽名簽發(fā)和校驗(yàn)使用的密鑰對(duì)是CA自己的公私密鑰，跟證書申請(qǐng)者提交的公鑰沒(méi)有關(guān)系。
數(shù)字簽名的簽發(fā)過(guò)程跟公鑰加密的過(guò)程剛好相反，即是用私鑰加密，公鑰解密。
現(xiàn)在大的CA都會(huì)有證書鏈，證書鏈的好處一是安全，保持根CA的私鑰離線使用。第二個(gè)好處是方便部署和撤銷，即如何證書出現(xiàn)問(wèn)題，只需要撤銷相應(yīng)級(jí)別的證書，根證書依然安全。
根CA證書都是自簽名，即用自己的公鑰和私鑰完成了簽名的制作和驗(yàn)證。而證書鏈上的證書簽名都是使用上一級(jí)證書的密鑰對(duì)完成簽名和驗(yàn)證的。
怎樣獲取根CA和多級(jí)CA的密鑰對(duì)？它們是否可信？當(dāng)然可信，因?yàn)檫@些廠商跟瀏覽器和操作系統(tǒng)都有合作，它們的公鑰都默認(rèn)裝到了瀏覽器或者操作系統(tǒng)環(huán)境里。比如firefox就自己維護(hù)了一個(gè)可信任的CA列表，而chrome和IE使用的是操作系統(tǒng)的CA列表。
數(shù)字證書的費(fèi)用其實(shí)也不高，對(duì)于中小網(wǎng)站可以使用便宜甚至免費(fèi)的數(shù)字證書服務(wù)（可能存在安全隱患），像著名的verisign公司的證書一般也就幾千到幾萬(wàn)塊一年不等。當(dāng)然如果公司對(duì)證書的需求比較大，定制性要求高，可以建立自己的CA站點(diǎn)，比如google，能夠隨意簽發(fā)google相關(guān)證書。

3，HTTPS對(duì)速度和性能的影響
既然HTTPS非常安全，數(shù)字證書費(fèi)用也不高，那為什么互聯(lián)網(wǎng)公司不全部使用HTTPS呢？原因主要有兩點(diǎn)：
HTTPS對(duì)速度的影響非常明顯。每個(gè)HTTPS連接一般會(huì)增加1-3個(gè)RTT，加上加解密對(duì)性能的消耗，延時(shí)還有可能再增加幾十毫秒。
HTTPS對(duì)CPU計(jì)算能力的消耗很嚴(yán)重，完全握手時(shí)，web server的處理能力會(huì)降低至HTTP的10%甚至以下。
下面簡(jiǎn)單分析一下這兩點(diǎn)。
3.1 HTTPS對(duì)訪問(wèn)速度的影響
我用一張圖來(lái)表示一個(gè)用戶訪問(wèn)使用HTTPS網(wǎng)站可能增加的延時(shí)：

HTTPS增加的延時(shí)主要體現(xiàn)在三個(gè)階段，包含了上圖所示的2和3階段。
302跳轉(zhuǎn)。為什么需要302？因?yàn)橛脩魬小Ｎ蚁虢^大部分網(wǎng)民平時(shí)訪問(wèn)百度時(shí)都是輸入www.baidu.com或者baidu.com吧？很少有輸入http://www.baidu.com訪問(wèn)百度搜索的吧？至于直接輸入https://www.baidu.com來(lái)訪問(wèn)百度的HTTPS服務(wù)的就更加少了。所以為了強(qiáng)制用戶使用HTTPS服務(wù)，只有將用戶發(fā)起的HTTP請(qǐng)求www.baidu.com302成https://www.baidu.com。這無(wú)疑是增加一個(gè)RTT的跳轉(zhuǎn)延時(shí)。
上圖第三階段的SSL完全握手對(duì)延時(shí)的影響就更加明顯了，這個(gè)影響不僅體現(xiàn)在網(wǎng)絡(luò)傳輸?shù)腞TT上，還包含了數(shù)字簽名的校驗(yàn)，由于客戶端特別是移動(dòng)端的計(jì)算性能弱，增加幾十毫秒的計(jì)算延時(shí)是很常見(jiàn)的。
還有一個(gè)延時(shí)沒(méi)有畫出來(lái)，就是證書的狀態(tài)檢查，現(xiàn)在稍微新一點(diǎn)的瀏覽器都使用ocsp來(lái)檢查證書的撤銷狀態(tài)，在拿到服務(wù)器的證書內(nèi)容之后會(huì)訪問(wèn)ocsp站點(diǎn)獲取證書的狀態(tài)，檢查證書是否撤銷。如果這個(gè)ocsp站點(diǎn)在國(guó)外或者ocsp服務(wù)器出現(xiàn)故障，顯然會(huì)影響這個(gè)正常用戶的訪問(wèn)速度。不過(guò)還好ocsp的檢查周期一般都是7天一次，所以這個(gè)對(duì)速度的影響還不是很頻繁。 另外chrome默認(rèn)是關(guān)閉了ocsp及crl功能，新版的firefox開(kāi)啟了這個(gè)功能，如果ocsp返回不正確，用戶無(wú)法打開(kāi)訪問(wèn)網(wǎng)站。
實(shí)際測(cè)試發(fā)現(xiàn)，在沒(méi)有任何優(yōu)化的情況下，HTTPS會(huì)增加200ms以上的延時(shí)。
那是不是對(duì)于這些延時(shí)我們就無(wú)法優(yōu)化了呢？顯然不是，部分優(yōu)化方式參考如下：
服務(wù)器端配置HSTS，減少302跳轉(zhuǎn)，其實(shí)HSTS的較大作用是防止302 HTTP劫持。HSTS的缺點(diǎn)是瀏覽器支持率不高，另外配置HSTS后HTTPS很難實(shí)時(shí)降級(jí)成HTTP。
設(shè)置ssl session 的共享內(nèi)存cache. 以nginx為例，它目前只支持session cache的單機(jī)多進(jìn)程共享。配置如下：
ssl_session_cache    shared:SSL:10m; 
如果是前端接入是多服務(wù)器架構(gòu)，這樣的session cache是沒(méi)有作用的，所以需要實(shí)現(xiàn)session cache的多機(jī)共享機(jī)制。我們已經(jīng)在nginx 1.6.0版本上實(shí)現(xiàn)了多機(jī)共享的session cache。多機(jī)session cache的問(wèn)題必須要同步訪問(wèn)外部session cache，比如redis。由于openssl目前提供的API是同步的，所以我們正在改進(jìn)openssl和nginx的異步實(shí)現(xiàn)。
配置相同的session ticket key，部署在多個(gè)服務(wù)器上，這樣多個(gè)不同的服務(wù)器也能產(chǎn)生相同的 session ticket。session ticket的缺點(diǎn)是支持率不廣，大概只有40%。而session id是client hello的標(biāo)準(zhǔn)內(nèi)容，從SSL2.0開(kāi)始就被全部客戶支持。
ssl_session_tickets    on; 
ssl_session_ticket_key ticket_keys; 
設(shè)置ocsp stapling file，這樣ocsp的請(qǐng)求就不會(huì)發(fā)往ca提供的ocsp站點(diǎn)，而是發(fā)往網(wǎng)站的webserver。ocsp的配置和生成命令如下：
ssl_stapling on; 
ssl_stapling_file domain.staple; 
上面是nginx配置，如下是ocsp_stapling_file的生成命令： 
openssl s_client -showcerts -connect yourdomain:443 < /dev/null | awk -v c=-1 '/-----BEGIN CERTIFICATE-----/{inc=1;c++} inc {print > ("level" c ".crt")} /---END CERTIFICATE-----/{inc=0}'  
for i in level?.crt;  
do  
openssl x509 -noout -serial -subject -issuer -in "$i";  
echo;  
done  
openssl ocsp -text -no_nonce -issuer level1.crt -CAfile CAbundle.crt -cert level0.crt -VAfile level1.crt -url $ocsp_url -respout domain.staple ,其中$ocsp_url等于ocsp站點(diǎn)的URL，可以通過(guò)如下命令求出：for i in level?.crt; do echo "$i:"; openssl x509 -noout -text -in "$i" | grep OCSP; done，如果是證書鏈，一般是最底層的值。 
優(yōu)先使用ecdhe密鑰交換算法，因?yàn)樗С諴FS(perfect forward secrecy)，能夠?qū)崿F(xiàn)false start。
設(shè)置tls record size，好是能動(dòng)態(tài)調(diào)整record size，即連接剛建立時(shí)record size設(shè)置成msg，連接穩(wěn)定之后可以將record size動(dòng)態(tài)增加。
如果有條件的話可以啟用tcp fast open。雖然現(xiàn)在沒(méi)有什么客戶端支持。
啟用SPDY。SPDY是強(qiáng)制使用HTTPS的，協(xié)議比較復(fù)雜，需要單獨(dú)的文章來(lái)分析。可以肯定的一點(diǎn)是使用SPDY的請(qǐng)求不僅明顯提升了HTTPS速度，甚至比HTTP還要快。在無(wú)線WIFI環(huán)境下，SPDY比HTTP要快50ms左右，3G環(huán)境下比HTTP要快250ms。
3.2 HTTPS 對(duì)性能的影響
HTTPS為什么會(huì)嚴(yán)重降低性能？主要是握手階段時(shí)的大數(shù)運(yùn)算。其中最消耗性能的又是密鑰交換時(shí)的私鑰解密階段（函數(shù)是rsa_private_decryption）。這個(gè)階段的性能消耗占整個(gè)SSL握手性能消耗的95%。
前面提及了openssl密鑰交換使用的算法只有四種：rsa, dhe, ecdhe，dh。dh由于安全問(wèn)題目前使用得非常少，所以這里可以比較下前面三種密鑰交換算法的性能，具體的數(shù)據(jù)如下：

上圖數(shù)據(jù)是指完成1000次握手需要的時(shí)間，顯然時(shí)間數(shù)值越大表示性能越低。
密鑰交換步驟是SSL完全握手過(guò)程中無(wú)法繞過(guò)的一個(gè)階段。我們只能采取如下措施：
通過(guò)session cache和session ticket提升session reuse率，減少完全握手(full handshake)次數(shù)，提升簡(jiǎn)化握手(abbreviated handshake)率。
出于前向加密和false start的考慮，我們優(yōu)先配置ecdhe用于密鑰交換，但是性能不足的情況下可以將rsa配置成密鑰交換算法，提升性能。
openssl 自帶的工具可以計(jì)算出對(duì)稱加密、數(shù)字簽名及HASH函數(shù)的各個(gè)性能，所以詳細(xì)數(shù)據(jù)我就不再列舉，讀者可以自行測(cè)試 。
結(jié)論就是對(duì)稱加密RC4的性能最快，但是RC4本身不安全，所以還是正常情況下還是采用AES。HASH函數(shù)MD5和SHA1差不多。數(shù)字簽名是ecdsa算法最快，但是支持率不高。
事實(shí)上由于密鑰交換在整個(gè)握手過(guò)程中消耗性能占了95%，而對(duì)稱加解密的性能消耗不到0.1%，所以server端對(duì)稱加密的優(yōu)化收益不大。相反，由于客戶端特別是移動(dòng)端的CPU計(jì)算能力本來(lái)就比較弱，所以對(duì)稱加密和數(shù)字簽名的優(yōu)化主要是針對(duì)移動(dòng)客戶端。
poly1350是google推出的號(hào)稱優(yōu)于aes-gcm的對(duì)稱加密算法，適用于移動(dòng)端，可以試用一下。
最后經(jīng)過(guò)測(cè)試，綜合安全和性能的最優(yōu)cipher suite配置是:  ECDHE-RSA-AES128-GCM-SHA256.
如果性能出現(xiàn)大幅度下降，可以修改配置，提升性能但是弱化了安全性，配置是：rc4-md5，根據(jù)openssl的規(guī)則，密鑰交換和數(shù)字簽名默認(rèn)都是使用rsa。

4，HTTPS的支持率分析
分析了百度服務(wù)器端一百萬(wàn)的無(wú)線訪問(wèn)日志（主要為手機(jī)和平板電腦的瀏覽器），得出協(xié)議和握手時(shí)間的關(guān)系如下：
tls協(xié)議版本客戶端使用率握手時(shí)間 ms
tls 1.224.8%299.496
tls 1.10.9%279.383
tls 1.074%307.077
ssl 3.00.3%484.564
從上表可以發(fā)現(xiàn)，ssl3.0速度最慢，不過(guò)支持率非常低。tls 1.0支持率最廣泛。
加密套件和握手時(shí)間的關(guān)系如下：
加密套件客戶端使用率握手時(shí)間
ECDHE-RSA-AES128-SHA58.5%294.36  
ECDHE-RSA-AES128-SHA25621.1%303.065
DHE-RSA-AES128-SHA16.7%351.063
ECDHE-RSA-AES128-GCM-SHA2563.7%274.83
顯然DHE對(duì)速度的影響比較大，ECDHE的性能確實(shí)要好出很多，而AES128-GCM對(duì)速度也有一點(diǎn)提升。
通過(guò)tcpdump分析client hello請(qǐng)求，發(fā)現(xiàn)有56.53%的請(qǐng)求發(fā)送了session id。也就意味著這些請(qǐng)求都能通過(guò)session cache得到復(fù)用。其他的一些擴(kuò)展屬性支持率如下：
tls擴(kuò)展名支持率
server_name76.99%
session_tickets38.6%
next_protocol_negotiation40.54%
elliptic_curves 90.6%
ec_point_formats90.6%
這幾個(gè)擴(kuò)展都非常有意義，解釋如下：
server_name,，即 sni （server name indicator)，有77%的請(qǐng)求會(huì)在client hello里面攜帶想要訪問(wèn)的域名，允許服務(wù)端使用一個(gè)IP支持多個(gè)域名。
next_protocol_negotiation，即NPN，意味著有40.54%的客戶端支持spdy.
session_tickets只有38.6%的支持率，比較低。這也是我們?yōu)槭裁磿?huì)修改nginx主干代碼實(shí)現(xiàn)session cache多機(jī)共享機(jī)制的原因。
elliptic_curves即是之前介紹的ECC（橢圓曲線系列算法），能夠使用更小KEY長(zhǎng)度實(shí)現(xiàn)DH同樣級(jí)別的安全，極大提升運(yùn)算性能。

5，結(jié)論
現(xiàn)在互聯(lián)網(wǎng)上HTTPS的中文資料相對(duì)較少，同時(shí)由于HTTPS涉及到大量協(xié)議、密碼學(xué)及PKI體系的知識(shí)，學(xué)習(xí)門檻相對(duì)較高。另外在具體的實(shí)踐過(guò)程中還有很多坑和待持續(xù)改進(jìn)的地方。希望本文對(duì)大家有一些幫助，同時(shí)由于我本人在很多地方掌握得也比較粗淺，一知半解，希望大家能多提意見(jiàn)，共同進(jìn)步。
最后，為了防止流量劫持，保護(hù)用戶隱私，大家都使用HTTPS吧，全網(wǎng)站支持。事實(shí)上，HTTPS并沒(méi)有那么難用和可怕，只是你沒(méi)有好好優(yōu)化。

上述內(nèi)容就是將全站進(jìn)行HTTPS化優(yōu)勢(shì)是什么，你們學(xué)到知識(shí)或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識(shí)儲(chǔ)備，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

網(wǎng)站題目：將全站進(jìn)行HTTPS化優(yōu)勢(shì)是什么-創(chuàng)新互聯(lián)
轉(zhuǎn)載源于：http://m.newbst.com/article0/dgihio.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站制作、企業(yè)網(wǎng)站制作、網(wǎng)站設(shè)計(jì)公司、做網(wǎng)站、面包屑導(dǎo)航、靜態(tài)網(wǎng)站

廣告

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