HTTP知識(shí)整合

HTTP——一、了解Web及網(wǎng)絡(luò)基礎(chǔ)
HTTP——二、簡(jiǎn)單的HTTP協(xié)議
HTTP——三、HTTP報(bào)文內(nèi)的HTTP信息
HTTP——四、返回結(jié)果的HTTP狀態(tài)碼
HTTP——五、與HTTP協(xié)作的Web服務(wù)器
HTTP——六、HTTP首部
HTTP——七、確保Web安全的HTTPS
HTTP——八、確認(rèn)訪問(wèn)用戶(hù)身份的認(rèn)證
HTTP——九、基于HTTP的功能追加協(xié)議
HTTP——十、構(gòu)建Web內(nèi)容的技術(shù)
HTTP——十一、Web的攻擊技術(shù)
在 HTTP 協(xié)議中有可能存在信息竊聽(tīng)或身份偽裝等安全問(wèn)題。使用HTTPS 通信機(jī)制可以有效地防止這些問(wèn)題。本章我們就了解一下HTTPS。

一、HTTP的缺點(diǎn)

到現(xiàn)在為止，我們已了解到 HTTP 具有相當(dāng)優(yōu)秀和方便的一面，然而HTTP 并非只有好的一面，事物皆具兩面性，它也是有不足之處的。HTTP 主要有這些不足，例舉如下。

• 通信使用明文（不加密），內(nèi)容可能會(huì)被竊聽(tīng)
• 不驗(yàn)證通信方的身份，因此有可能遭遇偽裝
• 無(wú)法證明報(bào)文的完整性，所以有可能已遭篡改

這些問(wèn)題不僅在 HTTP 上出現(xiàn)，其他未加密的協(xié)議中也會(huì)存在這類(lèi)問(wèn)題。
除此之外，HTTP 本身還有很多缺點(diǎn)。而且，還有像某些特定的 Web服務(wù)器和特定的 Web 瀏覽器在實(shí)際應(yīng)用中存在的不足（也可以說(shuō)成是脆弱性或安全漏洞），另外，用 Java 和 PHP 等編程語(yǔ)言開(kāi)發(fā)的Web 應(yīng)用也可能存在安全漏洞。

1、通信使用明文可能會(huì)被竊聽(tīng)

由于 HTTP 本身不具備加密的功能，所以也無(wú)法做到對(duì)通信整體（使用 HTTP 協(xié)議通信的請(qǐng)求和響應(yīng)的內(nèi)容）進(jìn)行加密。即，HTTP 報(bào)文使用明文（指未經(jīng)過(guò)加密的報(bào)文）方式發(fā)送。

• TCP/IP 是可能被竊聽(tīng)的網(wǎng)絡(luò)
  如果要問(wèn)為什么通信時(shí)不加密是一個(gè)缺點(diǎn)，這是因?yàn)?，按TCP/IP 協(xié)議族的工作機(jī)制，通信內(nèi)容在所有的通信線路上都有可能遭到窺視。
  所謂互聯(lián)網(wǎng)，是由能連通到全世界的網(wǎng)絡(luò)組成的。無(wú)論世界哪個(gè)角落的服務(wù)器在和客戶(hù)端通信時(shí)，在此通信線路上的某些網(wǎng)絡(luò)設(shè)備、光纜、計(jì)算機(jī)等都不可能是個(gè)人的私有物，所以不排除某個(gè)環(huán)節(jié)中會(huì)遭到惡意窺視行為。
  即使已經(jīng)過(guò)加密處理的通信，也會(huì)被窺視到通信內(nèi)容，這點(diǎn)和未加密的通信是相同的。只是說(shuō)如果通信經(jīng)過(guò)加密，就有可能讓人無(wú)法破解報(bào)文信息的含義，但加密處理后的報(bào)文信息本身還是會(huì)被看到的。

