信息安全協(xié)議有哪些?

　1.IPSec

我們提供的服務(wù)有：網(wǎng)站制作、成都網(wǎng)站建設(shè)、微信公眾號(hào)開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、杜集ssl等。為上千企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的杜集網(wǎng)站制作公司

IPSec 是Internet Protocol Security的縮寫,它是設(shè)計(jì)為IPv4和IPv6協(xié)議提供基于加密安全的協(xié)議，它使用AH和ESP協(xié)議來實(shí)現(xiàn)其安全，使用 ISAKMP/Oakley及SKIP進(jìn)行密鑰交換、管理及安全協(xié)商(Security Association)。IPSec安全協(xié)議工作在網(wǎng)絡(luò)層，運(yùn)行在它上面的所有網(wǎng)絡(luò)通道都是加密的。IPSec安全服務(wù)包括訪問控制、數(shù)據(jù)源認(rèn)證、無連 接數(shù)據(jù)完整性、抗重播、數(shù)據(jù)機(jī)密性和有限的通信流量機(jī)密性。IPSec使用身份認(rèn)證機(jī)制進(jìn)行訪問控制，即兩個(gè)IPSec實(shí)體試圖進(jìn)行通信前，必須通過 IKE協(xié)商SA，協(xié)商過程中要進(jìn)行身份認(rèn)證，身份認(rèn)證采用公鑰簽名機(jī)制，使用數(shù)字簽名標(biāo)準(zhǔn)(DSS)算法或RSA算法，而公通常是從證書中獲得的; IPSec使用消息鑒別機(jī)制實(shí)現(xiàn)數(shù)據(jù)源驗(yàn)證服務(wù)，即發(fā)送方在發(fā)送數(shù)據(jù)包前，要用消息鑒別算法HMAC計(jì)算MAC，HMAC將消息的一部分和密鑰作為輸入， 以MAC作為輸出，目的地收到IP包后，使用相同的驗(yàn)證算法和密鑰計(jì)算驗(yàn)證數(shù)據(jù)，如果計(jì)算出的MAC與數(shù)據(jù)包中的MAC完全相同，則認(rèn)為數(shù)據(jù)包通過了驗(yàn) 證;無連接數(shù)據(jù)完整性服務(wù)是對(duì)單個(gè)數(shù)據(jù)包是否被篡改進(jìn)行檢查，而對(duì)數(shù)據(jù)包的到達(dá)順序不作要求，IPSec使用數(shù)據(jù)源驗(yàn)證機(jī)制實(shí)現(xiàn)無連接完整性服務(wù); IPSec的抗重播服務(wù)，是指防止攻擊者截取和復(fù)制IP包，然后發(fā)送到源目的地，IPSec根據(jù) IPSec頭中的序號(hào)字段，使用滑動(dòng)窗口原理，實(shí)現(xiàn)抗重播服務(wù);通信流機(jī)密性服務(wù)是指防止對(duì)通信的外部屬性(源地址、目的地址、消息長(zhǎng)度和通信頻率等)的 泄露，從而使攻擊者對(duì)網(wǎng)絡(luò)流量進(jìn)行分析，推導(dǎo)其中的傳輸頻率、通信者身份、數(shù)據(jù)包大小、數(shù)據(jù)流標(biāo)識(shí)符等信息。IPSec使用ESP隧道模式，對(duì)IP包進(jìn)行 封裝，可達(dá)到一定程度的機(jī)密性，即有限的通信流機(jī)密性。

2.SSL協(xié)議

安全套接層(Security Socket Layer，SSL)協(xié)議就是設(shè)計(jì)來保護(hù)網(wǎng)絡(luò)傳輸信息的,它工作在傳輸層之上，應(yīng)用層之下，其底層是基于傳輸層可靠的流傳輸協(xié)議(如TCP)。SSL協(xié)議 最早由Netscape公司于1994年11月提出并率先實(shí)現(xiàn)(SSLv2)的，之后經(jīng)過多次修改，最終被IETF所采納，并制定為傳輸層安全 (Transport Layer Security，TLS)標(biāo)準(zhǔn)。該標(biāo)準(zhǔn)剛開始制定時(shí)是面向Web應(yīng)用的安全解決方案，隨著SSL部署的簡(jiǎn)易性和較高的安全性逐漸為人所知，現(xiàn)在它已經(jīng)成 為Web上部署最為廣泛的信息安全協(xié)議之一。近年來SSL的應(yīng)用領(lǐng)域不斷被拓寬，許多在網(wǎng)絡(luò)上傳輸?shù)拿舾行畔?如電子商務(wù)、金融業(yè)務(wù)中的信用卡號(hào)或PIN 碼等機(jī)密信息)都紛紛采用SSL來進(jìn)行安全保護(hù)。SSL通過加密傳輸來確保數(shù)據(jù)的機(jī)密性，通過信息驗(yàn)證碼(Message Authentication Codes，MAC)機(jī)制來保護(hù)信息的完整性，通過數(shù)字證書來對(duì)發(fā)送和接收者的身份進(jìn)行認(rèn)證。

