摘要：確保安全的在協(xié)議中有可能存在信息竊聽(tīng)或身份偽裝等安全問(wèn)題。與組合使用的被稱為，超文本傳輸安全協(xié)議或。無(wú)法證明報(bào)文完整性，可能已遭篡改所謂完整性是指信息的準(zhǔn)確度。如何防止篡改雖然有使用協(xié)議確定報(bào)文完整性的方法，但事實(shí)上并不便捷可靠。

在 HTTP 協(xié)議中有可能存在信息竊聽(tīng)或身份偽裝等安全問(wèn)題。使用 HTTPS 通信機(jī)制可以有效地防止這些問(wèn)題。

一. HTTP 的缺點(diǎn)

HTTP 主要有這些不足，例舉如下：

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

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

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

HTTP 的缺點(diǎn):

通信使用明文可能會(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ù)器在和客戶端通信時(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 被稱為 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ì)存在以下各種隱患:

無(wú)法確定請(qǐng)求發(fā)送至目標(biāo)的 Web 服務(wù)器是否是按真實(shí)意圖返回響應(yīng)的那臺(tái)服務(wù)器。有可能是已偽裝的 Web 服務(wù)器。
無(wú)法確定響應(yīng)返回到的客戶端是否是按真實(shí)意圖接收響應(yīng)的那個(gè)客戶端。有可能是已偽裝的客戶端。
無(wú)法確定正在通信的對(duì)方是否具備訪問(wèn)權(quán)限。因?yàn)槟承?Web 服務(wù)器上保存著重要的信息，只想發(fā)給特定用戶通信的權(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 不僅提供加密處理，而且還使用了一種被稱為證書(shū)的手段，可用于確定方。
證書(shū)由值得信任的第三方機(jī)構(gòu)頒發(fā)，用以證明服務(wù)器和客戶端是實(shí)際存在的。另外，偽造證書(shū)從技術(shù)角度來(lái)說(shuō)是異常困難的一件事。所以只要能夠確認(rèn)通信方（服務(wù)器或客戶端）持有的證書(shū)， 即可判斷通信方的真實(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)文完整性，因此，在請(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ú)法確定客戶端下載的文件和服務(wù)器上存放的文件是否前后一致的。文件內(nèi)容在傳輸途中可能已經(jīng)被篡改為其他的內(nèi)容。即使內(nèi)容真的已改變，作為接 收方的客戶端也是覺(jué)察不到的。像這樣，請(qǐng)求或響應(yīng)在傳輸途中，遭攻擊者攔截并篡改內(nèi)容的攻 擊稱為中間人攻擊（Man-in-the-Middle attack，MITM）。

4.如何防止篡改

雖然有使用 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ù)生成的散列值。不論使用哪一種方法，都需要操縱客戶端的用戶本人親自檢查驗(yàn)證下載的文件是否就是原來(lái)服務(wù)器上的文件。 瀏覽器無(wú)法自動(dòng)幫用戶檢查?？上У氖牵眠@些方法也依然無(wú)法百分百保證確認(rèn)結(jié)果正確。因?yàn)?PGP 和 MD5 本身被改寫(xiě)的話，用戶是沒(méi)有辦法意識(shí)到的。 為了有效防止這些弊端，有必要使用 HTTPS。SSL 提供認(rèn)證和加密處理及摘要功能。僅靠 HTTP 確保完整性是非常困難的，因此通過(guò)和其他協(xié)議組合使用來(lái)實(shí)現(xiàn)這個(gè)目標(biāo)。

二.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ù)器也好，客戶端也好，都是沒(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 稱為 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è)密鑰的方式稱為共享密鑰加密（Common key crypto system），也被叫做對(duì)稱密鑰加密。