圖：互聯(lián)網(wǎng)上的任何角落都存在通信內(nèi)容被竊聽(tīng)的風(fēng)險(xiǎn)
竊聽(tīng)相同段上的通信并非難事。只需要收集在互聯(lián)網(wǎng)上流動(dòng)的數(shù)據(jù)包（幀）就行了。對(duì)于收集來(lái)的數(shù)據(jù)包的解析工作，可交給那些抓包（Packet Capture）或嗅探器（Sniffer）工具。
下面的圖片示例就是被廣泛使用的抓包工具 Wireshark。它可以獲取 HTTP 協(xié)議的請(qǐng)求和響應(yīng)的內(nèi)容，并對(duì)其進(jìn)行解析。像使用 GET 方法發(fā)送請(qǐng)求、響應(yīng)返回了 200 OK，查看 HTTP 響應(yīng)報(bào)文的全部?jī)?nèi)容等一系列的事情都可以做到。

• 加密處理防止被竊聽(tīng)
  在目前大家正在研究的如何防止竊聽(tīng)保護(hù)信息的幾種對(duì)策中，最為普及的就是加密技術(shù)。加密的對(duì)象可以有這么幾個(gè)。
  通信的加密
  一種方式就是將通信加密。HTTP 協(xié)議中沒(méi)有加密機(jī)制，但可以通過(guò)和 SSL（Secure Socket Layer，安全套接層）或TLS（Transport Layer Security，安全層傳輸協(xié)議）的組合使用，
  加密 HTTP 的通信內(nèi)容。
  用 SSL建立安全通信線路之后，就可以在這條線路上進(jìn)行 HTTP通信了。與 SSL組合使用的 HTTP 被稱(chēng)為 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)行加密處理。
  在這種情況下，客戶(hù)端需要對(duì) HTTP 報(bào)文進(jìn)行加密處理后再發(fā)送請(qǐng)求。
  
  誠(chéng)然，為了做到有效的內(nèi)容加密，前提是要求客戶(hù)端和服務(wù)器同時(shí)具備加密和解密機(jī)制。主要應(yīng)用在 Web 服務(wù)中。有一點(diǎn)必須引起注意，由于該方式不同于 SSL或 TLS 將整個(gè)通信線路加密處理，所以?xún)?nèi)容仍有被篡改的風(fēng)險(xiǎn)。稍后我們會(huì)加以說(shuō)明。

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)求的客戶(hù)端”等類(lèi)似問(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ì)存在以下各種隱患。
• • 無(wú)法確定請(qǐng)求發(fā)送至目標(biāo)的 Web 服務(wù)器是否是按真實(shí)意圖返回響應(yīng)的那臺(tái)服務(wù)器。有可能是已偽裝的 Web 服務(wù)器。
• • 無(wú)法確定響應(yīng)返回到的客戶(hù)端是否是按真實(shí)意圖接收響應(yīng)的那個(gè)客戶(hù)端。有可能是已偽裝的客戶(hù)端。
• • 無(wú)法確定正在通信的對(duì)方是否具備訪問(wèn)權(quán)限。因?yàn)槟承￤eb 服務(wù)器上保存著重要的信息，只想發(fā)給特定用戶(hù)通信的權(quán)限。
• • 無(wú)法判定請(qǐng)求是來(lái)自何方、出自誰(shuí)手。
• • 即使是無(wú)意義的請(qǐng)求也會(huì)照單全收。無(wú)法阻止海量請(qǐng)求下的 DoS 攻擊（Denial of Service，拒絕服務(wù)攻擊）。
• 查明對(duì)手的證書(shū)
  雖然使用 HTTP 協(xié)議無(wú)法確定通信方，但如果使用 SSL則可以。SSL不僅提供加密處理，而且還使用了一種被稱(chēng)為證書(shū)的手段，可用于確定方。
  證書(shū)由值得信任的第三方機(jī)構(gòu)頒發(fā)，用以證明服務(wù)器和客戶(hù)端是實(shí)際存在的。另外，偽造證書(shū)從技術(shù)角度來(lái)說(shuō)是異常困難的一件事。所以只要能夠確認(rèn)通信方（服務(wù)器或客戶(hù)端）持有的證書(shū)，即可判斷通信方的真實(shí)意圖。
  
  通過(guò)使用證書(shū)，以證明通信方就是意料中的服務(wù)器。這對(duì)使用者個(gè)人來(lái)講，也減少了個(gè)人信息泄露的危險(xiǎn)性。
  另外，客戶(hù)端持有證書(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)文完整性，因此，在請(qǐng)求或響應(yīng)送出之后直到對(duì)方接收之前的這段時(shí)間內(nèi)，即使請(qǐng)求或響應(yīng)的內(nèi)容遭到篡改，也沒(méi)有辦法獲悉。
  換句話說(shuō)，沒(méi)有任何辦法確認(rèn)，發(fā)出的請(qǐng)求 / 響應(yīng)和接收到的請(qǐng)求 / 響應(yīng)是前后相同的。
  
  比如，從某個(gè) Web 網(wǎng)站上下載內(nèi)容，是無(wú)法確定客戶(hù)端下載的文件和服務(wù)器上存放的文件是否前后一致的。文件內(nèi)容在傳輸途中可能已經(jīng)被篡改為其他的內(nèi)容。即使內(nèi)容真的已改變，作為接收方的客戶(hù)端也是覺(jué)察不到的。
  像這樣，請(qǐng)求或響應(yīng)在傳輸途中，遭攻擊者攔截并篡改內(nèi)容的攻擊稱(chēng)為中間人攻擊（Man-in-the-Middle attack，MITM）。
  