實(shí)際上SSL協(xié)議本身也是個(gè)分層的協(xié)議，它由消息子層以及承載消息的記錄子層組成。

SSL 記錄協(xié)議首先按照一定的原則如性能最優(yōu)原則把消息數(shù)據(jù)分成一定長(zhǎng)度的片斷;接著分別對(duì)這些片斷進(jìn)行消息摘要和MAC計(jì)算，得到MAC值;然后再對(duì)這些片斷 進(jìn)行加密計(jì)算;最后把加密后的片斷和MAC值連接起來，計(jì)算其長(zhǎng)度，并打上記錄頭后發(fā)送到傳輸層。這是一般的消息數(shù)據(jù)到達(dá)后，記錄層所做的工作。但有的特 殊消息如握手消息，由于發(fā)送時(shí)還沒有完全建立好加密的通道，所以并不完全按照這個(gè)方式進(jìn)行;而且有的消息比較短小，如警示消息(Alert)，出于性能考 慮也可能和其它的一些消息一起被打包成一個(gè)記錄。

消息子層是應(yīng)用層和SSL記錄層間的接口，負(fù)責(zé)標(biāo)識(shí)并在應(yīng)用層和SSL記錄層間傳輸數(shù)據(jù)或者對(duì)握 手信息和警示信息的邏輯進(jìn)行處理，可以說是整個(gè)SSL層的核心。其中尤其關(guān)鍵的又是握手信息的處理，它是建立安全通道的關(guān)鍵，握手狀態(tài)機(jī)運(yùn)行在這一層上。 警示消息的處理實(shí)現(xiàn)上也可以作為握手狀態(tài)機(jī)的一部分。SSL協(xié)議為了描述所有消息，引入了SSL規(guī)范語言，其語法結(jié)構(gòu)主要仿照C語言，而是無歧義、精簡(jiǎn) 的。

3. S-HTTP

安全超文本傳輸協(xié)議(Secure HyperText Transfer Protocol，S-HTTP)是EIT公司結(jié)合 HTTP 而設(shè)計(jì)的一種消息安全通信協(xié)議。S-HTTP協(xié)議處于應(yīng)用層，它是HTTP協(xié)議的擴(kuò)展，它僅適用于HTTP聯(lián)結(jié)上，S-HTTP可提供通信保密、身份識(shí) 別、可信賴的信息傳輸服務(wù)及數(shù)字簽名等。S-HTTP 提供了完整且靈活的加密算法及相關(guān)參數(shù)。選項(xiàng)協(xié)商用來確定客戶機(jī)和服務(wù)器在安全事務(wù)處理模式、加密算法(如用于簽名的非對(duì)稱算法 RSA 和 DSA等、用于對(duì)稱加解密的 DES 和 RC2 等)及證書選擇等方面達(dá)成一致。

S-HTTP 支持端對(duì)端安全傳輸，客戶機(jī)可能“首先”啟動(dòng)安全傳輸(使用報(bào)頭的信息)，如，它可以用來支持加密技術(shù)。S-HTTP是通過在S-HTTP所交換包的特殊頭標(biāo)志來建立安全通訊的。當(dāng)使用 S-HTTP時(shí)，敏感的數(shù)據(jù)信息不會(huì)在網(wǎng)絡(luò)上明文傳輸。

4. S/MIME

S/MIME 是Secure / Multipurpose Internet Mail Extensions的縮寫，是從PEM (Privacy Enhanced Mail)和MIME(Internet郵件的附件標(biāo)準(zhǔn))發(fā)展而來的。S/MIME是利用單向散列算法(如SHA-1、MD5等)和公鑰機(jī)制的加密體系。 S/MIME的證書格式采用X.509標(biāo)準(zhǔn)格式。S/MIME的認(rèn)證機(jī)制依賴于層次結(jié)構(gòu)的證書認(rèn)證機(jī)構(gòu)，所有下一級(jí)的組織和個(gè)人的證書均由上一級(jí)的組織負(fù) 責(zé)認(rèn)證，而最上一級(jí)的組織(根證書)之間相互認(rèn)證，整個(gè)信任關(guān)系是樹狀結(jié)構(gòu)的。另外，S/MIME將信件內(nèi)容加密簽名后作為特殊的附件傳送。

HTTP，SSL/TLS和HTTPS協(xié)議的區(qū)別與聯(lián)系

概述：HTTP是普通明文傳輸協(xié)議，HTTPS是加密協(xié)議，相當(dāng)于HTTP的安全版本，但需要HTTPS加密必須擁有SSL證書與TLS協(xié)議交流產(chǎn)生，SSL證書在線簽發(fā)：網(wǎng)頁鏈接

