
- 網路安全教程
- 網路安全 - 首頁
- 網路安全 – 概述
- 網路安全 – 應用層
- 網路安全 – 傳輸層
- 網路安全 – 網路層
- 網路安全 – 資料鏈路層
- 網路安全 – 訪問控制
- 網路安全 – 防火牆
- 網路安全 – 至關重要
- 零信任安全
- 零信任安全 - 簡介
- 零信任安全模型
- 零信任架構
- 網路安全有用資源
- 網路安全 - 快速指南
- 網路安全 - 有用資源
- 網路安全 - 討論
網路安全 – 傳輸層
網路安全是指在資料在網路上傳輸過程中保護資料免受攻擊。為了實現這一目標,已經設計了許多即時安全協議。即時網路安全協議有一些流行的標準,例如 S/MIME、SSL/TLS、SSH 和 IPsec。如前所述,這些協議在網路模型的不同層工作。
在上一章中,我們討論了一些旨在提供應用層安全性的流行協議。在本章中,我們將討論在傳輸層實現網路安全的過程以及相關的安全協議。
對於基於 TCP/IP 協議的網路,物理層和資料鏈路層通常在使用者終端和網絡卡硬體中實現。TCP 和 IP 層在作業系統中實現。TCP/IP 上面的任何內容都作為使用者程序實現。
傳輸層安全的需求
讓我們討論一個典型的基於網際網路的商業交易。
Bob 訪問 Alice 的商品銷售網站。在網站上的表單中,Bob 輸入所需的商品型別和數量、他的地址和支付卡詳細資訊。Bob 點選提交併等待商品交付,同時從他的賬戶中扣除價格金額。這一切聽起來都很好,但在沒有網路安全的情況下,Bob 可能會遇到一些意外。
如果交易未使用機密性(加密),攻擊者可以獲取他的支付卡資訊。然後,攻擊者可以以 Bob 的名義進行購買。
如果未使用資料完整性措施,攻擊者可以修改 Bob 的訂單,包括商品型別或數量。
最後,如果未使用伺服器身份驗證,伺服器可能會顯示 Alice 的著名徽標,但該站點可能是由偽裝成 Alice 的攻擊者維護的惡意站點。在收到 Bob 的訂單後,他可能會拿走 Bob 的錢並逃跑。或者他可以透過收集 Bob 的姓名和信用卡詳細資訊來進行身份盜竊。
傳輸層安全方案可以透過增強基於 TCP/IP 的網路通訊的機密性、資料完整性、伺服器身份驗證和客戶端身份驗證來解決這些問題。
此層面的安全性主要用於保護網路上的基於 HTTP 的 Web 交易。但是,任何透過 TCP 執行的應用程式都可以使用它。
TLS 設計理念
傳輸層安全 (TLS) 協議在 TCP 層之上執行。這些協議的設計使用流行的應用程式程式設計介面 (API) 到 TCP,稱為“套接字”,用於與 TCP 層互動。
應用程式現在與傳輸安全層而不是直接與 TCP 互動。傳輸安全層提供了一個簡單的 API 與套接字,它類似於 TCP 的 API。