• 如何防止篡改
  雖然有使用 HTTP 協(xié)議確定報(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ù)生成的散列值。不論使用哪一種方法，都需要操縱客戶(hù)端的用戶(hù)本人親自檢查驗(yàn)證下載的文件是否就是原來(lái)服務(wù)器上的文件。瀏覽器無(wú)法自動(dòng)幫用戶(hù)檢查。
  可惜的是，用這些方法也依然無(wú)法百分百保證確認(rèn)結(jié)果正確。因?yàn)?PGP 和 MD5 本身被改寫(xiě)的話，用戶(hù)是沒(méi)有辦法意識(shí)到的。
  為了有效防止這些弊端，有必要使用 HTTPS。SSL提供認(rèn)證和加密處理及摘要功能。僅靠 HTTP 確保完整性是非常困難的，因此通過(guò)和其他協(xié)議組合使用來(lái)實(shí)現(xiàn)這個(gè)目標(biāo)。下節(jié)我們介紹HTTPS 的相關(guān)內(nèi)容。

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

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

如果在 HTTP 協(xié)議通信過(guò)程中使用未經(jīng)加密的明文，比如在 Web 頁(yè)面中輸入信用卡號(hào)，如果這條通信線路遭到竊聽(tīng)，那么信用卡號(hào)就暴露了。
另外，對(duì)于 HTTP 來(lái)說(shuō)，服務(wù)器也好，客戶(hù)端也好，都是沒(méi)有辦法確認(rèn)通信方的。因?yàn)楹苡锌赡懿⒉皇呛驮绢A(yù)想的通信方在實(shí)際通信。并且還需要考慮到接收到的報(bào)文在通信途中已經(jīng)遭到篡改這一可能性。
為了統(tǒng)一解決上述這些問(wèn)題，需要在 HTTP 上再加入加密處理和認(rèn)證等機(jī)制。我們把添加了加密及認(rèn)證機(jī)制的 HTTP 稱(chēng)為 HTTPS（HTTP Secure）。

經(jīng)常會(huì)在 Web 的登錄頁(yè)面和購(gòu)物結(jié)算界面等使用 HTTPS 通信。使用HTTPS 通信時(shí)，不再用 http://，而是改用 https://。另外，當(dāng)瀏覽器訪問(wèn) HTTPS 通信有效的 Web 網(wǎng)站時(shí)，瀏覽器的地址欄內(nèi)會(huì)出現(xiàn)一個(gè)帶鎖的標(biāo)記。對(duì) HTTPS 的顯示方式會(huì)因?yàn)g覽器的不同而有所改變。

2、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協(xié)議這層外殼的 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ù)。

3、相互交換密鑰的公開(kāi)密鑰加密技術(shù)

在對(duì) SSL進(jìn)行講解之前，我們先來(lái)了解一下加密方法。SSL采用一種叫做公開(kāi)密鑰加密（Public-key cryptography）的加密處理方式。
近代的加密方法中加密算法是公開(kāi)的，而密鑰卻是保密的。通過(guò)這種方式得以保持加密方法的安全性。
加密和解密都會(huì)用到密鑰。沒(méi)有密鑰就無(wú)法對(duì)密碼解密，反過(guò)來(lái)說(shuō)，任何人只要持有密鑰就能解密了。如果密鑰被攻擊者獲得，那加密也就失去了意義。