1、“HTTP”是什么？

超文本傳輸協(xié)議（HTTP，HyperText Transfer Protocol)是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議，所有的WWW文件都必須遵守這個(gè)標(biāo)準(zhǔn)，設(shè)計(jì)HTTP最初的目的是為了提供一種發(fā)布和接收HTML頁面的方法（具體可查看馬海祥博客《深入解析互聯(lián)網(wǎng)協(xié)議的原理》的相關(guān)介紹）。

1960年美國(guó)人Ted Nelson構(gòu)思了一種通過計(jì)算機(jī)處理文本信息的方法，并稱之為超文本（hypertext），這成為了HTTP超文本傳輸協(xié)議標(biāo)準(zhǔn)架構(gòu)的發(fā)展根基。

簡(jiǎn)單來說，HTTP就是一個(gè)網(wǎng)絡(luò)協(xié)議，是專門用來幫你傳輸Web內(nèi)容的，關(guān)于這個(gè)協(xié)議，就算你不了解，至少也聽說過吧？比如你訪問我的博客的主頁，瀏覽器地址欄會(huì)出現(xiàn)的網(wǎng)址：，大部分網(wǎng)站都是通過HTTP協(xié)議來傳輸Web頁面、以及Web頁面上包含的各種東東（圖片、CSS 樣式、JS 腳本）。

2、“SSL/TLS”是什么？

SSL是“Secure Sockets Layer”的縮寫，中文叫做“安全套接層”，它是在上世紀(jì)90年代中期，由網(wǎng)景公司設(shè)計(jì)的（順便插一句，網(wǎng)景公司不光發(fā)明了 SSL，還發(fā)明了很多 Web 的基礎(chǔ)設(shè)施——比如“CSS 樣式表”和“JS 腳本”）。

為啥要發(fā)明SSL這個(gè)協(xié)議捏？因?yàn)樵然ヂ?lián)網(wǎng)上使用的HTTP協(xié)議是明文的，存在很多缺點(diǎn)——比如傳輸內(nèi)容會(huì)被偷窺（嗅探）和篡改，發(fā)明SSL協(xié)議，就是為了解決這些問題。

到了1999年，SSL因?yàn)閼?yīng)用廣泛，已經(jīng)成為互聯(lián)網(wǎng)上的事實(shí)標(biāo)準(zhǔn)，IETF就在那年把SSL標(biāo)準(zhǔn)化，標(biāo)準(zhǔn)化之后的名稱改為TLS（是“Transport Layer Security”的縮寫），中文叫做“傳輸層安全協(xié)議”。

很多相關(guān)的文章都把這兩者并列稱呼（SSL/TLS），因?yàn)檫@兩者可以視作同一個(gè)東西的不同階段。

3、“HTTPS”是什么意思？

解釋完 HTTP 和 SSL/TLS，現(xiàn)在就可以來解釋 HTTPS 啦，咱們通常所說的 HTTPS 協(xié)議，說白了就是“HTTP 協(xié)議”和“SSL/TLS 協(xié)議”的組合，你可以把 HTTPS 大致理解為——“HTTP over SSL”或“HTTP over TLS”（反正 SSL 和 TLS 差不多）。

HTTPS（全稱：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全為目標(biāo)的HTTP通道，簡(jiǎn)單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎(chǔ)是SSL，因此加密的詳細(xì)內(nèi)容就需要SSL。

它是一個(gè)URI scheme（抽象標(biāo)識(shí)符體系），句法類同http:體系，用于安全的HTTP數(shù)據(jù)傳輸。

https:URL表明它使用了HTTP，但HTTPS存在不同于HTTP的默認(rèn)端口及一個(gè)加密/身份驗(yàn)證層（在HTTP與TCP之間），這個(gè)系統(tǒng)的最初研發(fā)由網(wǎng)景公司(Netscape)進(jìn)行，并內(nèi)置于其瀏覽器Netscape Navigator中，提供了身份驗(yàn)證與加密通訊方法，現(xiàn)在它被廣泛用于萬維網(wǎng)上安全敏感的通訊，例如交易支付方面。

4、談?wù)劇皩?duì)稱加密”和“非對(duì)稱加密”的概念

如果我們想搞明白“對(duì)稱加密”和“非對(duì)稱加密”的概念，首先，我們就要先知道什么是“加密”和“解密”？

（1）、什么是“加密”和“解密”？

通俗而言，你可以把“加密”和“解密”理解為某種互逆的數(shù)學(xué)運(yùn)算，就好比“加法和減法”互為逆運(yùn)算、“乘法和除法”互為逆運(yùn)算。