以共享密鑰方式加密時(shí)必須將密鑰也發(fā)給對(duì)方。可究竟怎樣才能安全地轉(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ì)稱的密鑰。一把叫做私有密鑰 （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)處于客戶端與服務(wù)器雙方都可信賴的第三方機(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ā)送給客戶端，以進(jìn)行公開(kāi)密鑰加密方式通信。公鑰證書(shū)也可叫做數(shù)字證書(shū)或直接稱為證書(shū)。接到證書(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)密鑰。

可證明組織真實(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ū)中記錄的組織名稱以及頒發(fā)證書(shū)的認(rèn)證機(jī)構(gòu)的名稱。上述機(jī)制的原意圖是為了防止用戶被釣魚(yú)攻擊（Phishing），但就效果上來(lái)講，還得打一個(gè)問(wèn)號(hào)。很多用戶可能不了解 EV SSL 證書(shū)相關(guān)的知識(shí)，因此也不太會(huì)留意它。
用以確認(rèn)客戶端的客戶端證書(shū)
HTTPS 中還可以使用客戶端證書(shū)。以客戶端證書(shū)進(jìn)行客戶端認(rèn)證，證明服務(wù)器正在通信的對(duì)方始終是預(yù)料之內(nèi)的客戶端，其作用跟服務(wù)器證書(shū)如出一轍。但客戶端證書(shū)仍存在幾處問(wèn)題點(diǎn)。其中的一個(gè)問(wèn)題點(diǎn)是證書(shū)的獲取及發(fā)布。想獲取證書(shū)時(shí)，用戶得自行安裝客戶端證書(shū)。但由于客戶端證書(shū)是要付費(fèi)購(gòu)買的，且每張證書(shū)對(duì)應(yīng)到每位用戶也就意味著需支付和用戶數(shù)對(duì)等的費(fèi)用。另外，要讓知識(shí)層次不同的用戶們自行安 裝證書(shū)，這件事本身也充滿了各種挑戰(zhàn)?，F(xiàn)狀是，安全性極高的認(rèn)證機(jī)構(gòu)可頒發(fā)客戶端證書(shū)但僅用于特殊用途的業(yè)務(wù)。比如那些可支撐客戶端證書(shū)支出費(fèi)用的業(yè)務(wù)。例如，銀行的網(wǎng)上銀行就采用了客戶端證書(shū)。在登錄網(wǎng)銀時(shí)不僅要求用戶確認(rèn)輸入 ID 和密碼，還會(huì)要求用戶的客戶端證書(shū)，以確認(rèn)用戶是否從特定的終端訪問(wèn)網(wǎng)銀?？蛻舳俗C書(shū)存在的另一個(gè)問(wèn)題點(diǎn)是，客戶端證書(shū)畢竟只能用來(lái)證明客戶端實(shí)際存在，而不能用來(lái)證明用戶本人的真實(shí)有效性。也就是說(shuō)，只要獲得了安裝有客戶端證書(shū)的計(jì)算機(jī)的使用權(quán)限，也就意味著同時(shí)擁有了客戶端證書(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í)，用戶根本無(wú)法察覺(jué)到。雖然存在可將證書(shū)無(wú)效化的證書(shū)吊銷列表（Certificate Revocation List，CRL）機(jī)制，以及從客戶端刪除根證書(shū)頒發(fā)機(jī)構(gòu)（Root Certificate Authority，RCA）的對(duì)策，但是距離生效還需要一段時(shí)間，而在這段時(shí)間內(nèi)，到底會(huì)有多少用戶的利益蒙受損失就不得而知了。
由自認(rèn)證機(jī)構(gòu)頒發(fā)的證書(shū)稱為自簽名證書(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ū)也被戲稱為自簽名證書(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ì)外宣稱“我是○○”的這種程度。即使采用自簽名證書(shū)，通過(guò) SSL 加密之后，可能偶爾還會(huì)看見(jiàn)通信處在安全狀態(tài)的提示，可那也是有問(wèn)題的。因?yàn)?就算加密通信，也不能排除正在和已經(jīng)過(guò)偽 裝的假服務(wù)器保持通信。值得信賴的第三方機(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ù)先已植入備受信賴的認(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 的通信步驟:

步驟 1： 客戶端通過(guò)發(fā)送 Client Hello 報(bào)文開(kāi)始 SSL 通信。報(bào)文中包含客戶端支持的 SSL 的指定版本、加密組件（Cipher Suite）列表（所使用的加密算法及密鑰長(zhǎng)度等）。
步驟 2： 服務(wù)器可進(jìn)行 SSL 通信時(shí)，會(huì)以 Server Hello 報(bào)文作為應(yīng)答。和客戶端一樣，在報(bào)文中包含 SSL 版本以及加密組件。服務(wù)器的加密組件內(nèi)容是從接收到的客戶端加密組件內(nèi)篩選出來(lái)的。
步驟 3： 之后服務(wù)器發(fā)送 Certificate 報(bào)文。報(bào)文中包含公開(kāi)密鑰證書(shū)。
步驟 4： 最后服務(wù)器發(fā)送 Server Hello Done 報(bào)文通知客戶端，最初階段的 SSL 握手協(xié)商部分結(jié)束。
步驟 5： SSL 第一次握手結(jié)束之后，客戶端以 Client Key Exchange 報(bào)文作為回應(yīng)。報(bào)文中包含通信加密中使用的一種被稱為 Pre-master secret 的隨機(jī)密碼串。該報(bào)文已用步驟 3 中的公開(kāi)密鑰進(jìn)行加密。
步驟 6： 接著客戶端繼續(xù)發(fā)送 Change Cipher Spec 報(bào)文。該報(bào)文會(huì)提示服務(wù)器，在此報(bào)文之后的通信會(huì)采用 Pre-master secret 密鑰加密。
步驟 7： 客戶端發(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ù)器和客戶端的 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： 最后由客戶端斷開(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ò)程。

- 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)一稱該協(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ù)器和客戶端都需要進(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ù)載。