• 共享密鑰加密的困境
  加密和解密同用一個(gè)密鑰的方式稱(chēng)為共享密鑰加密（Common key crypto system），也被叫做對(duì)稱(chēng)密鑰加密。
  
  以共享密鑰方式加密時(shí)必須將密鑰也發(fā)給對(duì)方?？删烤乖鯓硬拍馨踩剞D(zhuǎn)交？在互聯(lián)網(wǎng)上轉(zhuǎn)發(fā)密鑰時(shí)，如果通信被監(jiān)聽(tīng)那么密鑰就可會(huì)落入攻擊者之手，同時(shí)也就失去了加密的意義。另外還得設(shè)法安全地保管接收到的密鑰。
  
  圖：密鑰發(fā)送問(wèn)題
• 使用兩把密鑰的公開(kāi)密鑰加密
  公開(kāi)密鑰加密方式很好地解決了共享密鑰加密的困難。
  公開(kāi)密鑰加密使用一對(duì)非對(duì)稱(chēng)的密鑰。一把叫做私有密鑰（private key），另一把叫做公開(kāi)密鑰（public key）。顧名思義，私有密鑰不能讓其他任何人知道，而公開(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)行求值，這并非輕而易舉就能辦到。退一步講，如果能對(duì)一個(gè)非常大的整數(shù)做到快速地因式分解，那么密碼破解還是存在希望的。但就目前的技術(shù)來(lái)看是不太現(xiàn)實(shí)的。
  
• 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)文階段則使用共享密鑰加密方式。
  

4、證明公開(kāi)密鑰正確性的證書(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)機(jī)關(guān)頒發(fā)的公開(kāi)密鑰證書(shū)。
數(shù)字證書(shū)認(rèn)證機(jī)構(gòu)處于客戶(hù)端與服務(wù)器雙方都可信賴(lài)的第三方機(jī)構(gòu)的立場(chǎng)上。威瑞信（VeriSign）就是其中一家非常有名的數(shù)字證書(shū)認(rèn)證機(jī)構(gòu)。我們來(lái)介紹一下數(shù)字證書(shū)認(rèn)證機(jī)構(gòu)的業(yè)務(wù)流程。首先，服務(wù)器的運(yùn)營(yíng)人員向數(shù)字證書(shū)認(rèn)證機(jī)構(gòu)提出公開(kāi)密鑰的申請(qǐng)。數(shù)字證書(shū)認(rèn)證機(jī)構(gòu)在判明提出申請(qǐng)者的身份之后，會(huì)對(duì)已申請(qǐng)的公開(kāi)密鑰做數(shù)字簽名，然后分配這個(gè)已簽名的公開(kāi)密鑰，并將該公開(kāi)密鑰放入公鑰證書(shū)后綁定在一起。
服務(wù)器會(huì)將這份由數(shù)字證書(shū)認(rèn)證機(jī)構(gòu)頒發(fā)的公鑰證書(shū)發(fā)送給客戶(hù)端，以進(jìn)行公開(kāi)密鑰加密方式通信。公鑰證書(shū)也可叫做數(shù)字證書(shū)或直接稱(chēng)
為證書(shū)。
接到證書(shū)的客戶(hù)端可使用數(shù)字證書(shū)認(rèn)證機(jī)構(gòu)的公開(kāi)密鑰，對(duì)那張證書(shū)上的數(shù)字簽名進(jìn)行驗(yàn)證，一旦驗(yàn)證通過(guò)，客戶(hù)端便可明確兩件事：一，認(rèn)證服務(wù)器的公開(kāi)密鑰的是真實(shí)有效的數(shù)字證書(shū)認(rèn)證機(jī)構(gòu)。二，服務(wù)器的公開(kāi)密鑰是值得信賴(lài)的。
此處認(rèn)證機(jī)關(guān)的公開(kāi)密鑰必須安全地轉(zhuǎn)交給客戶(hù)端。使用通信方式時(shí)，如何安全轉(zhuǎn)交是一件很困難的事，因此，多數(shù)瀏覽器開(kāi)發(fā)商發(fā)布版本時(shí)，會(huì)事先在內(nèi)部植入常用認(rèn)證機(jī)關(guān)的公開(kāi)密鑰。