“加密”的過程，就是把“明文”變成“密文”的過程；反之，“解密”的過程，就是把“密文”變?yōu)椤懊魑摹保谶@兩個(gè)過程中，都需要一個(gè)關(guān)鍵的東東——叫做“密鑰”——來參與數(shù)學(xué)運(yùn)算。

（2）、什么是“對(duì)稱加密”？

所謂的“對(duì)稱加密技術(shù)”，意思就是說：“加密”和“解密”使用相同的密鑰。這個(gè)比較好理解，就好比你用 7zip 或 WinRAR 創(chuàng)建一個(gè)帶密碼（口令）的加密壓縮包，當(dāng)你下次要把這個(gè)壓縮文件解開的時(shí)候，你需要輸入同樣的密碼，在這個(gè)例子中，密碼/口令就如同剛才說的“密鑰”。

對(duì)稱加密是最快速、最簡(jiǎn)單的一種加密方式，加密（encryption）與解密（decryption）用的是同樣的密鑰（secret key），這種方法在密碼學(xué)中叫做對(duì)稱加密算法，對(duì)稱加密有很多種算法，由于它效率很高，所以被廣泛使用在很多加密協(xié)議的核心當(dāng)中。

（3）、什么是“非對(duì)稱加密”？

所謂的“非對(duì)稱加密技術(shù)”，意思就是說：“加密”和“解密”使用不同的密鑰，這玩意兒比較難理解，也比較難想到，當(dāng)年“非對(duì)稱加密”的發(fā)明，還被譽(yù)為“密碼學(xué)”歷史上的一次革命。

非對(duì)稱加密為數(shù)據(jù)的加密與解密提供了一個(gè)非常安全的方法，它使用了一對(duì)密鑰，公鑰（public key）和私鑰（private key），私鑰只能由一方安全保管，不能外泄，而公鑰則可以發(fā)給任何請(qǐng)求它的人，非對(duì)稱加密使用這對(duì)密鑰中的一個(gè)進(jìn)行加密，而解密則需要另一個(gè)密鑰。

由于篇幅有限，對(duì)“非對(duì)稱加密”這個(gè)話題，我就不展開了，有空的話，我會(huì)再單獨(dú)寫一篇文章在馬海祥博客上發(fā)布。

（4）、各自有啥優(yōu)缺點(diǎn)？

看完剛才的定義，很顯然：（從功能角度而言）“非對(duì)稱加密”能干的事情比“對(duì)稱加密”要多，這是“非對(duì)稱加密”的優(yōu)點(diǎn)，但是“非對(duì)稱加密”的實(shí)現(xiàn)，通常需要涉及到“復(fù)雜數(shù)學(xué)問題”，所以，“非對(duì)稱加密”的性能通常要差很多（相對(duì)于“對(duì)稱加密”而言）。

這兩者的優(yōu)缺點(diǎn)，也影響到了 SSL 協(xié)議的設(shè)計(jì)。

5、HTTP協(xié)議的特點(diǎn)

作為背景知識(shí)介紹，還需要再稍微談一下 HTTP 協(xié)議本身的特點(diǎn)，HTTP本身有很多特點(diǎn)，考慮到篇幅有限，馬海祥只談那些和HTTPS相關(guān)的特點(diǎn)，想要了解更深入的HTTP知識(shí)，可查看馬海祥博客《HTTP服務(wù)的七層架構(gòu)技術(shù)解析及運(yùn)用》的相關(guān)介紹。

（1）、HTTP的版本和歷史

如今咱們用的 HTTP 協(xié)議，版本號(hào)是 1.1（也就是 HTTP 1.1），這個(gè) 1.1 版本是1995年底開始起草的（技術(shù)文檔是RFC2068），并在1999年正式發(fā)布（技術(shù)文檔是RFC2616）。

在 1.1 之前，還有曾經(jīng)出現(xiàn)過兩個(gè)版本“0.9 和 1.0”，其中的 HTTP 0.9 沒有被廣泛使用，而 HTTP 1.0 被廣泛使用過。

（2）、HTTP 和 TCP 之間的關(guān)系

簡(jiǎn)單地說，TCP 協(xié)議是 HTTP 協(xié)議的基石——HTTP 協(xié)議需要依靠 TCP 協(xié)議來傳輸數(shù)據(jù)。

在網(wǎng)絡(luò)分層模型中，TCP 被稱為“傳輸層協(xié)議”，而 HTTP 被稱為“應(yīng)用層協(xié)議”。

有很多常見的應(yīng)用層協(xié)議是以 TCP 為基礎(chǔ)的，比如“FTP、SMTP、POP、IMAP”等。