在上圖中,儘管 TLS 在技術上位於應用程式和傳輸層之間,但從常見角度來看,它是一個傳輸協議,充當增強了安全服務的 TCP 層。
TLS 旨在在可靠的第 4 層協議 TCP(而不是 UDP 協議)上執行,這使得 TLS 的設計變得簡單得多,因為它不必擔心“超時”和“重傳丟失的資料”。TCP 層照常繼續這樣做,滿足了 TLS 的需求。
為什麼 TLS 受歡迎?
在傳輸層使用安全性的受歡迎程度的原因是其簡單性。在這一層設計和部署安全不需要對在作業系統中實現的 TCP/IP 協議進行任何更改。只需要設計/修改使用者程序和應用程式,這不太複雜。
安全套接字層 (SSL)
在本節中,我們討論為 TLS 設計的協議族。該族包括 SSL 版本 2 和 3 以及 TLS 協議。SSLv2 現已被 SSLv3 取代,因此我們將重點關注 SSL v3 和 TLS。
SSL 的簡史
1995 年,Netscape 開發了 SSLv2 並將其用於 Netscape Navigator 1.1。SSL 版本 1 從未釋出和使用。後來,微軟改進了 SSLv2 並引入了另一個類似的協議,稱為私有通訊技術 (PCT)。
Netscape 在各種安全問題上大幅改進了 SSLv2,並在 1999 年部署了 SSLv3。隨後,網際網路工程任務組 (IETF) 引入了一個類似的 TLS(傳輸層安全)協議作為開放標準。TLS 協議與 SSLv3 不相容。
TLS 修改了用於金鑰擴充套件和身份驗證的加密演算法。此外,TLS 建議使用開放的加密 Diffie-Hellman (DH) 和數字簽名標準 (DSS) 來代替 SSL 中使用的專利 RSA 加密。但由於 RSA 專利於 2000 年到期,因此使用者沒有充分的理由從廣泛部署的 SSLv3 遷移到 TLS。
SSL 的主要特點
SSL 協議的主要特點如下:
SSL 透過以下方式提供網路連線安全性:
機密性 - 資訊以加密形式交換。
身份驗證 - 通訊實體透過使用數字證書相互識別。Web 伺服器身份驗證是強制性的,而客戶端身份驗證是可選的。
可靠性 - 保持訊息完整性檢查。
SSL 可用於所有 TCP 應用程式。
幾乎所有 Web 瀏覽器都支援。
方便與新的線上實體開展業務。
主要為 Web 電子商務而開發。
SSL 的架構
SSL 特定於 TCP,它不適用於 UDP。SSL 為應用程式提供應用程式程式設計介面 (API)。C 和 Java SSL 庫/類隨時可用。
SSL 協議旨在在應用程式和傳輸層之間互操作,如下面的影像所示:

SSL 本身不是影像中所示的單層協議;事實上,它由兩個子層組成。
下層子層包含 SSL 協議的一個元件,稱為 SSL 記錄協議。此元件提供完整性和機密性服務。
上層子層包含三個與 SSL 相關的協議元件和一個應用程式協議。應用程式元件提供客戶端/伺服器互動之間的資訊傳輸服務。從技術上講,它也可以在 SSL 層之上執行。三個與 SSL 相關的協議元件是:
- SSL 握手協議
- 更改密碼規範協議
- 警報協議。
這三個協議管理所有 SSL 訊息交換,並在本節後面進行討論。

SSL 協議元件的功能
SSL 協議的四個子元件處理客戶端計算機和伺服器之間安全通訊的各種任務。
記錄協議
記錄層格式化上層協議訊息。
它將資料分成可管理的塊(最大長度 16 KB)。它可以選擇性地壓縮資料。
加密資料。
為每條訊息提供標題並在末尾提供雜湊值(訊息身份驗證程式碼 (MAC))。
將格式化的塊傳遞給 TCP 層進行傳輸。

SSL 握手協議
它是 SSL 中最複雜的部分。在傳輸任何應用程式資料之前都會呼叫它。它在客戶端和伺服器之間建立 SSL 會話。
會話的建立涉及伺服器身份驗證、金鑰和演算法協商、建立金鑰和客戶端身份驗證(可選)。
會話由一組唯一的加密安全引數標識。
客戶端和伺服器之間的多個安全 TCP 連線可以共享同一個會話。
握手協議透過四個階段進行操作。這些將在下一節中討論。
ChangeCipherSpec 協議
SSL 協議中最簡單的一部分。它包含在兩個通訊實體(客戶端和伺服器)之間交換的單個訊息。
當每個實體傳送 ChangeCipherSpec 訊息時,它會將其連線端更改為已商定的安全狀態。
掛起狀態的密碼引數被複制到當前狀態。
此訊息的交換表示所有將來的資料交換都已加密並受到完整性保護。
SSL 警報協議
此協議用於報告錯誤 - 例如意外訊息、錯誤的記錄 MAC、安全引數協商失敗等。
它也用於其他目的 - 例如通知關閉 TCP 連線、通知收到錯誤或未知證書等。
SSL 會話的建立
如上所述,SSL 會話建立有四個階段。這些主要由 SSL 握手協議處理。
階段 1 - 建立安全功能。
此階段包括交換兩條訊息 - Client_hello 和 Server_hello。

