在一次網絡通信或者是進程通信中,如果傳輸數據采用明文的方式,那么很容易被第三方"竊聽"到,安全性難以保障。
而所謂加密是讓數據從明文變成密文,傳輸過程中是密文,傳送過去之后對方接收到的也是密文?!梢岳斫鉃槊芪木褪莵y碼,看不出內在的任何意義,通常也都是逐位對應的。
在接收方接收到密文之后只有把它還原為原來的樣子才可以理解對方說的具體是什么,此過程就叫做解密。
所謂系統的安全要實現的目標應該包括:機密性-confidentiality,完整性-integrity 和可用性-availability;在通信中威脅到上述三者的***行為分別有:
1.威脅機密性的***行為:竊聽、嗅探、掃描、通信量分析
2.威脅完整性的***行為:更改、偽裝、重放、否認
3.威脅可用性的***行為: 拒絕服務(DoS)
針對各種威脅安全性***行為,我們分別從技術層面和服務層面出發,有不同的解決方案。
技術:數據的加密和解密;服務:安全服務;
今天來初探Linux世界里的加密和解密是怎么一回事;
加密需要兩個東西,算法+密鑰;
加密的算法分為四類:
對稱加密算法-通俗的說就是 用什么密鑰加密就用同一個密鑰進行解密;
其優勢所在就是加密速度較快;但劣勢也非常明顯:
對稱加密無法保證完整性。被截獲了,隨破解不出來里面的密文是什么,但是,截獲者插入一些字符篡改內容,再發送給接收者;接收者在接收到被篡改的密文以后,解密出來,發現內容似乎沒有什么意義,此時,怎樣確定此密文就是自己信任的對方發送過來的呢?所以完整性是無法得到保證的。
這種算法的主流算法有:DES,AES,3DES等等;
公鑰加密算法-采用公鑰加密,私鑰解密;
公鑰加密也叫做非對稱加密,加密解密采用同一組的公鑰和私鑰。
先來解釋一下什么是公鑰私鑰:
私鑰(seceret key|private key):是通過特定的工具創建生成;由使用者自己留存。務必保證其私密性;
公鑰(public key):從私鑰中提取生成,可以公開給所有人使用;
這種方式加密的數據安全等級高,代價就是密鑰很長,從512位、768位、1024位、2048位、4096位、8192位不等;由此也對系統的性能提出了更高的要求,例如此種加密技術的RSA的發展似乎遇到了瓶頸。因此,很少用公鑰加密算法來加密大批量的數據;
單項加密算法 - 提取數據特征碼,只能由明文計算出密文,也就是只可加密不能解密;
因此此種算法的功能就是保證數據的完整性,防止被篡改;
常見的算法:md5、SHA1(安全hash算法)、SHA2、SHA256、SHA512、SHA3(目前最新的)
密鑰加密算法-IKE
所謂IKE:
1、IPsec使用IKE來完成對等體之間的認證和密鑰的生成以及交換
2、協商和維護安全關聯(SA)參數
3、SA是一個集合,包含了加密算法,認證方式等等
4、通過認證,防止偽裝***
5、自動產生密鑰,并自動更新密鑰
6、動態,安全的交換密鑰
在實際應用里,通信雙方數據加密進行以下步驟:
1.通信雙方互相交換證書,并到信任的CA進行證書驗證;
2.發送方使用某種對稱加密算法對數據進行加密;對加密后的數據使用單向加密,計算其特征值;發送方再用自己的私鑰加密此特征值,以證明數據來源的可靠;發送方使用接收方的證書加密對稱密鑰;
3.接收方在收到數據后,先使用自己的私鑰解密對此密鑰;然后使用發送方的公鑰特征值,再利用相同的單向加密算法;
不使用SSL/TLS的HTTP通信,就是不加密的通信。所有信息明文傳播,帶來了三大風險。
(1)竊聽風險(eavesdropping):第三方可以獲知通信內容。
(2)篡改風險(tampering):第三方可以修改通信內容。
(3)冒充風險(pretending):第三方可以冒充他人身份參與通信。
SSL/TLS協議是為了解決這三大風險而設計的,希望達到:
(1)所有信息都是加密傳播,第三方無法竊聽。
(2)具有校驗機制,一旦被篡改,通信雙方會立刻發現。
(3)配備×××書,防止身份被冒充。
SSL/TLS協議的基本思路是采用公鑰加密法,也就是說,客戶端先向服務器端索要公鑰,然后用公鑰加密信息,服務器收到密文后,用自己的私鑰解密。
它將將公鑰放在數字證書中。只要證書是可信的,公鑰就是可信的。這樣保證了公鑰不會被篡改;
數字證書里包含的內容:
擁有者的名稱
擁有者所提交的公鑰
有效期
證書的版本號
證書的序列號
簽發算法ID
簽發CA的名稱
主體名稱
發證者唯一標識
發證者的數字簽名
擴展信息
因此,SSL/TLS協議的基本過程是這樣的:
(1) 客戶端向服務器端索要并驗證公鑰。
(2) 雙方協商生成"對話密鑰"。
(3) 雙方采用"對話密鑰"進行加密通信。
前兩步也叫握手階段 - handshake
SSL/TSL的handshake的四個階段:
1.客戶端向服務器索要證書并驗證;
client_hello發送的信息內容:
支持的協議版本,如:TLS V1.2...
客戶端生成的隨機數,可能在之后充當加密的密鑰;
支持的加密算法,如AES,sha...
協商各自支持的壓縮算法。非必
2.雙方協商生成會話密鑰;dh算法交換密鑰
Server_hello的內容:
確認使用的加密協議的版本號。
服務器生成一個隨機數,稍后用于生成會話密鑰
確認加密算法及壓縮算法;
3.雙方采用生成的會話密鑰進行安全加密的通信;
客戶端驗證服務器證書,在確認無誤后,取出其公鑰;
驗證服務器證書需要驗證下述內容:
驗證發證機構CA;
驗證證書的完整性;
驗證證書的持有者信息;
驗證證書的有效期
驗證證書的吊銷列表;
客戶端發送信息給服務器:
1.一個隨機數,用于服務器上的公鑰加密
2.編碼格式變更的通知,表示隨后的信息都將用雙方已經協商好的加密算法和密鑰進行加密發送;
客戶端握手結束;
4.雙方互相通告握手結束的信息;
服務器會收到客戶端發送來的此次握手階段的第三個隨機數 Pre-Master_key
計算本次會話所用到的會話密鑰,向客戶端發送相關信息;
編碼變更通知,表示隨后的信息都將用雙方已經協商好的加密算法和密鑰進行加密發送;
服務器端握手結束;
接下來,客戶端與服務器進入加密通信,就完全是使用普通的HTTP協議,只不過用"會話密鑰"加密內容。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。