TCP被稱為“面向連接”的傳輸層協(xié)議，關(guān)于它的具體細(xì)節(jié)，俺就不展開了（否則篇幅又失控了），你只需知道：傳輸層主要有兩個(gè)協(xié)議，分別是TCP和UDP，TCP比UDP更可靠，你可以把 TCP 協(xié)議想象成某個(gè)水管，發(fā)送端這頭進(jìn)水，接收端那頭就出水，并且 TCP 協(xié)議能夠確保，先發(fā)送的數(shù)據(jù)先到達(dá)（與之相反，UDP不保證這點(diǎn)）。

（3）、HTTP協(xié)議如何使用 TCP 連接？

HTTP對(duì) TCP 連接的使用，分為兩種方式：俗稱“短連接”和“長(zhǎng)連接”（“長(zhǎng)連接”又稱“持久連接”，叫做“Keep-Alive”或“Persistent Connection”）

假設(shè)有一個(gè)網(wǎng)頁，里面包含好多圖片，還包含好多外部的CSS文件和JS文件，在“短連接”的模式下，瀏覽器會(huì)先發(fā)起一個(gè) TCP 連接，拿到該網(wǎng)頁的 HTML 源代碼（拿到 HTML 之后，這個(gè) TCP 連接就關(guān)閉了）。然后，瀏覽器開始分析這個(gè)網(wǎng)頁的源碼，知道這個(gè)頁面包含很多外部資源（圖片、CSS、JS）。然后針對(duì)每一個(gè)外部資源，再分別發(fā)起一個(gè)個(gè) TCP 連接，把這些文件獲取到本地（同樣的，每抓取一個(gè)外部資源后，相應(yīng)的 TCP 就斷開）。

相反，如果是“長(zhǎng)連接”的方式，瀏覽器也會(huì)先發(fā)起一個(gè) TCP 連接去抓取頁面，但是抓取頁面之后，該 TCP 連接并不會(huì)立即關(guān)閉，而是暫時(shí)先保持著（所謂的“Keep-Alive”），然后瀏覽器分析 HTML 源碼之后，發(fā)現(xiàn)有很多外部資源，就用剛才那個(gè) TCP 連接去抓取此頁面的外部資源。

在 HTTP 1.0 版本，默認(rèn)使用的是“短連接”（那時(shí)候是 Web 誕生初期，網(wǎng)頁相對(duì)簡(jiǎn)單，“短連接”的問題不大）。

到了1995年底開始制定 HTTP 1.1 草案的時(shí)候，網(wǎng)頁已經(jīng)開始變得復(fù)雜（網(wǎng)頁內(nèi)的圖片、腳本越來越多了），這時(shí)候再用短連接的方式，效率太低下了（因?yàn)榻?TCP 連接是有“時(shí)間成本”和“CPU成本”），所以，在 HTTP 1.1 中，默認(rèn)采用的是“Keep-Alive”的方式。

6、SSL/TLS協(xié)議的基本運(yùn)行過程

SSL/TLS協(xié)議的基本思路是采用公鑰加密法，也就是說，客戶端先向服務(wù)器端索要公鑰，然后用公鑰加密信息，服務(wù)器收到密文后，用自己的私鑰解密，但是這里有兩個(gè)問題：

（1）、如何保證公鑰不被篡改？

解決方法：將公鑰放在數(shù)字證書中，只要證書是可信的，公鑰就是可信的。

（2）、公鑰加密計(jì)算量太大，如何減少耗用的時(shí)間？

解決方法：每一次對(duì)話（session），客戶端和服務(wù)器端都生成一個(gè)"對(duì)話密鑰"（session key），用它來加密信息。由于"對(duì)話密鑰"是對(duì)稱加密，所以運(yùn)算速度非常快，而服務(wù)器公鑰只用于加密"對(duì)話密鑰"本身，這樣就減少了加密運(yùn)算的消耗時(shí)間。

因此，SSL/TLS協(xié)議的基本過程是這樣的：

（1）、客戶端向服務(wù)器端索要并驗(yàn)證公鑰。

（2）、雙方協(xié)商生成“對(duì)話密鑰”。

（3）、雙方采用“對(duì)話密鑰”進(jìn)行加密通信。

7、SSL、HTTP和HTTPS協(xié)議的聯(lián)系

SSL是Netscape公司所提出的安全保密協(xié)議，在瀏覽器(如Internet Explorer、Netscape Navigator)和Web服務(wù)器(如Netscape的Netscape Enterprise Server、ColdFusion Server等等)之間構(gòu)造安全通道來進(jìn)行數(shù)據(jù)傳輸，SSL運(yùn)行在TCP/IP層之上、應(yīng)用層之下，為應(yīng)用程序提供加密數(shù)據(jù)通道，它采用了RC4、MD5 以及RSA等加密算法，使用40位的密鑰，適用于商業(yè)信息的加密。