Client_hello 包含客戶端支援的加密演算法列表,按優先順序遞減排序。
Server_hello 包含所選的密碼規範 (CipherSpec) 和新的 session_id。
CipherSpec 包含以下欄位:
密碼演算法 (DES、3DES、RC2 和 RC4)
MAC 演算法(基於 MD5、SHA-1)
公鑰演算法 (RSA)
兩條訊息都具有“隨機數”,以防止重放攻擊。
階段 2 - 伺服器身份驗證和金鑰交換。

伺服器傳送證書。客戶端軟體配置了各種“受信任”組織 (CA) 的公鑰以檢查證書。
伺服器傳送所選的密碼套件。
伺服器可能會請求客戶端證書。通常不會這樣做。
伺服器指示 Server_hello 結束。
階段 3 - 客戶端身份驗證和金鑰交換。

客戶端傳送證書,僅當伺服器請求時。
它還發送使用伺服器的公鑰加密的主金鑰前身 (PMS)。
如果客戶端傳送證書,它還會發送 Certificate_verify 訊息以證明它擁有與此證書關聯的私鑰。基本上,客戶端對之前的訊息的雜湊值進行簽名。
階段 4 - 完成。

客戶端和伺服器相互發送 Change_cipher_spec 訊息,以將掛起的密碼狀態複製到當前狀態。
從現在開始,所有資料都已加密並受到完整性保護。
來自每一端的“Finished”訊息驗證金鑰交換和身份驗證過程是否成功。
上述所有四個階段都發生在 TCP 會話建立期間。SSL 會話建立在 TCP SYN/SYNACK 之後開始,在 TCP Fin 之前結束。
恢復斷開的會話
如果客戶端使用加密的 session_id 資訊向伺服器傳送 hello_request,則可以恢復斷開的會話(透過 Alert 訊息)。
然後,伺服器確定 session_id 是否有效。如果驗證有效,它會與客戶端交換 ChangeCipherSpec 和 finished 訊息,並恢復安全通訊。
這避免了重新計算會話密碼引數,並節省了伺服器和客戶端端的計算量。
SSL 會話金鑰
我們已經看到,在 SSL 會話建立的第 3 階段,客戶端會發送主金鑰前身,使用伺服器的公鑰加密。主金鑰和各種會話金鑰的生成方式如下:
主金鑰是使用以下方法生成的(透過偽隨機數生成器):
主金鑰前身。
客戶端 hello 和伺服器 hello 訊息中交換了兩個隨機數(RA 和 RB)。
然後從這個主金鑰派生出六個秘密值,如下所示:
用於 MAC 的金鑰(用於伺服器傳送的資料)
用於 MAC 的金鑰(用於客戶端傳送的資料)
用於加密的金鑰和 IV(由伺服器使用)
用於加密的金鑰和 IV(由客戶端使用)
TLS 協議
為了提供一個開放的網際網路標準的 SSL,IETF 於 1999 年 1 月釋出了傳輸層安全 (TLS) 協議。TLS 在 RFC 5246 中被定義為一個提議的網際網路標準。
主要特點
TLS 協議與 SSL 具有相同的目標。
它使客戶端/伺服器應用程式能夠以安全的方式進行通訊,方法是進行身份驗證、防止竊聽並抵禦訊息修改。
TLS 協議位於網路層堆疊中可靠的面向連線的傳輸 TCP 層之上。
TLS 協議的架構類似於 SSLv3 協議。它有兩個子協議:TLS 記錄協議和 TLS 握手協議。
雖然 SSLv3 和 TLS 協議具有相似的架構,但在架構和功能上,特別是對於握手協議,進行了一些更改。
TLS 和 SSL 協議的比較
TLS 和 SSLv3 協議之間主要有八個區別。如下所示:
協議版本 - TLS 協議段的頭部攜帶版本號 3.1,以區別於 SSL 協議段頭部攜帶的 3 號。
訊息認證 - TLS 使用帶金鑰的雜湊訊息認證碼 (H-MAC)。好處是 H-MAC 可以與任何雜湊函式一起使用,而不僅僅是 MD5 或 SHA,正如 SSL 協議明確規定的那樣。
會話金鑰生成 - TLS 和 SSL 協議在金鑰材料生成方面有兩個區別。
計算預主金鑰和主金鑰的方法是相似的。但在 TLS 協議中,主金鑰的計算使用 HMAC 標準和偽隨機函式 (PRF) 輸出,而不是臨時 MAC。
計算會話金鑰和初始化向量 (IV) 的演算法在 TLS 中與 SSL 協議不同。
警報協議訊息 -
TLS 協議支援 SSL 的警報協議使用所有訊息,除了無證書警報訊息被認為是冗餘的。如果不需要客戶端身份驗證,則客戶端傳送空證書。
TLS 協議中包含了許多其他警報訊息,用於其他錯誤條件,例如record_overflow、decode_error 等。
支援的密碼套件 - SSL 支援 RSA、Diffie-Hellman 和 Fortezza 密碼套件。TLS 協議支援所有套件,除了 Fortezza。
客戶端證書型別 - TLS 定義了在certificate_request 訊息中請求的證書型別。SSLv3 支援所有這些。此外,SSL 還支援某些其他型別的證書,例如 Fortezza。
CertificateVerify 和 Finished 訊息 -
在 SSL 中,certificate_verify 訊息使用複雜的訊息過程。使用 TLS,已驗證的資訊包含在握手訊息本身中,從而避免了這種複雜的過程。
Finished 訊息在 TLS 和 SSLv3 中以不同的方式計算。
資料的填充 - 在 SSL 協議中,在加密之前新增到使用者資料中的填充是使總資料大小等於密碼塊長度的倍數所需的最小量。在 TLS 中,填充可以是任何導致資料大小為密碼塊長度倍數的量,最多 255 位元組。
TLS 和 SSLv3 協議之間的上述差異在以下表格中進行了總結。

