HTTP 的缺點(diǎn)

1. 通信使用明文（不加密），內(nèi)容可能會(huì)被竊聽(tīng)

通信的加密

一種方式是將通信加密。HTTP 協(xié)議中沒(méi)有加密機(jī)制，但可以通過(guò)和 SSL（Secure Socket Layer，安全套接層）或 TLS（Transport Layer Security，安全傳輸層協(xié)議）的組合使用，加密 HTTP 的通信內(nèi)容。

用 SSL 建立安全通信線路之后，就可以在這條線路上進(jìn)行 HTTP 通信了。與 SSL 組合使用的 HTTP 被稱為 HTTPS （HTTP Secure，超文本傳輸安全協(xié)議）或 HTTP over SSL。

內(nèi)容的加密

還有一種將參與通信的內(nèi)容本身加密的方式。由于 HTTP 協(xié)議中沒(méi)有加密機(jī)制，那么就對(duì) HTTP 協(xié)議傳輸?shù)膬?nèi)容本身加密。即把 HTTP 報(bào)文里所含的內(nèi)容進(jìn)行加密處理。

在這種情況下，客戶端需要對(duì) HTTP 報(bào)文進(jìn)行加密處理后再發(fā)送請(qǐng)求。

誠(chéng)然，為了做到有效的內(nèi)容加密，前提是要求客戶端和服務(wù)器同時(shí)具備加密和解密機(jī)制。主要應(yīng)用在 Web 服務(wù)中。有一點(diǎn)必須引起注意，由于該方式不同于 SSL 或 TLS 將整個(gè)通信線路加密處理，所以內(nèi)容仍有被篡改的風(fēng)險(xiǎn)。

2. 不驗(yàn)證通信方的身份，因此有可能遭遇偽裝

HTTP 協(xié)議中的請(qǐng)求和響應(yīng)不會(huì)對(duì)通信方進(jìn)行確認(rèn)。也就是說(shuō)存在“服務(wù)器是否就是發(fā)送請(qǐng)求中 URI 真正指定的主機(jī)，返回的響應(yīng)是否真的返回到實(shí)際提出請(qǐng)求的客戶端”等類似問(wèn)題。

任何人都可發(fā)起請(qǐng)求

在 HTTP 協(xié)議通信時(shí)，由于不存在確認(rèn)通信方的處理步驟，任何人都可以發(fā)起請(qǐng)求。另外，服務(wù)器只要接收到請(qǐng)求，不管對(duì)方是誰(shuí)都會(huì)返回一個(gè)響應(yīng)（但也僅限于發(fā)送端的 IP 地址和端口號(hào)沒(méi)有被 Web 服務(wù)器設(shè)定限制訪問(wèn)的前提下）。

HTTP 協(xié)議的實(shí)現(xiàn)本身非常簡(jiǎn)單，不論是誰(shuí)發(fā)送過(guò)來(lái)的請(qǐng)求都會(huì)返回響應(yīng)，因此不確認(rèn)通信方，會(huì)存在以下各種隱患：

1. 無(wú)法確定請(qǐng)求發(fā)送至目標(biāo)的 Web 服務(wù)器是否是按真實(shí)意圖返回響應(yīng)的那臺(tái)服務(wù)器。有可能是已偽裝的 Web 服務(wù)器。
2. 無(wú)法確定響應(yīng)返回到的客戶端是否是按真實(shí)意圖接收響應(yīng)的那個(gè)客戶端。有可能是已偽裝的客戶端。
3. 無(wú)法確定正在通信的對(duì)方是否具備訪問(wèn)權(quán)限。因?yàn)槟承?Web 服務(wù)器上保存著重要的信息，只想發(fā)給特定用戶通信的權(quán)限。
4. 無(wú)法判定請(qǐng)求是來(lái)自何方、出自誰(shuí)手。
5. 即使是無(wú)意義的請(qǐng)求也會(huì)照單全收。無(wú)法阻止海量請(qǐng)求下的 DoS 攻擊。

查明對(duì)手的證書(shū)

雖然使用 HTTP 協(xié)議無(wú)法確定通信方，但如果使用 SSL 則可以。SSL 不僅提供加密處理，而且還使用一種被稱為證書(shū)的手段，可用于確定方。

