在HTTPS項目的開展過程中明顯感覺到目前國內互聯(lián)網對HTTPS并不是很重視，其實也就是對用戶隱私和網絡安全不重視。本文從保護用戶隱私的角度出發(fā)，簡單描述現(xiàn)在存在的用戶隱私泄露和流量劫持現(xiàn)象，然后進一步說明為什么HTTPS能夠保護用戶安全以及HTTPS使用過程中需要注意的地方。
國外很多網站包括google,facebook,twitter都支持了全站HTTPS，而國內目前還沒有一家大型網站全站支持HTTPS（PC端的微信全部使用了HTTPS，但是PC端用戶應該不多）。甚至一些大型網站明顯存在很多HTTPS使用不規(guī)范或者過時的地方。比如支付寶使用的是tls1.0和RC4,而京東(quickpay.jd.com)竟然還使用著SSL3.0這個早就不安全并且性能低下的協(xié)議，其他很多網站的HTTPS登陸頁面也存在著不安全的HTTP鏈接，這個也為黑客提供了可乘之機。
由于篇幅關系，文中幾乎沒有詳細描述任何細節(jié)，后面有時間我再一一整理成博客發(fā)表出來。同時由于水平有限，本文肯定存在很多錯誤，希望大家不吝賜教。本文的大部分內容都能從互聯(lián)網上搜索到，有些地方我也標明了引用，可以直接跳轉過去。但是全文都是在我自己理解的基礎上結合開發(fā)部署過程中的一些經驗和測試數(shù)據一個字一個字敲出來的，最后決定將它們分享出來的原因是希望能和大家多多交流，拋磚引玉，共同推進中國互聯(lián)網的HTTPS發(fā)展。
本文不會科普介紹HTTPS、TLS及PKI，如果遇到一些基本概念文中只是提及而沒有描述，請大家自行百度和google。本文重點是想告訴大家HTTPS沒有想像中難用可怕，只是沒有經過優(yōu)化。
中國互聯(lián)網全站使用HTTPS的時代已經到來。

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

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

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

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

采用非對稱密碼算法的密鑰協(xié)商過程結束之后就已經得出了本次會話需要使用的對稱密鑰。對稱加密又分為兩種模式：流式加密和分組加密。流式加密現(xiàn)在常用的就是RC4，不過RC4已經不再安全，微軟也建議網站盡量不要使用RC4流式加密。支付寶可能沒有意識到這一點，也可能是由于其他原因，他們仍然在使用RC4算法和TLS1.0協(xié)議。

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

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

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

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

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

4，HTTPS的支持率分析
分析了百度服務器端一百萬的無線訪問日志（主要為手機和平板電腦的瀏覽器），得出協(xié)議和握手時間的關系如下：
tls協(xié)議版本客戶端使用率握手時間 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速度最慢，不過支持率非常低。tls 1.0支持率最廣泛。
加密套件和握手時間的關系如下：
加密套件客戶端使用率握手時間
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對速度的影響比較大，ECDHE的性能確實要好出很多，而AES128-GCM對速度也有一點提升。
通過tcpdump分析client hello請求，發(fā)現(xiàn)有56.53%的請求發(fā)送了session id。也就意味著這些請求都能通過session cache得到復用。其他的一些擴展屬性支持率如下：
tls擴展名支持率
server_name76.99%
session_tickets38.6%
next_protocol_negotiation40.54%
elliptic_curves 90.6%
ec_point_formats90.6%
這幾個擴展都非常有意義，解釋如下：
server_name,，即 sni （server name indicator)，有77%的請求會在client hello里面攜帶想要訪問的域名，允許服務端使用一個IP支持多個域名。
next_protocol_negotiation，即NPN，意味著有40.54%的客戶端支持spdy.
session_tickets只有38.6%的支持率，比較低。這也是我們?yōu)槭裁磿薷膎ginx主干代碼實現(xiàn)session cache多機共享機制的原因。
elliptic_curves即是之前介紹的ECC（橢圓曲線系列算法），能夠使用更小KEY長度實現(xiàn)DH同樣級別的安全，極大提升運算性能。

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