安全瀏覽 - HTTPS
在本節中,我們將討論使用 SSL/TLS 協議執行安全 Web 瀏覽。
HTTPS 定義
超文字傳輸協議 (HTTP) 協議用於 Web 瀏覽。HTTPS 的功能類似於 HTTP。唯一的區別是 HTTPS 提供“安全”的 Web 瀏覽。HTTPS 代表 HTTP over SSL。此協議用於在客戶端 Web 瀏覽器和網站伺服器之間提供加密和身份驗證的連線。

透過 HTTPS 進行的安全瀏覽確保以下內容已加密:
- 請求的網頁的 URL。
- 伺服器提供給使用者客戶端的網頁內容。
- 使用者填寫的表單內容。
- 在兩個方向上建立的 Cookie。
HTTPS 的工作原理
HTTPS 應用協議通常使用兩種流行的傳輸層安全協議之一 - SSL 或 TLS。安全瀏覽過程在以下幾點中進行了描述。
您透過在瀏覽器位址列中輸入 https:// 後跟 URL 來請求到網頁的 HTTPS 連線。
Web 瀏覽器啟動到 Web 伺服器的連線。https 的使用會呼叫 SSL 協議的使用。
應用程式(在本例中為瀏覽器)使用系統埠 443 而不是埠 80(在 http 的情況下使用)。
SSL 協議會經歷一個握手協議以建立安全會話,如前面各節所述。
網站最初會將其 SSL 數字證書傳送到您的瀏覽器。在驗證證書後,SSL 握手將繼續交換會話的共享秘密。
當伺服器使用受信任的 SSL 數字證書時,使用者會在瀏覽器位址列中看到一個掛鎖圖示。當在網站上安裝擴充套件驗證證書時,位址列會變成綠色。

一旦建立,此會話將包含 Web 伺服器和瀏覽器之間許多安全連線。
HTTPS 的用途
HTTPS 的使用為使用者提供機密性、伺服器身份驗證和訊息完整性。它能夠在網際網路上安全地進行電子商務。
防止資料被竊聽並拒絕身份盜竊,這是 HTTP 上常見的攻擊。
當今的 Web 瀏覽器和 Web 伺服器都配備了 HTTPS 支援。但是,與 HTTP 相比,使用 HTTPS 需要客戶端和伺服器端更多的計算能力來執行加密和 SSL 握手。
安全外殼協議 (SSH)
SSH 的主要特點如下:
SSH 是一種在 TCP/IP 層之上執行的網路協議。它旨在取代提供不安全遠端登入功能的 TELNET。
SSH 提供安全客戶端/伺服器通訊,可用於檔案傳輸和電子郵件等任務。
SSH2 是一種流行的協議,它提供了比早期版本 SSH1 更好的網路通訊安全性。
SSH 定義
SSH 組織為三個子協議。