證書(shū)由值得信任的第三方機(jī)構(gòu)頒發(fā)，用以證明服務(wù)器和客戶端是實(shí)際存在的。另外，偽造證書(shū)從技術(shù)角度來(lái)說(shuō)是異常困難的一件事。所以只要能確認(rèn)通信方（服務(wù)端或客戶端）持有的證書(shū)，即可判斷通信方的真是意圖。

通過(guò)使用證書(shū)，以證明通信方就是意料中的服務(wù)器。這對(duì)使用者個(gè)人來(lái)講，也減少了個(gè)人信息泄露的危險(xiǎn)性。另外，客戶端持有證書(shū)即可完成個(gè)人身份的確認(rèn)，也可用于對(duì) Web 網(wǎng)站的認(rèn)證環(huán)節(jié)。

3. 無(wú)法證明報(bào)文的完整性，所以有可能已遭篡改

所謂完整性是指信息的準(zhǔn)確度。若無(wú)法證明其完整性，通常也就意味著無(wú)法判斷信息是否準(zhǔn)確。

接收到的內(nèi)容可能有誤

由于 HTTP 協(xié)議無(wú)法證明通信的報(bào)文的完整性，因此，沒(méi)有任何辦法確認(rèn)，發(fā)出的請(qǐng)求/響應(yīng)和接收到的請(qǐng)求/響應(yīng)是前后相同的。

如何防止篡改

雖然有使用 HTTP 協(xié)議確認(rèn)報(bào)文完整性的方法，但事實(shí)上并不便捷、可靠。其中常用的是 MD5 和 SHA-1 等散列值校驗(yàn)的方法，以及用來(lái)確認(rèn)文件的數(shù)字簽名方法。

提供文件下載服務(wù)的 Web 網(wǎng)站也會(huì)提供相應(yīng)的以 PGP（Pretty Good Privacy，完美隱私）創(chuàng)建的數(shù)字簽名及 MD5 算法生成的散列值。PGP 是用來(lái)證明創(chuàng)建文件的數(shù)字簽名，MD5 是由單向函數(shù)生成的散列值。不論使用哪一種方法，都需要操縱客戶端的用戶本人親自檢查驗(yàn)證下載的文件是否就是原來(lái)服務(wù)器上的文件。瀏覽器無(wú)法自動(dòng)幫用戶檢查。

可惜的是，這些辦法也依然無(wú)法百分之百保證確認(rèn)結(jié)果正確。因?yàn)?PGP 和 MD5 本身被改寫的話，用戶是沒(méi)有辦法意識(shí)到的。

為了有效防止這些弊端，有必要使用 HTTPS。SSL 提供認(rèn)證和加密處理及摘要功能。僅靠 HTTP 確保完整性是非常困難的，因此通過(guò)和其他協(xié)議組合使用來(lái)實(shí)現(xiàn)這個(gè)目標(biāo)。

HTTPS = HTTP + 加密 + 認(rèn)證 + 完整性保護(hù)

HTTP 加上加密處理和認(rèn)證及完整性保護(hù)后即是 HTTPS

如果在 HTTP 協(xié)議通信過(guò)程中使用未經(jīng)加密的明文，比如在 Web 頁(yè)面中輸入信用卡號(hào)，如果這條通信線路遭到竊聽(tīng)，那么信用卡號(hào)就暴露了。

另外，對(duì)于 HTTP 來(lái)說(shuō)，服務(wù)器也好，客戶端也好，都是沒(méi)有辦法確認(rèn)通信方的。因?yàn)楹苡锌赡懿⒉皇呛驮瓉?lái)預(yù)想的通信方在實(shí)際通信。并且還需要考慮到接收到的報(bào)文在通信途中已經(jīng)遭到篡改這一可能性。

為了統(tǒng)一解決上述這些問(wèn)題，需要在 HTTP 上再加入加密處理和認(rèn)證等機(jī)制。我們把添加了加密及認(rèn)證機(jī)制的 HTTP 稱為 HTTPS（HTTP Secure）。

HTTPS 是身披 SSL 外殼的 HTTP

HTTPS 并非是應(yīng)用層的一種新協(xié)議。只是 HTTP 通信接口部分用 SSL（Secure Socket Layer）和TLS（Transport Layer Security）協(xié)議代替而已。