• 可證明組織真實(shí)性的 EV SSL 證書(shū)
  證書(shū)的一個(gè)作用是用來(lái)證明作為通信一方的服務(wù)器是否規(guī)范，另外一個(gè)作用是可確認(rèn)對(duì)方服務(wù)器背后運(yùn)營(yíng)的企業(yè)是否真實(shí)存在。擁有該特性的證書(shū)就是 EV SSL證書(shū)（Extended Validation SSL
  Certificate）。
  EV SSL證書(shū)是基于國(guó)際標(biāo)準(zhǔn)的認(rèn)證指導(dǎo)方針頒發(fā)的證書(shū)。其嚴(yán)格規(guī)定了對(duì)運(yùn)營(yíng)組織是否真實(shí)的確認(rèn)方針，因此，通過(guò)認(rèn)證的Web 網(wǎng)站能夠獲得更高的認(rèn)可度。
  持有 EV SSL證書(shū)的 Web 網(wǎng)站的瀏覽器地址欄處的背景色是綠色的，從視覺(jué)上就能一眼辨別出。而且在地址欄的左側(cè)顯示了 SSL證書(shū)中記錄的組織名稱(chēng)以及頒發(fā)證書(shū)的認(rèn)證機(jī)構(gòu)的名稱(chēng)。
  
  上述機(jī)制的原意圖是為了防止用戶(hù)被釣魚(yú)攻擊（Phishing），但就效果上來(lái)講，還得打一個(gè)問(wèn)號(hào)。很多用戶(hù)可能不了解 EV SSL證書(shū)相關(guān)的知識(shí)，因此也不太會(huì)留意它。
• 用以確認(rèn)客戶(hù)端的客戶(hù)端證書(shū)
  HTTPS 中還可以使用客戶(hù)端證書(shū)。以客戶(hù)端證書(shū)進(jìn)行客戶(hù)端認(rèn)證，證明服務(wù)器正在通信的對(duì)方始終是預(yù)料之內(nèi)的客戶(hù)端，其作用跟服務(wù)器證書(shū)如出一轍。
  但客戶(hù)端證書(shū)仍存在幾處問(wèn)題點(diǎn)。其中的一個(gè)問(wèn)題點(diǎn)是證書(shū)的獲取及發(fā)布。
  想獲取證書(shū)時(shí)，用戶(hù)得自行安裝客戶(hù)端證書(shū)。但由于客戶(hù)端證書(shū)是要付費(fèi)購(gòu)買(mǎi)的，且每張證書(shū)對(duì)應(yīng)到每位用戶(hù)也就意味著需支付和用戶(hù)數(shù)對(duì)等的費(fèi)用。另外，要讓知識(shí)層次不同的用戶(hù)們自行安裝證書(shū)，這件事本身也充滿了各種挑戰(zhàn)。
  現(xiàn)狀是，安全性極高的認(rèn)證機(jī)構(gòu)可頒發(fā)客戶(hù)端證書(shū)但僅用于特殊用途的業(yè)務(wù)。比如那些可支撐客戶(hù)端證書(shū)支出費(fèi)用的業(yè)務(wù)。
  例如，銀行的網(wǎng)上銀行就采用了客戶(hù)端證書(shū)。在登錄網(wǎng)銀時(shí)不僅要求用戶(hù)確認(rèn)輸入 ID 和密碼，還會(huì)要求用戶(hù)的客戶(hù)端證書(shū)，以確認(rèn)用戶(hù)是否從特定的終端訪問(wèn)網(wǎng)銀。
  客戶(hù)端證書(shū)存在的另一個(gè)問(wèn)題點(diǎn)是，客戶(hù)端證書(shū)畢竟只能用來(lái)證明客戶(hù)端實(shí)際存在，而不能用來(lái)證明用戶(hù)本人的真實(shí)有效性。也就是說(shuō)，只要獲得了安裝有客戶(hù)端證書(shū)的計(jì)算機(jī)的使用權(quán)限，也就意味著同時(shí)擁有了客戶(hù)端證書(shū)的使用權(quán)限。