為什么不一直使用 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)買證書(shū)的開(kāi)銷也是原因之一。要進(jìn)行 HTTPS 通信，證書(shū)是必不可少的。而使用的證書(shū)必須向認(rèn)證機(jī)構(gòu)（CA）購(gòu)買。證書(shū)價(jià)格可能會(huì)根據(jù)不同的認(rèn)證機(jī)構(gòu)略有不同。通常，一年的授權(quán)需要數(shù)萬(wàn)日元（現(xiàn)在一萬(wàn)日元大約折合 600 人民幣）。那些購(gòu)買證書(shū)并不合算的服務(wù)以及一些個(gè)人網(wǎng)站，可能只會(huì)選擇采用 HTTP 的通信方式。

以下是往日學(xué)習(xí)總結(jié)，有需要的盆友可以去看看噢~~
TCP/IP基礎(chǔ)總結(jié)性學(xué)習(xí)（1）：了解web和網(wǎng)絡(luò)基礎(chǔ)
https://segmentfault.com/a/11...
TCP/IP基礎(chǔ)總結(jié)性學(xué)習(xí)（2）：簡(jiǎn)單的HTTP協(xié)議
https://segmentfault.com/a/11...
TCP/IP基礎(chǔ)總結(jié)性學(xué)習(xí)（3）：HTTP 報(bào)文內(nèi)的 HTTP 信息
https://segmentfault.com/a/11...
TCP/IP基礎(chǔ)總結(jié)性學(xué)習(xí)（4）：返回結(jié)果的 HTTP 狀態(tài)碼
https://segmentfault.com/a/11...
TCP/IP基礎(chǔ)總結(jié)性學(xué)習(xí)（5）：與 HTTP 協(xié)作的 Web 服務(wù)器
https://segmentfault.com/a/11...
TCP/IP基礎(chǔ)總結(jié)性學(xué)習(xí)（6）：與 HTTP 協(xié)作的 Web 服務(wù)器
https://segmentfault.com/a/11...
前端實(shí)習(xí)面試試題總結(jié)：
https://segmentfault.com/a/11...