同時(shí)，Netscape公司相應(yīng)開發(fā)了HTTPS協(xié)議并內(nèi)置于其瀏覽器中，HTTPS實(shí)際上就是SSL over HTTP，它使用默認(rèn)端口443，而不是像HTTP那樣使用端口80來和TCP/IP進(jìn)行通信。HTTPS協(xié)議使用SSL在發(fā)送方把原始數(shù)據(jù)進(jìn)行加密，然后在接受方進(jìn)行解密，加密和解密需要發(fā)送方和接受方通過交換共知的密鑰來實(shí)現(xiàn)，因此，所傳送的數(shù)據(jù)不容易被網(wǎng)絡(luò)黑客截獲和解密。

然而，加密和解密過程需要耗費(fèi)系統(tǒng)大量的開銷，嚴(yán)重降低機(jī)器的性能，相關(guān)測(cè)試數(shù)據(jù)表明使用HTTPS協(xié)議傳輸數(shù)據(jù)的工作效率只有使用HTTP協(xié)議傳輸?shù)氖种弧?/p>

假如為了安全保密，將一個(gè)網(wǎng)站所有的Web應(yīng)用都啟用SSL技術(shù)來加密，并使用HTTPS協(xié)議進(jìn)行傳輸，那么該網(wǎng)站的性能和效率將會(huì)大大降低，而且沒有這個(gè)必要，因?yàn)橐话銇碚f并不是所有數(shù)據(jù)都要求那么高的安全保密級(jí)別，所以，我們只需對(duì)那些涉及機(jī)密數(shù)據(jù)的交互處理使用HTTPS協(xié)議，這樣就做到魚與熊掌兼得（具體可查看馬海祥博客《從SEO的角度來分析網(wǎng)站是否該采用HTTPS協(xié)議》的相關(guān)介紹）。

總之不需要用https的地方，就盡量不要用。

8、HTTPS協(xié)議的需求是什么？

花了好多口水，終于把背景知識(shí)說完了，下面正式進(jìn)入正題，先來說說當(dāng)初設(shè)計(jì)HTTPS是為了滿足哪些需求？

很多介紹 HTTPS 的文章一上來就給你講實(shí)現(xiàn)細(xì)節(jié)，對(duì)此，馬海祥覺得這是不好的做法，一上來就給你講協(xié)議細(xì)節(jié)，你充其量只能知道如何做，無法理解為什么，我在前一個(gè)章節(jié)講了“背景知識(shí)”，在這個(gè)章節(jié)講了“需求”，這就有助于你理解了。

為什么要設(shè)計(jì)成這樣？——這就是 WHY 型的問題。

（1）、兼容性

因?yàn)槭窍扔?HTTP 再有 HTTPS，所以，HTTPS 的設(shè)計(jì)者肯定要考慮到對(duì)原有 HTTP 的兼容性。

這里所說的兼容性包括很多方面，比如已有的 Web 應(yīng)用要盡可能無縫地遷移到 HTTPS；比如對(duì)瀏覽器廠商而言，改動(dòng)要盡可能小。

基于“兼容性”方面的考慮，很容易得出如下幾個(gè)結(jié)論：

①、HTTPS還是要基于 TCP 來傳輸

如果改為 UDP 作傳輸層，無論是 Web 服務(wù)端還是瀏覽器客戶端，都要大改，動(dòng)靜太大了。

②、單獨(dú)使用一個(gè)新的協(xié)議，把 HTTP 協(xié)議包裹起來

所謂的“HTTP over SSL”，實(shí)際上是在原有的 HTTP 數(shù)據(jù)外面加了一層 SSL 的封裝，HTTP 協(xié)議原有的 GET、POST 之類的機(jī)制，基本上原封不動(dòng)。

打個(gè)比方：如果原來的 HTTP 是塑料水管，容易被戳破；那么如今新設(shè)計(jì)的 HTTPS 就像是在原有的塑料水管之外，再包一層金屬水管，一來，原有的塑料水管照樣運(yùn)行；二來，用金屬加固了之后，不容易被戳破。

（2）、可擴(kuò)展性

前面說了，HTTPS 相當(dāng)于是“HTTP over SSL”。

如果 SSL 這個(gè)協(xié)議在“可擴(kuò)展性”方面的設(shè)計(jì)足夠牛逼，那么它除了能跟 HTTP 搭配，還能夠跟其它的應(yīng)用層協(xié)議搭配，豈不美哉？

現(xiàn)在看來，當(dāng)初設(shè)計(jì) SSL 的人確實(shí)比較牛，如今的 SSL/TLS 可以跟很多常用的應(yīng)用層協(xié)議（比如：FTP、SMTP、POP、Telnet）搭配，來強(qiáng)化這些應(yīng)用層協(xié)議的安全性。

接著剛才打的比方：如果把 SSL/TLS 視作一根用來加固的金屬管，它不僅可以用來加固輸水的管道，還可以用來加固輸煤氣的管道。

（3）、保密性（防泄密）

HTTPS需要做到足夠好的保密性。