通常，HTTP 直接和 TCP 通信。當(dāng)使用 SSL 時(shí)，則演變成先和 SSL 通信，再由 SSL 和 TCP 通信了。簡(jiǎn)言之，所謂 HTTPS，其實(shí)就是身披 SSL 外殼的 HTTP。

在采用 SSL 后，HTTP 就擁有了 HTTPS 的加密、證書(shū)和完整性保護(hù)這些功能。

SSL 是獨(dú)立于 HTTP 的協(xié)議，所以不光是 HTTP 協(xié)議，其他運(yùn)行在應(yīng)用層的 SMTP 和 Telnet 等協(xié)議均可配合 SSL 協(xié)議使用?？梢哉f(shuō) SSL 是當(dāng)今世界上應(yīng)用最為廣泛的網(wǎng)絡(luò)安全技術(shù)。

加密技術(shù)

相互共享密鑰的共享加密技術(shù)

SSL 采用一種叫做公開(kāi)密鑰加密的加密處理方式。

近代的加密方法中的加密算法是公開(kāi)的，而密鑰確實(shí)保密的。通過(guò)這種方式得以保持加密方法的安全性。

加密和解密都會(huì)用到密鑰。沒(méi)有密鑰就無(wú)法對(duì)密碼解密，反過(guò)來(lái)說(shuō)，任何人只要持有密鑰就能解密了。如果密鑰被攻擊者獲得，那加密也就失去了意義。

共享密鑰加密的困境
加密和解密同用一個(gè)密鑰的方式叫做共享密鑰加密，也被稱為對(duì)稱密鑰加密。

以共享密鑰方式加密時(shí)必須將密鑰也給對(duì)方?？删烤乖鯓硬拍馨踩霓D(zhuǎn)交？在互聯(lián)網(wǎng)上轉(zhuǎn)發(fā)密鑰時(shí)，如果通信被監(jiān)聽(tīng)那么密鑰就可會(huì)落入攻擊者之手，同時(shí)也就失去了加密的意義。另外還得設(shè)法安全地保管接收到的密鑰。

使用兩把密鑰的公開(kāi)密鑰加密

公開(kāi)密鑰加密方式很好地解決了共享密鑰加密的困難。

公開(kāi)密鑰加密使用一對(duì)非對(duì)稱的密鑰。一把叫做私有密鑰，另一把叫做公開(kāi)密鑰。私有密鑰不能讓其他任何人知道，而公有密鑰則可以隨意發(fā)布，任何人都可以獲得。

使用公開(kāi)密鑰加密方式，發(fā)送密文的一方使用對(duì)方的公開(kāi)密鑰進(jìn)行加密處理，對(duì)方收到被加密的信息后，再使用自己的私有密鑰進(jìn)行解密。利用這種方式，不需要發(fā)送用來(lái)解密的私有密鑰，也不必?fù)?dān)心密鑰被攻擊者竊聽(tīng)而盜走。

另外，要想根據(jù)密文和公開(kāi)密鑰，恢復(fù)到信息原文是異常困難的，因?yàn)榻饷苓^(guò)程就是在對(duì)離散對(duì)數(shù)進(jìn)行求值，這并非輕而易舉就能辦到。

HTTPS 采用混合加密機(jī)制

HTTPS 采用共享密鑰加密和公開(kāi)密鑰加密兩者并用的混合加密機(jī)制。若密鑰能夠?qū)崿F(xiàn)安全交換，那么有可能會(huì)考慮僅使用公開(kāi)密鑰加密來(lái)通信。但是公開(kāi)密鑰加密和共享密鑰加密相比，其處理速度要慢。

所以應(yīng)充分利用兩者各自的優(yōu)勢(shì)，將多種方法組合起來(lái)用于通信。在交換密鑰環(huán)節(jié)使用公開(kāi)密鑰加密方式，之后的建立通信交換報(bào)文階段則使用共享密鑰加密方式。

數(shù)字證書(shū)

在公開(kāi)密鑰加密方式中也存在一些問(wèn)題，那就是無(wú)法證明公開(kāi)密鑰本身就是貨真價(jià)實(shí)的公開(kāi)密鑰。比如，正準(zhǔn)備和某臺(tái)服務(wù)器建立公開(kāi)密鑰加密方式下的通信時(shí)，如何證明收到的公開(kāi)密鑰就是原本預(yù)想的那臺(tái)服務(wù)器發(fā)行的公開(kāi)密鑰?；蛟S在公開(kāi)密鑰傳輸途中，真正的公開(kāi)密鑰已經(jīng)被攻擊者替換了。

