網(wǎng)絡(luò)傳輸安全問題分析

一直知道http協(xié)議是不安全的明文數(shù)據(jù)惜浅，https是基于ssl加密的安全的通信方式税稼。但是后來又知道了https也可以抓包身害，也就是說并不是絕對安全的，但是沒有仔細(xì)研究澈缺。直到前陣子打算自己寫個升級后臺坪创，第一關(guān)就是服務(wù)器安全和權(quán)限控制，才去深入地了解一下網(wǎng)絡(luò)安全這塊的內(nèi)容姐赡，在此記錄一下自己的理解方式莱预。

我們知道信息安全大致可以分為存儲安全、使用安全项滑、傳輸安全依沮，其中傳輸安全是面臨威脅最直接的一種。因為在信息傳輸過程中枪狂，信息交換雙方是開放的 危喉、傳輸?shù)逆溌肥遣淮_定的、雙方的身份也是未知的州疾，非常容易遭受各種形式的攻擊辜限。比如，信息竊取孝治，信息篡改列粪，身份偽裝（也叫中間人攻擊 Middle Attack）等，接下來我們從最原始的通信模式開始谈飒，通過安全威脅的方式及其解決辦法的展開討論，來解釋HTTPS通信過程和安全方案态蒂。

1.明文傳輸

服務(wù)器和客戶端都以明文的方式進(jìn)行通信杭措。

明文傳輸模式

明文傳輸模式，數(shù)據(jù)一旦在鏈路上被人截取钾恢，比如通過代理的模式手素，信息直接就泄露了，并且還可能被篡改瘩蚪。

明文傳輸漏洞

所以我們需要對明文進(jìn)行加密泉懦。

2.對稱加密

對稱加密即加密和解密使用同一個秘鑰，常見的對稱加密有DES疹瘦、DES3算法等崩哩，其示意圖如下

對稱加密示意

3.對稱加密傳輸

服務(wù)器和客戶端要進(jìn)行對稱加密方式的密文通信，首先要交換加密秘鑰，否則另外一方無法解密信息邓嘹。

對稱加密傳輸

在這種模式下面酣栈，雖然之后的信息交換是以加密的方式進(jìn)行的，但是在秘鑰交換的時候汹押，必須是明文的矿筝，一旦秘鑰被竊取，后續(xù)的加密數(shù)傳輸棚贾，也就等同于明文傳輸了窖维，如下：

對稱加密傳輸漏洞

4.非對稱加密

對稱加密方式，無法解決秘鑰傳輸問題妙痹，也因此無法滿足信息加密傳輸?shù)男枨蟪氯瑁院髞砻艽a學(xué)上又發(fā)展出了非對稱加密算法。在非對稱加密算法中细诸，加密和解密使用不同的秘鑰沛贪，用其中一個秘鑰加密的數(shù)據(jù)，只能用另外一個解密震贵。這種特性利赋，使得其中一個秘鑰可以對外公開，也稱作公鑰猩系，另一個就稱作私鑰媚送。信息經(jīng)過公鑰加密躁愿，只有私鑰持有者才解密厕妖，這樣就解決了秘鑰傳輸?shù)膯栴}。對稱加密的過程如下：

非對稱加密示意

5.單向非對稱加密傳輸

為了解決對稱加密傳輸中易稠，秘鑰公開傳輸帶來的安全漏洞拿霉，我們采用非對稱加密算法對信息進(jìn)行加密后傳輸吟秩。先考慮只有一端有非對稱加密的情況，比如服務(wù)端绽淘，那么傳輸?shù)倪^程如下涵防。

單項非對稱加密示意

可以看到，為了讓客戶端能夠理解服務(wù)端返回的信息沪铭，服務(wù)端必須要使用私鑰對返回的信息進(jìn)行加密壮池，因為服務(wù)端的公鑰是明文傳輸?shù)模?wù)端返回的數(shù)據(jù)是可以被解密和竊取的杀怠，過程如下：

單項非對稱加密傳輸漏洞

在因為服務(wù)端的公鑰是可以獲取的椰憋，所以服務(wù)端返回的數(shù)據(jù)，如果用自己的私鑰加密和明文傳輸是沒有區(qū)別的赔退。如果在客戶端對數(shù)據(jù)進(jìn)行加密橙依，所面臨的問題也是一樣的，所以單向非對稱加密只能滿足單向加密傳輸?shù)男枨蟆?/p>

6.雙向非對稱加密

假如通信雙方都各持有一對加密秘鑰，并要求接收的數(shù)據(jù)都使用自己公鑰進(jìn)行加密票编，那么就形成了雙向非對稱加密褪储。

雙向非對稱加密示意

在這種通信模式下，即使雙方的公鑰和加密信息被第三者攔截慧域，因為第三者沒有私鑰鲤竹，因此不會造成信息泄露，至此我們徹底解決了信息竊取的安全問題昔榴。但是辛藻，是否這種傳輸模式已經(jīng)沒有問題了呢，并非如此互订。我們從一開始到現(xiàn)在討論的都是信息竊取的問題吱肌，這種模式雖然已經(jīng)解決了這個問題，但是并沒有解決身份偽裝的問題仰禽。比如氮墨，假如一開始服務(wù)器通信的就是第三方偽裝的客戶端，那么通信過程就依然完全暴露在第三方的視野中吐葵，如下:

雙向非對稱加密通信問題

同樣规揪，客戶端可能遭遇第三者偽裝的服務(wù)端的釣魚通信。

7. 身份證明問題