• 認(rèn)證機(jī)構(gòu)信譽(yù)第一
  SSL機(jī)制中介入認(rèn)證機(jī)構(gòu)之所以可行，是因?yàn)榻⒃谄湫庞媒^對(duì)可靠這一大前提下的。然而，2011 年 7 月，荷蘭的一家名叫DigiNotar 的認(rèn)證機(jī)構(gòu)曾遭黑客不法入侵，頒布了 google.com 和twitter.com 等網(wǎng)站的偽造證書(shū)事件。這一事件從根本上撼動(dòng)了SSL的可信度。
  因?yàn)閭卧熳C書(shū)上有正規(guī)認(rèn)證機(jī)構(gòu)的數(shù)字簽名，所以瀏覽器會(huì)判定該證書(shū)是正當(dāng)?shù)摹．?dāng)偽造的證書(shū)被用做服務(wù)器偽裝之時(shí)，用戶(hù)根本無(wú)法察覺(jué)到。
  雖然存在可將證書(shū)無(wú)效化的證書(shū)吊銷(xiāo)列表（Certificate Revocation
  List，CRL）機(jī)制，以及從客戶(hù)端刪除根證書(shū)頒發(fā)機(jī)構(gòu)（Root Certificate Authority，RCA）的對(duì)策，但是距離生效還需要一段
  時(shí)間，而在這段時(shí)間內(nèi)，到底會(huì)有多少用戶(hù)的利益蒙受損失就不得而知了。
• 由自認(rèn)證機(jī)構(gòu)頒發(fā)的證書(shū)稱(chēng)為自簽名證書(shū)
  如果使用 OpenSSL這套開(kāi)源程序，每個(gè)人都可以構(gòu)建一套屬于自己的認(rèn)證機(jī)構(gòu)，從而自己給自己頒發(fā)服務(wù)器證書(shū)。但該服務(wù)器證書(shū)在互聯(lián)網(wǎng)上不可作為證書(shū)使用，似乎沒(méi)什么幫助。
  獨(dú)立構(gòu)建的認(rèn)證機(jī)構(gòu)叫做自認(rèn)證機(jī)構(gòu)，由自認(rèn)證機(jī)構(gòu)頒發(fā)的“無(wú)用”證書(shū)也被戲稱(chēng)為自簽名證書(shū)。
  瀏覽器訪問(wèn)該服務(wù)器時(shí)，會(huì)顯示“無(wú)法確認(rèn)連接安全性”或“該網(wǎng)站的安全證書(shū)存在問(wèn)題”等警告消息。
  
  由自認(rèn)證機(jī)構(gòu)頒發(fā)的服務(wù)器證書(shū)之所以不起作用，是因?yàn)樗鼰o(wú)法消除偽裝的可能性。自認(rèn)證機(jī)構(gòu)能夠產(chǎn)生的作用頂多也就是自己對(duì)外宣稱(chēng)“我是○○”的這種程度。即使采用自簽名證書(shū)，通過(guò) SSL加密之后，可能偶爾還會(huì)看見(jiàn)通信處在安全狀態(tài)的提示，可那也是有問(wèn)題的。因?yàn)?就算加密通信，也不能排除正在和已經(jīng)過(guò)偽裝的假服務(wù)器保持通信。
  值得信賴(lài)的第三方機(jī)構(gòu)介入認(rèn)證，才能讓已植入在瀏覽器內(nèi)的認(rèn)證機(jī)構(gòu)頒布的公開(kāi)密鑰發(fā)揮作用，并借此證明服務(wù)器的真實(shí)性。
  中級(jí)認(rèn)證機(jī)構(gòu)的證書(shū)可能會(huì)變成自認(rèn)證證書(shū)
  多數(shù)瀏覽器內(nèi)預(yù)先已植入備受信賴(lài)的認(rèn)證機(jī)構(gòu)的證書(shū)，但也有一小部分瀏覽器會(huì)植入中級(jí)認(rèn)證機(jī)構(gòu)的證書(shū)。
  對(duì)于中級(jí)認(rèn)證機(jī)構(gòu)頒發(fā)的服務(wù)器證書(shū)，某些瀏覽器會(huì)以正規(guī)的證書(shū)來(lái)對(duì)待，可有的瀏覽器會(huì)當(dāng)作自簽名證書(shū)。

