近日，百度宣布全站開啟HTTPS加密搜索。據(jù)官方表示，為解決“中間者”對用戶隱私的嗅探和劫持等問題，百度將對傳統(tǒng)HTTP通道添加SSL安全套接層，將所有百度搜索請求全部變成加密狀態(tài)。
•百度已啟用全站HTTPS加密搜索
•如何看待百度全站搜索進入HTTPS時代？
實際上，一些國際網(wǎng)站，比如維基百科，在啟用HTTPS前先會考慮自己計算能力是否可以承載HTTPS。那么問題來了，HTTPS要比HTTP多用多少服務器資源？
以下為知乎網(wǎng)友牟旭東的觀點：
HTTPS其實就是建構在SSL/TLS之上的 HTTP協(xié)議，所以要比較HTTPS比HTTP多用多少服務器資源，主要看SSL/TLS本身消耗多少服務器資源。
HTTP使用TCP 三次握手建立連接，客戶端和服務器需要交換3個包，HTTPS除了 TCP 的三個包，還要加上 ssl握手需要的9個包，所以一共是12個包。HTTP 建立連接，按照下面鏈接中針對Computer Science House的測試，是114毫秒；HTTPS建立連接，耗費436毫秒。ssl 部分花費322毫秒，包括網(wǎng)絡延時和ssl 本身加解密的開銷（服務器根據(jù)客戶端的信息確定是否需要生成新的主密鑰；服務器回復該主密鑰，并返回給客戶端一個用主密鑰認證的信息；服務器向客戶端請求數(shù)字簽名和公開密鑰）。
SSL handshake latency and HTTPS optimizations. :: semicomplete.com
當SSL 連接建立后，之后的加密方式就變成了3DES等對于 CPU 負荷較輕的對稱加密方式。相對前面 SSL 建立連接時的非對稱加密方式，對稱加密方式對 CPU 的負荷基本可以忽略不記，所以問題就來了，如果頻繁的重建 ssl 的session，對于服務器性能的影響將會是致命的，盡管打開HTTPS �；羁梢跃徑鈫蝹�連接的性能問題，但是對于并發(fā)訪問用戶數(shù)極多的大型網(wǎng)站，基于負荷分擔的獨立的SSL termination proxy就顯得必不可少了，Web 服務放在SSL termination proxy之后。SSL termination proxy既可以是基于硬件的，譬如F5；也可以是基于軟件的，譬如維基百科用到的就是 Nginx。
那采用 HTTPS 后，到底會多用多少服務器資源，2010年1月 Gmail切換到完全使用 HTTPS， 前端處理 SSL 機器的CPU 負荷增加不超過1%，每個連接的內存消耗少于20KB，網(wǎng)絡流量增加少于2%。由于 Gmail 應該是使用N臺服務器分布式處理，所以CPU 負荷的數(shù)據(jù)并不具有太多的參考意義，每個連接內存消耗和網(wǎng)絡流量數(shù)據(jù)有參考意義。這篇文章中還列出了單核每秒大概處理1500次握手（針對1024-bit 的 RSA），這個數(shù)據(jù)很有參考意義，具體信息來源的英文網(wǎng)址：ImperialViolet。
Heartbleed這個被稱作史上最大的網(wǎng)絡安全漏洞，想必很多人都有所耳聞，Heartbleed之所以能夠出現(xiàn)，其實和我們這個問題關系還不小，前面我們談到了頻繁重建 SSL/TLS的session對于服務器影響是致命的，所以聰明的RFC 在2012年提出了 RFC6520 TLS 的心跳擴展。這個協(xié)議本身是簡單和完美的，通過在客戶端和服務器之間來回發(fā)送心跳的請求和應答，�；� TLS session，減少重建 TLS的session的性能開銷。令人遺憾的是，openssl 在實現(xiàn)這個心跳擴展時，犯了一個低級的錯誤，沒有對收到的心跳請求進行長度檢查，直接根據(jù)心跳請求長度拷貝數(shù)據(jù)區(qū)，導致簡單的心跳應答中可能包含了服務器端的核心數(shù)據(jù)區(qū)內容，用戶名，密碼，信用卡信息，甚至服務器的私有密鑰都有可能泄露。心因為心跳�；畹倪@個 BUG 在滴血，這個名字起的極度形象。
下面開始講一個無聊的故事，和問題關系不大，時間緊張的看官可以到此為止了。
從前山上有座廟，廟里有個和尚......，別胡鬧了，老和尚來了。
小和尚問老和尚：ssl為什么會讓HTTP安全？
老和尚答道：譬如你我都有一個同樣的密碼，我發(fā)信給你時用這個密碼加密，你收到我發(fā)的信，用這個密碼解密，就能知道我信的內容，其他的閑雜人等，就算偷偷拿到了信，由于不知道這個密碼，也只能望信興嘆，這個密碼就叫做對稱密碼。ssl使用對稱密碼對HTTP內容進行加解密，所以讓HTTP安全了，常用的加解密算法主要有3DES和AES等。
小和尚摸摸腦袋問老和尚：師傅，如果我們兩人選擇“和尚”作為密碼，再創(chuàng)造一個和尚算法，我們倆之間的通信不就高枕無憂了？
老和尚當頭給了小和尚一戒尺：那我要給山下的小花寫情書，還得用“和尚”這個密碼不成？想了想又給了小和尚一戒尺：雖然我們是和尚，不是碼農，也不能自己造輪子，當初一堆牛人碼農造出了Wifi的安全算法WEP，后來發(fā)現(xiàn)是一繡花枕頭，在安全界傳為笑談；況且小花只知道3DES和AES，哪知道和尚算法？
小和尚問到：那師傅何解？
老和尚：我和小花只要知道每封信的密碼，就可以讀到對方加密的信件，關鍵是我們互相之間怎么知道這個對稱密碼。你說，我要是將密碼寫封信給她，信被別人偷了，那大家不都知道我們的密碼了，也就能夠讀懂我們情書了。不過還是有解的，這里我用到了江湖中秘傳的非對稱密碼。我現(xiàn)在手頭有兩個密碼，一個叫“公鑰”，一個叫“私鑰”，公鑰發(fā)布到了江湖上，好多人都知道，私鑰嘛，江湖上只有我一個人知道；這兩個密鑰有數(shù)學相關性，就是說用公鑰加密的信件，可以用私鑰解開，但是用公鑰卻解不開。公鑰小花是知道的，她每次給我寫信，都要我的公鑰加密她的對稱密碼，單獨寫一張密碼紙，然后用她的對稱密碼加密她的信件，這樣我用我的私鑰可以解出這個對稱密碼，再用這個對稱密碼來解密她的信件。
老和尚頓了頓：可惜她用的對稱密碼老是“和尚為什么寫情書”這一類，所以我每次解開密碼紙時總是悵然若失，其實我鐘意的對稱密碼是諸如“風花”“雪月”什么的，最頭痛的是，我還不得不用“和尚為什么寫情書”這個密碼來加密我給小花回的情書，人世間最痛苦的事莫過于如此�？晌夷睦镏溃鋵嵱腥吮任腋纯�。山下的張屠夫，暗戀小花很多年，看著我們鴻雁傳書，心中很不是滋味，主動毛遂自薦代替香客給我們送信。在他第一次給小花送信時，就給了小花他自己的公鑰，謊稱是我公鑰剛剛更新了，小花信以為真，之后的信件對稱密碼都用張屠夫的這個公鑰加密了，張屠夫拿到回信后，用他自己的私鑰解開了小花的對稱密碼，然后用這個對稱密碼，不僅能夠看到了小花信件的所有內容，還能使用這個密碼偽造小花給我寫信，同時還能用他的私鑰加密給小花的信件。漸漸我發(fā)現(xiàn)信件變味了，盡管心生疑惑，但是沒有確切的證據(jù)，一次我寫信問小花第一次使用的對稱密碼，回信中“和尚為什么寫情書”赫然在列，于是我的疑惑稍稍減輕。直到有一次去拜會嵩山少林寺老方丈才頓悟，原來由于我的公鑰沒有火印，任何人都可以偽造一份公鑰宣稱是我的，這樣這個人即能讀到別人寫給我的信，也能偽造別人給我寫信，同樣也能讀到我的回信，也能偽造我給別人的回信，這種邪門武功江湖上稱之“Man-in-the-middle attack”。唯一的破解就是使用嵩山少林寺的火印，這個火印可有講究了，需要將我的公鑰及個人在江湖地位提交給18羅漢委員會，他們會根據(jù)我的這些信息使用委員會私鑰進行數(shù)字簽名，簽名的信息凸現(xiàn)在火印上，有火印的公鑰真實性在江湖上無人質疑，要知道18羅漢可是無人敢得罪的。
小和尚問：那然后呢？
老和尚：從嵩山少林寺回山上寺廟時，我將有火印的公鑰親自給小花送去，可是之后再也沒有收到小花的來信。過了一年才知道，其實小花還是給我寫過信的，當時信確實是用有火印的公鑰加密，張屠夫拿到信后，由于不知道我的私鑰，解不開小花的密碼信，所以一怒之下將信件全部燒毀了。也由于張屠夫無法知道小花的對稱密碼而無法回信，小花發(fā)出幾封信后石沉大海，也心生疑惑，到處打聽我的近況。這下張屠夫急了，他使用我發(fā)布的公鑰，仿照小花的語氣，給我發(fā)來一封信。拿到信時我就覺得奇怪，信紙上怎么有一股豬油的味道，結尾竟然還關切的詢問我的私鑰。情知有詐，我思量無論如何要找到辦法讓我知道來的信是否真是小花所寫。后來竟然讓我想到了辦法....
老和尚摸著光頭說：這頭發(fā)可不是白掉的，我托香客給小花帶話，我一切安好，希望她也擁有屬于自己的一段幸福，不對，是一對非對稱密鑰。小花委托小鎮(zhèn)美女協(xié)會給小花公鑰打上火印后，托香客給我送來，這樣小花在每次給我寫信時，都會在密碼紙上貼上一朵小牡丹，牡丹上寫上用她自己的私鑰加密過的給我的留言，這樣我收到自稱是小花的信后，我會先抽出密碼紙，取下小牡丹，使用小花的公鑰解密這段留言，如果解不出來，我會直接將整封信連同密碼紙一起扔掉，因為這封信一定不是小花寫的，如果能夠解出來，這封信才能確信來之于小花，我才仔細的解碼閱讀。
小和尚：難怪聽說張屠夫是被活活氣死的。您這情書整的，我頭都大了，我長大后，有想法直接扯著嗓子對山下喊，也省的這么些麻煩。不過我倒是明白了樓上的話，ssl 握手階段，就是要解決什么看火印，讀牡丹，解密碼紙，確實夠麻煩的，所以性能瓶頸在這里，一旦雙方都知道了對稱密碼，之后就是行云流水的解碼讀信階段了，相對輕松很多。
轉載請保留原文地址: http://m.pufcvep.cn/show-398.html