現(xiàn)在我們知道通信雙方都需要一種方法温峭，能夠證明自己的身份猛铅，來解決第三者偽裝攻擊的問題。那么有沒有這種辦法或者技術(shù)手段呢凤藏，這貌似無從下手奸忽。

我們來抽象一下問題，假如A與B要進(jìn)行通信揖庄，B具有不確定性栗菜，即任何能夠證明自己身份合法的對象，都可以與A通信抠艾。因此A事先對于B的身份沒有任何已知的信息苛萎，完全依賴B在通信時提供的憑證F。那么問題變成了：提供怎樣的憑證F能夠證明B是合法的呢检号？

假設(shè)憑證F要求包含最小的信息集合為F={F1,F2,F3,...,Fn},我們要求對于任意 Fi 屬于 F都是合法的就可以證明F合法。那么怎么證明信息Fi是合法的呢蛙酪？答案是無解齐苛。因為A對B沒有任何已知的信息，即使F1再進(jìn)行拆分桂塞，它依賴的信息凹蜂，依然無法形成憑證，只能將證明問題進(jìn)行轉(zhuǎn)移。因此無論提供怎樣的憑證F玛痊，都無法讓B直接對A證明自身的合法汰瘫。

因此我們需要引入一個A信賴的第三方作為公證，來驗證B的身份擂煞。因為這個A是抽象的通信端混弥，因此A的問題B也同樣需要解決，那么這個第三方公證对省，需要被AB同時信任蝗拿。

8. 即時公證的雙向非對稱加密傳輸

在即時公正的雙向非對稱加密傳輸過程中，通信雙方要事先在公正方處進(jìn)行身份和公鑰注冊蒿涎。在通信開始之前哀托，通信雙方首先要與公正方交換公鑰，以便后續(xù)加密認(rèn)證過程劳秋，其次請求雙方的公鑰和身份信息仓手，然后申請公證，如果公證成功玻淑，則認(rèn)可對方的公鑰嗽冒，后續(xù)使用公鑰進(jìn)行雙方通信。

公證雙向非對稱加密傳輸

到此為止岁忘，通信模式好像接近完善了辛慰，但是其實還有幾個問題：

（1）公證方身份偽裝問題

通信雙方和公正方依然存在公鑰交換過程，也就是公正方也可能是偽裝的干像，所謂的身份認(rèn)證問題帅腌，只是從認(rèn)證通信對方，轉(zhuǎn)移到了認(rèn)證公正方這里麻汰，并沒有得到解決速客，示意如下:

公正方偽裝漏洞

既然這個問題是由公正方與通信方的公鑰交換引起的，那我們是否可以取消這個過程呢?答案是肯定的,因為公正方本身就需要是一個權(quán)威的機構(gòu)五鲫，而不像通信方一樣具有不確定性溺职。事實上，現(xiàn)在的瀏覽器和服務(wù)端程序位喂，都內(nèi)置了公正方的信息浪耘，或者依賴系統(tǒng)信任的公正方的信息。

這里會有一個潛在的問題塑崖，假如這些內(nèi)置的信息七冲，被篡改了，那么身份偽裝是不是就依然可行了呢规婆？是這樣的澜躺，所謂的https抓包正是基于這個原理蝉稳，但是這并不代表https是不安全的通信協(xié)議，因為瀏覽器和服務(wù)器系統(tǒng)的通信證書是可以管控的掘鄙，正常用戶使用的客戶端耘戚，肯定依賴的是正確的公正方信息，那么在這個條件下操漠，通信的過程就是安全的收津。請注意，這里有兩個對象颅夺，容易讓人混淆朋截。我們說安全是針對正常的用戶而言的，而通信模式漏洞吧黄，是在惡意攻擊情況下部服，針對通信端程序而言的，因此在網(wǎng)絡(luò)通信程序的設(shè)計上拗慨，不能夠因為使用了HTTPS廓八，而對通信安全掉以輕心，還是要做好數(shù)據(jù)審查和權(quán)限管理赵抢。

（2） 即時公證的并發(fā)和成本問題

公正方在通信過程中剧蹂，承擔(dān)了中間人的角色，在真實的網(wǎng)絡(luò)請求中烦却，會遇到并發(fā)和成本問題宠叼。因此我們考慮將依賴公正方的即時的認(rèn)證過程，變成通信雙方的離線的校驗過程其爵。那么怎么設(shè)計呢冒冬？

在即時公正的模式下，通信雙方的認(rèn)證信息是存儲在公正方這里的摩渺，這是導(dǎo)致需要實時訪問的根本原因简烤。那么我們能不能將身份信息，加以處理摇幻，帶上我們公證方的認(rèn)證結(jié)果横侦，做成憑據(jù)，再還給通信方绰姻，只要提供這個憑據(jù)就對方就能通過認(rèn)證呢枉侧。

那么這個憑據(jù)要求：

• 包含了公正方和注冊方的身份信息
• 能夠證明是公正方頒布，而無法偽造
• 頒布之后狂芋，憑證的內(nèi)容無法修改

這個公正方叫做CA機構(gòu)棵逊，而這個憑據(jù)就叫CA證書。

（3）加密效率問題

非對稱加密雖然能解決秘鑰傳輸問題银酗，單它有個弊端辆影，就是加解密計算量大，效率低黍特。因此不適用于頻繁的蛙讥、大數(shù)據(jù)量的信息交換。因此我們在完成身份認(rèn)證之后灭衷，不能一直使用非對稱加密進(jìn)行通信次慢，而是協(xié)商一個堆成加密的秘鑰，使用對稱加密交換信息翔曲。

HTTPS通信原理介紹

待續(xù)迫像。