5、HTTPS 的安全通信機(jī)制

為了更好地理解 HTTPS，我們來(lái)觀察一下 HTTPS 的通信步驟。

步驟 1： 客戶(hù)端通過(guò)發(fā)送 Client Hello 報(bào)文開(kāi)始 SSL通信。報(bào)文中包含客戶(hù)端支持的 SSL的指定版本、加密組件（Cipher Suite）列表（所
使用的加密算法及密鑰長(zhǎng)度等）。
步驟 2： 服務(wù)器可進(jìn)行 SSL通信時(shí)，會(huì)以 Server Hello 報(bào)文作為應(yīng)答。和客戶(hù)端一樣，在報(bào)文中包含 SSL版本以及加密組件。服務(wù)器的加密組件內(nèi)容是從接收到的客戶(hù)端加密組件內(nèi)篩選出來(lái)的。
步驟 3： 之后服務(wù)器發(fā)送 Certificate 報(bào)文。報(bào)文中包含公開(kāi)密鑰證書(shū)。
步驟 4： 最后服務(wù)器發(fā)送 Server Hello Done 報(bào)文通知客戶(hù)端，最初階段的 SSL握手協(xié)商部分結(jié)束。
步驟 5： SSL第一次握手結(jié)束之后，客戶(hù)端以 Client Key Exchange 報(bào)文作為回應(yīng)。報(bào)文中包含通信加密中使用的一種被稱(chēng)為 Pre-master
secret 的隨機(jī)密碼串。該報(bào)文已用步驟 3 中的公開(kāi)密鑰進(jìn)行加密。
步驟 6： 接著客戶(hù)端繼續(xù)發(fā)送 Change Cipher Spec 報(bào)文。該報(bào)文會(huì)提示服務(wù)器，在此報(bào)文之后的通信會(huì)采用 Pre-master secret 密鑰加密。
步驟 7： 客戶(hù)端發(fā)送 Finished 報(bào)文。該報(bào)文包含連接至今全部報(bào)文的整體校驗(yàn)值。這次握手協(xié)商是否能夠成功，要以服務(wù)器是否能夠正確
解密該報(bào)文作為判定標(biāo)準(zhǔn)。
步驟 8： 服務(wù)器同樣發(fā)送 Change Cipher Spec 報(bào)文。
步驟 9： 服務(wù)器同樣發(fā)送 Finished 報(bào)文。
步驟 10： 服務(wù)器和客戶(hù)端的 Finished 報(bào)文交換完畢之后，SSL連接就算建立完成。當(dāng)然，通信會(huì)受到 SSL的保護(hù)。從此處開(kāi)始進(jìn)行應(yīng)用
層協(xié)議的通信，即發(fā)送 HTTP 請(qǐng)求。
步驟 11： 應(yīng)用層協(xié)議通信，即發(fā)送 HTTP 響應(yīng)。
步驟 12： 最后由客戶(hù)端斷開(kāi)連接。斷開(kāi)連接時(shí)，發(fā)送 close_notify 報(bào)文。上圖做了一些省略，這步之后再發(fā)送 TCP FIN 報(bào)文來(lái)關(guān)閉與 TCP
的通信。
在以上流程中，應(yīng)用層發(fā)送數(shù)據(jù)時(shí)會(huì)附加一種叫做 MAC（Message Authentication Code）的報(bào)文摘要。MAC 能夠查知報(bào)文是否遭到篡改，從而保護(hù)報(bào)文的完整性。
下面是對(duì)整個(gè)流程的圖解。圖中說(shuō)明了從僅使用服務(wù)器端的公開(kāi)密鑰證書(shū)（服務(wù)器證書(shū)）建立 HTTPS 通信的整個(gè)過(guò)程。

1 CBC 模式（Cipher Block Chaining）又名密碼分組鏈接模式。在此模式下，將前一個(gè)明文塊加密處理后和下一個(gè)明文塊做 XOR 運(yùn)算，使之重疊，然后再對(duì)運(yùn)算結(jié)果做加密處理。對(duì)第一個(gè)明文塊做加密時(shí)，要么使用前一段密文的最后一塊，要么利用外部生成的初始向量（initial vector，IV）。