傳輸層協議 - SSH 協議的這部分提供資料機密性、伺服器(主機)身份驗證和資料完整性。它還可以選擇提供資料壓縮。
伺服器身份驗證 - 主機金鑰是不對稱的,如公鑰/私鑰。伺服器使用公鑰向客戶端證明其身份。客戶端驗證聯絡的伺服器是否來自其維護的資料庫中的“已知”主機。一旦伺服器透過身份驗證,就會生成會話金鑰。
會話金鑰建立 - 身份驗證後,伺服器和客戶端就將使用的密碼達成一致。會話金鑰由客戶端和伺服器生成。會話金鑰在使用者身份驗證之前生成,以便可以加密傳送使用者名稱和密碼。這些金鑰通常在會話期間定期更換(例如,每小時一次),並在使用後立即銷燬。
資料完整性 - SSH 使用訊息認證碼 (MAC) 演算法進行資料完整性檢查。這是對 SSH1 使用的 32 位 CRC 的改進。
使用者身份驗證協議 - SSH 的這部分將使用者身份驗證到伺服器。伺服器驗證是否僅授予預期使用者訪問許可權。目前使用多種身份驗證方法,例如鍵入密碼、Kerberos、公鑰身份驗證等。
連線協議 - 這在單個底層 SSH 連線上提供多個邏輯通道。
SSH 服務
SSH 提供三種主要服務,這些服務能夠提供許多安全解決方案。這些服務簡要描述如下:
安全命令外殼(遠端登入) - 它允許使用者編輯檔案、檢視目錄內容和訪問連線裝置上的應用程式。系統管理員可以遠端啟動/檢視/停止服務和程序、建立使用者帳戶以及更改檔案/目錄許可權等。使用安全遠端登入,現在可以從遠端計算機安全地執行機器命令提示符下可行的所有任務。
安全檔案傳輸 - SSH 檔案傳輸協議 (SFTP) 旨在作為 SSH-2 的擴充套件,用於安全檔案傳輸。從本質上講,它是在安全外殼協議之上分層的一個單獨協議,用於處理檔案傳輸。SFTP 加密正在傳輸的使用者名稱/密碼和檔案資料。它使用與安全外殼伺服器相同的埠,即系統埠號 22。
埠轉發(隧道) - 它允許來自不安全的基於 TCP/IP 的應用程式的資料得到保護。設定埠轉發後,安全外殼會重定向來自程式(通常是客戶端)的流量,並將其透過加密隧道傳送到另一側的程式(通常是伺服器)。多個應用程式可以透過單個多路複用安全通道傳輸資料,從而無需在防火牆或路由器上開啟多個埠。

優點和侷限性
在傳輸層採用通訊安全性的優點和侷限性如下:
優點
傳輸層安全性對應用程式是透明的。
伺服器已透過身份驗證。
應用程式層標頭被隱藏。
它比第 3 層 (IPsec) 的安全機制更細粒度,因為它在傳輸連線級別工作。
侷限性
僅適用於基於 TCP 的應用程式(不適用於 UDP)。
TCP/IP 標頭是明文的。
適用於客戶端和伺服器之間的直接通訊。不適用於使用伺服器鏈的安全應用程式(例如電子郵件)
SSL 不提供不可否認性,因為客戶端身份驗證是可選的。
如果需要,需要在 SSL 之上實現客戶端身份驗證。
總結
在過去的十年中,網際網路上出現了大量的 Web 應用程式。許多電子政務和電子商務入口網站已上線。這些應用程式要求伺服器和客戶端之間的會話是安全的,提供會話的機密性、身份驗證和完整性。
在使用者會話期間減輕潛在攻擊的一種方法是使用安全通訊協議。本章討論了兩種此類通訊協議,即安全套接字層 (SSL) 和傳輸層安全 (TLS)。這兩種協議都位於傳輸層。
另一種傳輸層協議,安全外殼 (SSH),旨在取代 TELNET,提供安全的遠端登入功能。它能夠提供各種服務,例如安全命令外殼和 SFTP。
使用傳輸層安全性有很多好處。但是,在這些層設計的安全協議只能與 TCP 一起使用。它們不為使用 UDP 實現的通訊提供安全性。