說到保密性，首先要能夠?qū)剐崽剑ㄐ性捊?Sniffer），所謂的“嗅探”，通俗而言就是監(jiān)視你的網(wǎng)絡(luò)傳輸流量，如果你使用明文的 HTTP 上網(wǎng)，那么監(jiān)視者通過嗅探，就知道你在訪問哪些網(wǎng)站的哪些頁面。

嗅探是最低級(jí)的攻擊手法，除了嗅探，HTTPS 還需要能對(duì)抗其它一些稍微高級(jí)的攻擊手法——比如“重放攻擊”（后面講協(xié)議原理的時(shí)候，會(huì)再聊）。

（4）、完整性（防篡改）

除了“保密性”，還有一個(gè)同樣重要的目標(biāo)是“確保完整性”。

在發(fā)明 HTTPS 之前，由于 HTTP 是明文的，不但容易被嗅探，還容易被篡改。

舉個(gè)例子：比如咱們的網(wǎng)絡(luò)運(yùn)營(yíng)商（ISP）都比較流氓，經(jīng)常有網(wǎng)友抱怨說訪問某網(wǎng)站（本來是沒有廣告的），竟然會(huì)跳出很多中國(guó)電信的廣告，為啥會(huì)這樣呢？因?yàn)槟愕木W(wǎng)絡(luò)流量需要經(jīng)過 ISP 的線路才能到達(dá)公網(wǎng)，如果你使用的是明文的 HTTP，ISP 很容易就可以在你訪問的頁面中植入廣告。

所以，當(dāng)初設(shè)計(jì) HTTPS 的時(shí)候，還有一個(gè)需求是“確保 HTTP 協(xié)議的內(nèi)容不被篡改”。

（5）、真實(shí)性（防假冒）

在談到 HTTPS 的需求時(shí)，“真實(shí)性”經(jīng)常被忽略，其實(shí)“真實(shí)性”的重要程度不亞于前面的“保密性”和“完整性”。

舉個(gè)例子：你因?yàn)槭褂镁W(wǎng)銀，需要訪問該網(wǎng)銀的 Web 站點(diǎn)，那么，你如何確保你訪問的網(wǎng)站確實(shí)是你想訪問的網(wǎng)站？

有些天真的同學(xué)會(huì)說：通過看網(wǎng)址里面的域名，來確保，為啥說這樣的同學(xué)是“天真的”？因?yàn)?DNS 系統(tǒng)本身是不可靠的（尤其是在設(shè)計(jì) SSL 的那個(gè)年代，連 DNSSEC 都還沒發(fā)明），由于 DNS 的不可靠（存在“域名欺騙”和“域名劫持”），你看到的網(wǎng)址里面的域名未必是真實(shí)滴！

所以，HTTPS 協(xié)議必須有某種機(jī)制來確保“真實(shí)性”的需求（至于如何確保，后面會(huì)細(xì)聊）。

9、HTTPS和HTTP的區(qū)別

超文本傳輸協(xié)議HTTP協(xié)議被用于在Web瀏覽器和網(wǎng)站服務(wù)器之間傳遞信息，HTTP協(xié)議以明文方式發(fā)送內(nèi)容，不提供任何方式的數(shù)據(jù)加密，如果攻擊者截取了Web瀏覽器和網(wǎng)站服務(wù)器之間的傳輸報(bào)文，就可以直接讀懂其中的信息，因此HTTP協(xié)議不適合傳輸一些敏感信息，比如信用卡號(hào)、密碼等。

為了解決HTTP協(xié)議的這一缺陷，需要使用另一種協(xié)議：安全套接字層超文本傳輸協(xié)議HTTPS。

為了數(shù)據(jù)傳輸?shù)陌踩琀TTPS在HTTP的基礎(chǔ)上加入了SSL協(xié)議，SSL依靠證書來驗(yàn)證服務(wù)器的身份，并為瀏覽器和服務(wù)器之間的通信加密。

一般來說，HTTPS和HTTP的區(qū)別主要為以下四點(diǎn)：

（1）、https協(xié)議需要到ca申請(qǐng)證書，一般免費(fèi)證書很少，需要交費(fèi)。

（2）、http是超文本傳輸協(xié)議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協(xié)議。

（3）、http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。

（4）、http的連接很簡(jiǎn)單，是無狀態(tài)的；HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比http協(xié)議安全（具體可查看馬海祥博客《HTTP與HTTPS的區(qū)別》的相關(guān)介紹）。

10、HTTPS和HTTP的性能比較

再來說最后一個(gè)需求——性能。

本來簡(jiǎn)單的http協(xié)議，一個(gè)get一個(gè)response，由于https要還密鑰和確認(rèn)加密算法的需要，單握手就需要6、7個(gè)往返，任何應(yīng)用中，過多的round trip肯定影響性能，接下來才是具體的http協(xié)議，每一次響應(yīng)或者請(qǐng)求，都要求客戶端和服務(wù)端對(duì)會(huì)話的內(nèi)容做加密/解密。