• SSL 和 TLS
  HTTPS 使用 SSL（Secure Socket Layer） 和 TLS（Transport Layer Security）這兩個(gè)協(xié)議。
  SSL技術(shù)最初是由瀏覽器開(kāi)發(fā)商網(wǎng)景通信公司率先倡導(dǎo)的，開(kāi)發(fā)過(guò) SSL3.0 之前的版本。目前主導(dǎo)權(quán)已轉(zhuǎn)移到 IETF（Internet Engineering Task Force，Internet 工程任務(wù)組）的手中。
  IETF 以 SSL3.0 為基準(zhǔn)，后又制定了 TLS1.0、TLS1.1 和TLS1.2。TSL是以 SSL為原型開(kāi)發(fā)的協(xié)議，有時(shí)會(huì)統(tǒng)一稱(chēng)該協(xié)議為 SSL。當(dāng)前主流的版本是 SSL3.0 和 TLS1.0。
  由于 SSL1.0 協(xié)議在設(shè)計(jì)之初被發(fā)現(xiàn)出了問(wèn)題，就沒(méi)有實(shí)際投入使用。SSL2.0 也被發(fā)現(xiàn)存在問(wèn)題，所以很多瀏覽器直接廢除了該協(xié)議版本。
• SSL速度慢嗎
  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ù)器和客戶(hù)端都需要進(jìn)行加密和解密的運(yùn)算處理。因此從結(jié)果上講，比起 HTTP 會(huì)更多地消耗服務(wù)器和客戶(hù)端的硬件資源，導(dǎo)致負(fù)載增強(qiáng)。
  針對(duì)速度變慢這一問(wèn)題，并沒(méi)有根本性的解決方案，我們會(huì)使用SSL加速器這種（專(zhuān)用服務(wù)器）硬件來(lái)改善該問(wèn)題。該硬件為SSL通信專(zhuān)用硬件，相對(duì)軟件來(lái)講，能夠提高數(shù)倍 SSL的計(jì)算速度。僅在 SSL處理時(shí)發(fā)揮 SSL加速器的功效，以分擔(dān)負(fù)載。

為什么不一直使用 HTTPS
既然 HTTPS 那么安全可靠，那為何所有的 Web 網(wǎng)站不一直使用HTTPS ？
其中一個(gè)原因是，因?yàn)榕c純文本通信相比，加密通信會(huì)消耗更多的CPU 及內(nèi)存資源。如果每次通信都加密，會(huì)消耗相當(dāng)多的資源，平攤到一臺(tái)計(jì)算機(jī)上時(shí)，能夠處理的請(qǐng)求數(shù)量必定也會(huì)隨之減少。
因此，如果是非敏感信息則使用 HTTP 通信，只有在包含個(gè)人信息等敏感數(shù)據(jù)時(shí)，才利用 HTTPS 加密通信。
特別是每當(dāng)那些訪問(wèn)量較多的 Web 網(wǎng)站在進(jìn)行加密處理時(shí)，它們所承擔(dān)著的負(fù)載不容小覷。在進(jìn)行加密處理時(shí)，并非對(duì)所有內(nèi)容都進(jìn)行加密處理，而是僅在那些需要信息隱藏時(shí)才會(huì)加密，以節(jié)約資源。

除此之外，想要節(jié)約購(gòu)買(mǎi)證書(shū)的開(kāi)銷(xiāo)也是原因之一。
要進(jìn)行 HTTPS 通信，證書(shū)是必不可少的。而使用的證書(shū)必須向認(rèn)證機(jī)構(gòu)（CA）購(gòu)買(mǎi)。證書(shū)價(jià)格可能會(huì)根據(jù)不同的認(rèn)證機(jī)構(gòu)略有不同。通常，一年的授權(quán)需要數(shù)萬(wàn)日元（現(xiàn)在一萬(wàn)日元大約折合 600
人民幣）。
那些購(gòu)買(mǎi)證書(shū)并不合算的服務(wù)以及一些個(gè)人網(wǎng)站，可能只會(huì)選擇采用 HTTP 的通信方式。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-650650.html

到了這里，關(guān)于HTTP——七、確保Web安全的HTTPS的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！