為了解決上述問(wèn)題，可以使用由數(shù)字證書(shū)認(rèn)證機(jī)構(gòu)（CA，Certificate Authority）和其他相關(guān)頒發(fā)的公開(kāi)密鑰證書(shū)。

數(shù)字證書(shū)認(rèn)證機(jī)構(gòu)處于客戶端和服務(wù)器雙方都可信賴的第三方機(jī)構(gòu)的立場(chǎng)上。數(shù)字證書(shū)認(rèn)證機(jī)構(gòu)的流程是：

1. 服務(wù)器的運(yùn)營(yíng)人員向數(shù)字證書(shū)認(rèn)證機(jī)構(gòu)提供公開(kāi)密鑰的申請(qǐng)。
2. 數(shù)字證書(shū)認(rèn)證機(jī)構(gòu)在判明提出申請(qǐng)者的身份之后，會(huì)對(duì)已申請(qǐng)的公開(kāi)密鑰做數(shù)字簽名，然后分配這個(gè)已簽名的公開(kāi)密鑰，并將該公開(kāi)密鑰放入公鑰證書(shū)后綁定在一起。
3. 服務(wù)器會(huì)將這份由數(shù)字證書(shū)認(rèn)證機(jī)構(gòu)頒發(fā)的公鑰證書(shū)發(fā)送給客戶端，以進(jìn)行公開(kāi)密鑰加密方式通信。公鑰證書(shū)也可叫做數(shù)字證書(shū)或直接稱為證書(shū)。
4. 接到證書(shū)的客戶端可使用數(shù)字證書(shū)認(rèn)證機(jī)構(gòu)的公開(kāi)密鑰，對(duì)那張證書(shū)上的數(shù)字簽名進(jìn)行驗(yàn)證，一旦驗(yàn)證通過(guò)，客戶端便可明確兩件事：一，認(rèn)證服務(wù)器的公開(kāi)密鑰的是真實(shí)有效的數(shù)字證書(shū)認(rèn)證機(jī)構(gòu)。二，服務(wù)器的公開(kāi)密鑰是值得信賴的。

此處認(rèn)證機(jī)關(guān)的公開(kāi)密鑰必須安全地轉(zhuǎn)交給客戶端。使用通信方式時(shí)，如何安全轉(zhuǎn)交是一件很困難的事。因此，多數(shù)瀏覽器開(kāi)發(fā)商發(fā)布版本時(shí)，會(huì)事先在內(nèi)部植入常用認(rèn)證機(jī)關(guān)的公開(kāi)密鑰。

HTTPS 存在的問(wèn)題

HTTPS 也存在一些問(wèn)題，那就是當(dāng)使用 SSL 時(shí)，它的處理速度會(huì)變慢。

SSL 的慢是分兩種。一種是指通信慢。另一種是指由于大量消耗 CPU 及內(nèi)存等資源，導(dǎo)致處理速度變慢。
和使用 HTTP 相比，網(wǎng)絡(luò)負(fù)載可能會(huì)變慢 2 到 100 倍。除去和 TCP 連接、發(fā)送 HTTP 請(qǐng)求/響應(yīng)外，還必須進(jìn)行 SSL 通信，因此整體上處理通信量不可避免會(huì)增加。

另一點(diǎn)是 SSL 必須進(jìn)行加密處理。在服務(wù)器和客戶端都需要進(jìn)行加密和解密的運(yùn)算處理。因此從結(jié)果上講，比起 HTTP 會(huì)更多地消耗服務(wù)器和客戶端的硬件資源，導(dǎo)致負(fù)載增強(qiáng)。

針對(duì)速度變慢這一問(wèn)題，并沒(méi)有根本性的解決方案，我們會(huì)使用 SSL 加速器這種（專用服務(wù)器）硬件來(lái)改善該問(wèn)題。該硬件為 SSL 通信專用硬件，相對(duì)軟件來(lái)講，能夠提高數(shù)倍 SSL 的計(jì)算速度。僅在 SSL 處理時(shí)發(fā)揮 SSL 加速器的功效，以分擔(dān)負(fù)載。