盡管對(duì)稱加密/解密效率比較高，可是仍然要消耗過多的CPU，為此有專門的SSL芯片，如果CPU信能比較低的話，肯定會(huì)降低性能，從而不能serve更多的請(qǐng)求，加密后數(shù)據(jù)量的影響，所以，才會(huì)出現(xiàn)那么多的安全認(rèn)證提示（具體可查看馬海祥博客《HTTPS對(duì)網(wǎng)站性能優(yōu)化的影響》的相關(guān)介紹）。

一般來說，引入HTTPS之后，不能導(dǎo)致性能變得太差，否則的話，誰還愿意用？

為了確保性能，SSL 的設(shè)計(jì)者至少要考慮如下幾點(diǎn)：

（1）、如何選擇加密算法（“對(duì)稱”or“非對(duì)稱”）？

（2）、如何兼顧 HTTP 采用的“短連接”TCP 方式？

SSL 是在1995年之前開始設(shè)計(jì)的，那時(shí)候的 HTTP 版本還是 1.0，默認(rèn)使用的是“短連接”的 TCP 方式——默認(rèn)不啟用 Keep-Alive。

HTTPS的關(guān)鍵性能影響是CPU和往返，如果CPU很強(qiáng)的話，性能可能就是有人講的80%；如果cpu是瓶頸的話，有人講原來可以server330-500個(gè)請(qǐng)求每秒，現(xiàn)在只有30-50%，因此在使用https請(qǐng)求數(shù)據(jù)的時(shí)候要注意看看你的項(xiàng)目里面是否真的需要。

什么是SSL加密，什么是TLS加密

SSL加密是Netscape公司所提出的安全保密協(xié)議，在瀏覽器和Web服務(wù)器之間構(gòu)造安全通道來進(jìn)行數(shù)據(jù)傳輸，SSL運(yùn)行在TCP/IP層之上、應(yīng)用層之下，為應(yīng)用程序提供加密數(shù)據(jù)通道，它采用了RC4、MD5以及RSA等加密算法，使用40 位的密鑰，適用于商業(yè)信息的加密。

TLS是安全傳輸層協(xié)議。安全傳輸層協(xié)議（TLS）用于在兩個(gè)通信應(yīng)用程序之間提供保密性和數(shù)據(jù)完整性。該協(xié)議由兩層組成： TLS 記錄協(xié)議（TLS Record）和 TLS 握手協(xié)議（TLS Handshake）。較低的層為 TLS 記錄協(xié)議，位于某個(gè)可靠的傳輸協(xié)議上面。

擴(kuò)展資料：

SSL加密并不保護(hù)數(shù)據(jù)中心本身，而是確保了SSL加密設(shè)備的數(shù)據(jù)中心安全，可以監(jiān)控企業(yè)中來往于數(shù)據(jù)中心的最終用戶流量。

從某個(gè)角度來看，數(shù)據(jù)中心管理員可以放心將加密裝置放在某個(gè)地方，需要使用時(shí)再進(jìn)行應(yīng)用，數(shù)據(jù)中心應(yīng)該會(huì)有更合理的方法來應(yīng)對(duì)利用SSL的惡意攻擊，需要找到SSL加密應(yīng)用的最佳實(shí)踐。

TLS協(xié)議是可選的，必須配置客戶端和服務(wù)器才能使用。主要有兩種方式實(shí)現(xiàn)這一目標(biāo)：一個(gè)是使用統(tǒng)一的TLS協(xié)議通信端口（例如：用于HTTPS的端口443）。另一個(gè)是客戶端請(qǐng)求服務(wù)器連接到TLS時(shí)使用特定的協(xié)議機(jī)制（例如：郵件、新聞協(xié)議和STARTTLS）。

一旦客戶端和服務(wù)器都同意使用TLS協(xié)議，他們通過使用一個(gè)握手過程協(xié)商出一個(gè)有狀態(tài)的連接以傳輸數(shù)據(jù)。通過握手，客戶端和服務(wù)器協(xié)商各種參數(shù)用于創(chuàng)建安全連接。

參考資料來源：百度百科-SSL加密技術(shù)

參考資料來源：百度百科-TLS

網(wǎng)頁名稱：服務(wù)器信息安全保密協(xié)議 服務(wù)器數(shù)據(jù)保密
網(wǎng)站網(wǎng)址：http://www.chinadenli.net/article12/ddohhgc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供App開發(fā)、自適應(yīng)網(wǎng)站、移動(dòng)網(wǎng)站建設(shè)、用戶體驗(yàn)、網(wǎng)頁設(shè)計(jì)公司、搜索引擎優(yōu)化

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)