此文章轉(zhuǎn)載自掘金論壇：https://juejin.cn/post/691532...

在 WebRTC 中辕狰，為了保證媒體傳輸?shù)陌踩郧运撸肓?DTLS 來對通信過程進(jìn)行加密坛善。DTLS 的作用髓迎、原理與 SSL/TLS 類似尘颓，都是為了使得原本不安全的通信過程變得安全。它們的區(qū)別點是 DTLS 適用于加密 UDP 通信過程逼纸，SSL/TLS 適用于加密 TCP 通信過程歌亲，正是由于使用的傳輸層協(xié)議不同，造成了它們實現(xiàn)上面的一些差異。

基本概念

對稱密鑰加密技術(shù)

對稱密鑰加密的含義是加密過程和解密過程使用的是同一個密鑰澜术。常見的對稱加密算法有 DES艺蝴、3DES、AES鸟废、Blowfish猜敢、IDEA、RC5侮攀、RC6锣枝。

非對稱加密密鑰加密技術(shù)

非對稱密鑰加密的含義是加密過程和解密過程使用了不同的密鑰，分別稱為公開密鑰和私有密鑰兰英。公鑰是眾所周知的撇叁，但是密鑰只能為報文的目標(biāo)主機所持有。相比對稱加密技術(shù)畦贸，它的優(yōu)點是不用擔(dān)心密鑰在通信過程中被他人竊仍赡帧；缺點是解密速度慢薄坏，消耗更多的 CPU 資源趋厉。常見的非對稱加密算法有 RSA、DSA胶坠、DH 等君账。

數(shù)字簽名

數(shù)字簽名是附加在報文上的特殊加密校驗碼，即所謂的校驗和沈善，其中利用了非對稱加密密鑰加密技術(shù)乡数。數(shù)字簽名的主要作用是防止報文被篡改，一旦報文被攻擊者篡改闻牡，通過將其與校驗和進(jìn)行匹配净赴，可以立刻被接收者發(fā)現(xiàn)。數(shù)字簽名的過程如下圖所示：

截屏2022-04-29 17.50.59.png

發(fā)送者 A 將報文摘要（報文通過 SHA-1 等哈希算法生成摘要）通過私有密鑰加密生成簽名罩润，與明文報文一起發(fā)給接收者 B玖翅，接收者 B 可以通過對收到的信息進(jìn)行計算后得到兩份報文摘要，比較這兩份報文摘要是否相等可以驗證報文是否被篡改：

1. 明文報文通過使用與發(fā)送端相同的哈希算法生成摘要 1割以；
2. 簽名通過公開密鑰解密后生成摘要 2金度。

截屏2022-04-29 17.51.37.png

數(shù)字證書

數(shù)字證書是由一些公認(rèn)可信的證書頒發(fā)機構(gòu)簽發(fā)的，不易偽造拳球。包括如下內(nèi)容：

• 證書序列號
• 證書簽名算法
• 證書頒發(fā)者
• 有效期
• 公開密鑰
• 證書簽發(fā)機構(gòu)的數(shù)字簽名

數(shù)字證書可以用于接收者驗證對端的身份审姓。接收者（例如瀏覽器）收到某個對端（例如 Web 服務(wù)器）的證書時，會對簽名頒發(fā)機構(gòu)的數(shù)字簽名進(jìn)行檢查祝峻，一般來說，接收者事先就會預(yù)先安裝很多常用的簽名頒發(fā)機構(gòu)的證書（含有公開密鑰），利用預(yù)先的公開密鑰可以對簽名進(jìn)行驗證莱找。以 Google 為例酬姆，在瀏覽器中訪問 Google 首頁，點擊左上角的感嘆號就可以看到 Google 證書的完整信息奥溺，包括以上提到的所有內(nèi)容：

截屏2022-04-29 17.52.33.png

參考資料

zhangbuhuai.com/post/https-…

SSL/TLS 協(xié)議

簡介

要了解 DTLS辞色，首先從我們比較熟悉的 SSL/TLS 開始講起。SSL（Secure Socket Layer） 和 TLS（Transport Layer Security） 簡單理解就是同一件東西的兩個演進(jìn)階段浮定，同樣都是在應(yīng)用層和傳輸層之間加入的安全層相满，最早的時候這個安全層叫做 SSL，由 Netscape 公司推出桦卒，后來被 IETF 組織標(biāo)準(zhǔn)化并稱之為 TLS立美。SSL/TLS 的作用是為了解決互聯(lián)網(wǎng)通信中存在的三種風(fēng)險：

1. 竊聽風(fēng)險：第三方可以獲知通信內(nèi)容；
2. 篡改風(fēng)險：第三方可以修改通信內(nèi)容方灾；
3. 冒充風(fēng)險：第三方可以冒充他人身份參與通信建蹄。

SSL/TLS 協(xié)議能夠做到以下這幾點，從而解決上述的三種風(fēng)險：

1. 所有信息通過加密傳播裕偿，第三方無法竊聽洞慎；
2. 具有數(shù)據(jù)簽名及校驗機制，一旦被篡改嘿棘，通信雙方立刻可以發(fā)現(xiàn)劲腿；
3. 具有身份證書，防止其他人冒充鸟妙。

協(xié)議棧

SSL/TLS 建立在 TCP 傳輸層上焦人，最常使用 SSL/TLS 的場景是在 HTTPS 中，通過在 HTTP 和 TCP 中加了一層 SSL/TLS圆仔，使得不安全的 HTTP 成為了安全的 HTTPS垃瞧。協(xié)議棧如下圖所示：

截屏2022-04-29 17.53.50.png

SSL/TLS 加密是通過動態(tài)密鑰對數(shù)據(jù)進(jìn)行對稱加密實現(xiàn)的，而動態(tài)密鑰通過握手流程協(xié)商制定坪郭。在 SSL/TLS 握手過程中需要協(xié)商的信息包括：

1. 協(xié)議版本號个从；
2. 加密算法，包括非對稱加密算法歪沃、動態(tài)密鑰算法嗦锐；
3. 數(shù)字證書祖今，傳輸雙方通過交換證書及簽名校驗來驗證對方身份屿储；
4. 動態(tài)密鑰，由于非對稱加密對性能消耗較大按厘，因此主要的通信過程都是使用動態(tài)密鑰進(jìn)行對稱加密的液走；對稱加密使用的動態(tài)密鑰則在握手過程中通過非對稱加密來傳輸碳默。

握手過程

以 TLS 1.2 為例：

截屏2022-04-29 17.54.20.png

握手過程如上圖所示贾陷，大體來說分成三個過程：明文通信過程、非對稱加密通信過程嘱根、對稱加密通信過程髓废；

1. 明文通信過程：在通信兩端首次向?qū)Ψ桨l(fā)送 Hello 消息時，由于雙方都沒有協(xié)商好要使用哪種加密方式该抒，因此這個過程中的消息都是使用明文進(jìn)行發(fā)送的慌洪。

   a. Client Hello：客戶端首先向服務(wù)端發(fā)起握手，在握手消息中告訴對方自己支持的 SSL/TLS 版本凑保、加密套件（包括非對稱加密時使用的算法與冈爹、非對稱加密時使用的算法、產(chǎn)生密鑰的偽隨機函數(shù) PRF）與數(shù)據(jù)壓縮算法（TLS1.3之后就已經(jīng)沒有這個字段）等欧引；還會攜帶一個 Session ID频伤，因為握手流程的開銷比較大，使用 Session ID 可以在下一次與 TLS 握手的過程跳過后續(xù)繁瑣的握手流程维咸，重用之前的握手結(jié)果（如版本號剂买、加密算法套件、master-key 等）癌蓖；并產(chǎn)生一個隨機數(shù) A瞬哼，也告訴給對方；

   b. Server Hello：服務(wù)端響應(yīng)一個 Server Hello 消息租副，攜帶協(xié)商出來的 TLS/SSL 版本號坐慰、加密套件和數(shù)據(jù)壓縮算法，如果服務(wù)端同意客戶端重用上次的會話用僧，就返回一個相同的 Session ID结胀，否則就填入一個全新的 Session ID；

   c. Server Certificate（可選）：攜帶服務(wù)端數(shù)字證書（CA）以驗證服務(wù)端身份责循，里面攜帶了服務(wù)端非對稱加密所使用的公鑰糟港；大部分情況下這步都是需要的，除非客戶端和服務(wù)端協(xié)商使用了某些匿名密鑰協(xié)商算法（如 匿名 DH 算法）院仿；

   d. Server Key Exchange（可選）：在使用某些非對稱加密算法（例如 DH 算法）的情況下秸抚，Server Certificate 里的信息是不足夠的，或者 Server Certificate 在某些通信過程中直接被省略了（沒有驗證服務(wù)端身份）歹垫，需要 Server Key Exchange 里的額外信息來幫助客戶端生成 pre-master key剥汤；

   e. Client Sertificate Request（可選）：在有些安全性要求高的場景，例如銀行支付等排惨，不僅需要驗證服務(wù)端的身份吭敢，還需要驗證客戶端的身份，這時候服務(wù)端就會要求客戶端提供客戶端的身份證書暮芭；

   f. Server Hello Done：表明 Server Hello 結(jié)束鹿驼；

   g. Client Certificate（可選）：如果服務(wù)端要求客戶端提供數(shù)字證書以驗證身份欲低，則客戶端發(fā)送自己的身份證書給服務(wù)端；

2. 非對稱加密通信過程：由于非對稱加密通信的性能較差蠢沿，在實際的通信過程中其實使用的是對稱加密通信伸头，為了保證對稱加密通信過程的安全性匾效，也就是需要避免對稱加密密鑰被竊取舷蟀，這個密鑰在協(xié)商過程中使用非對稱加密來進(jìn)行加密。

   a. Client Key Exchange：客戶端在驗證服務(wù)端的身份證書后面哼，會取出其中的服務(wù)端公鑰野宜，產(chǎn)生一個隨機數(shù) C，作為 pre-master key魔策，在本地使用之前的隨機數(shù) A匈子、B 和這次生成的 C 共同生成對稱加密密鑰 master-key；使用服務(wù)端公鑰對 pre-master key 加密后發(fā)送給服務(wù)端闯袒；

   b. Certificate Verify（可選）：如果服務(wù)端要求客戶端提供客戶端證書虎敦，那么客戶端在發(fā)送 Client Key Exchange 之后必須馬上發(fā)送 Certificate Verify，其中的內(nèi)容是客戶端使用自己的私鑰加密的一段數(shù)據(jù)政敢，提供給服務(wù)端用客戶端的公鑰來進(jìn)行解密驗證其徙。之所以需要這一步是為了確保客戶端發(fā)送的證書確實是它自己的證書喷户；

   c. Client Change Cipher Spec：提示服務(wù)端隨后使用 master key 來進(jìn)行對稱加密通信唾那；

   d. Client Handshake Finished: 表明客戶端側(cè) SSL/TLS 握手結(jié)束；

   e. Server Change Cipher Spec：提示客戶端隨后使用 master key 來進(jìn)行對稱加密通信褪尝；

   f. Server Handshake Finished：表明服務(wù)端側(cè) SSL/TLS 握手結(jié)束闹获；

3. 對稱加密通信過程：通過上述握手過程協(xié)商出對稱加密算法及使用的對稱加密密鑰之后，隨后的通信過程河哑，也就是實際的應(yīng)用通信過程避诽，都使用的是對稱加密。

握手消息格式

SSL/TLS 的握手消息格式如下所示璃谨，消息類型已經(jīng)在上文握手過程中分別進(jìn)行了解釋沙庐；結(jié)構(gòu)體中包含 消息類型、消息長度睬罗、消息體轨功。

enum {
       hello_request(0), client_hello(1), server_hello(2),
       certificate(11), server_key_exchange (12),
       certificate_request(13), server_hello_done(14),
       certificate_verify(15), client_key_exchange(16),
       finished(20)
       (255)
   } HandshakeType;

   struct {
       HandshakeType msg_type;
       uint24 length;
       select (HandshakeType) {
           case hello_request:       HelloRequest;
           case client_hello:        ClientHello;
           case server_hello:        ServerHello;
           case certificate:         Certificate;
           case server_key_exchange: ServerKeyExchange;
           case certificate_request: CertificateRequest;
           case server_hello_done:   ServerHelloDone;
           case certificate_verify:  CertificateVerify;
           case client_key_exchange: ClientKeyExchange;
           case finished:            Finished;
       } body;
   } Handshake;
復(fù)制代碼

每種消息都會有自己獨立的消息體，消息體中的內(nèi)容就是握手過程中提到的消息中需要攜帶的一些信息容达，以 ClientHello 為例古涧，其中需要包含 SSL/TLS 版本號、隨機數(shù)花盐、Session ID羡滑、可選的加密套件菇爪、可選的壓縮算法：

struct {
           ProtocolVersion client_version;
           Random random;
           SessionID session_id;
           CipherSuite cipher_suites<2..2^16-1>;
           CompressionMethod compression_methods<1..2^8-1>;
       } ClientHello;
復(fù)制代碼

答疑

1. 什么時候握手過程中不需要 Server Certificate 的步驟？

如果服務(wù)端和客戶端協(xié)商出來的密鑰交換算法是匿名算法柒昏，例如匿名 DH 算法凳宙。所以如果使用如下加密套件都會省略 Server Certificate 的步驟：

CipherSuite TLS_DH_anon_WITH_RC4_128_MD5          = { 0x00,0x18 };

CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x1B };

CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA      = { 0x00,0x34 };

CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA      = { 0x00,0x3A };

CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256   = { 0x00,0x6C };

CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256   = { 0x00,0x6D };
復(fù)制代碼

TLS RFC 也明確指出使用這些匿名算法是不安全的，因為客戶端沒有驗證服務(wù)端的身份职祷，容易遭受中間人攻擊氏涩。

參考資料

RFC：
tools.ietf.org/html/rfc224… TLS 1.0
tools.ietf.org/html/rfc434… TLS 1.1
tools.ietf.org/html/rfc524… TLS 1.2（本文主要參考）
tools.ietf.org/html/rfc844… TLS 1.3
論壇資料：
www.cnblogs.com/littleatp/p…
segmentfault.com/a/119000002…
halfrost.com/https_tls1-…

DTLS 協(xié)議

簡介

DTLS 的全稱為 Datagram Transport Layer Security，從名字上就可以看出它和 TLS 的區(qū)別就在于多了一個“Datagram”有梆，因為我們把使用 UDP 傳輸?shù)膱笪慕凶?“Datagram”是尖，所以這個名字也就意味著 DTLS 是適用于 UDP 傳輸過程的加密協(xié)議。 DTLS 在設(shè)計上盡可能復(fù)用 TLS 現(xiàn)有的代碼泥耀，并做一些小的修改來適配 UDP 傳輸饺汹。DTLS 與 TLS 具備了同樣的安全機制和防護(hù)等級，同樣能夠防止消息竊聽痰催、篡改兜辞，以及身份冒充等問題。在版本上夸溶，DTLS 和 TLS 也有一定的對應(yīng)關(guān)系逸吵，如下：

• DTLS 1.0 對應(yīng) TLS 1.1
• DTLS 1.2 對應(yīng) TLS 1.2
• DTLS 1.3 對應(yīng) TLS 1.3

沒有 DTLS 1.1 應(yīng)當(dāng)是為了和 TLS 版本號相一致。

協(xié)議棧

在 WebRTC 中蜘醋，通過引入 DTLS 對 RTP 進(jìn)行加密胁塞，使得媒體通信變得安全。通過 DTLS 協(xié)商出加密密鑰之后压语，RTP 也需要升級為 SRTP啸罢，通過密鑰加密后進(jìn)行通信。協(xié)議棧如下圖所示：

截屏2022-04-29 17.55.02.png

握手過程

TLS 1.2 及之前都沒有嘗試解決 DoS 攻擊的問題胎食，直到 TLS 1.3 才通過加入了 HelloRetryRequest 和 Cookie 來解決 DoS 攻擊的問題（并且在 TLS 1.3 的 RFC 中提到主要用于非面向連接的通道扰才，也就是 UDP 連接）。相對 TCP 來說厕怜，UDP 連接對 DoS 攻擊更加敏感衩匣，因此 DTLS 在 1.0 版本就加入了 HelloVerifyRequest 和 Cookie，用于服務(wù)端對客戶端的二次校驗粥航，避免 DoS 攻擊琅捏。
同樣以 DTLS 1.2 舉例（TLS 1.3 和 DTLS 1.3 的流程已經(jīng)很接近了），相比 TLS 1.2递雀，DTLS 1.2 大部分步驟都是一樣的柄延，只是在服務(wù)端多了一步 HelloVerifyRequest，客戶端因此也多了第二次的 ClientHello缀程，如下圖所示：

截屏2022-04-29 17.55.35.png

服務(wù)端在首次收到客戶端發(fā)送的 Client Hello 之后搜吧，只會生成一個 Cookie市俊，不進(jìn)行任何其他的操作，并給客戶端發(fā)送 HelloVerifyRequest 消息滤奈，帶上這個 Cookie摆昧。只有當(dāng)客戶端重新發(fā)送一次 Client Hello，并帶上服務(wù)端發(fā)送的這個 Cookie 后蜒程，服務(wù)端才會繼續(xù)握手過程绅你。

握手消息格式

DTLS 的握手消息格式如下所示，可以看到相比 SSL/TLS 的握手協(xié)議搞糕，DTLS 在消息類型中多了 HelloVerifyRequest 這種消息（在握手過程中介紹過）勇吊，在結(jié)構(gòu)體中多了 message_seq、fragment_offset窍仰、fragment_length 三個字段。
SSL/TLS 基于 TCP礼殊，因此不需要操心重放驹吮、亂序、丟包的問題晶伦，可靠傳輸由 TCP 做了保證碟狞；而 DTLS 基于 UDP，UDP 是一種盡力而為的協(xié)議婚陪，因此 DTLS 需要自己處理重放族沃、亂序、丟包的問題泌参。DTLS 在復(fù)用大部分 TLS 的基礎(chǔ)上做了一些小改動脆淹，在握手消息中增加了三個字段 message_seq、fragment_offset沽一、fragment_length 三個字段盖溺，具體的功能在下一節(jié)中講述。

enum {
     hello_request(0), client_hello(1), server_hello(2),
     hello_verify_request(3),                   // New field
     certificate(11), server_key_exchange (12),
     certificate_request(13), server_hello_done(14),
     certificate_verify(15), client_key_exchange(16),
     finished(20), (255) } HandshakeType;

   struct {
     HandshakeType msg_type;
     uint24 length;
     uint16 message_seq;                        // New field
     uint24 fragment_offset;                    // New field
     uint24 fragment_length;                    // New field
     select (HandshakeType) {
       case hello_request: HelloRequest;
       case client_hello:  ClientHello;
       case server_hello:  ServerHello;
       case hello_verify_request: HelloVerifyRequest;// New field
       case certificate:Certificate;
       case server_key_exchange: ServerKeyExchange;
       case certificate_request: CertificateRequest;
       case server_hello_done:ServerHelloDone;
       case certificate_verify:  CertificateVerify;
       case client_key_exchange: ClientKeyExchange;
       case finished: Finished;
     } body; } Handshake;
復(fù)制代碼

每種消息同樣都會有自己獨立的消息體铣缠，消息體中的內(nèi)容就是握手過程中提到的消息中需要攜帶的一些信息烘嘱，大部分的消息體內(nèi)容與 SSL/TLS 相同，區(qū)別有兩點：

1. 多了 HelloVerifyRequest 消息蝗蛙，需要攜帶 Cookie蝇庭，消息體如下所示：

struct {
        ProtocolVersion server_version;
        opaque cookie<0..32>;
      } HelloVerifyRequest;
復(fù)制代碼

2. ClientHello 多了 Cookie 字段，因為第二次 ClientHello 需要攜帶 Cookie 信息：

struct {
        ProtocolVersion client_version;
        Random random;
        SessionID session_id;
        opaque cookie<0..32>;                             // New field
        CipherSuite cipher_suites<2..2^16-1>;
        CompressionMethod compression_methods<1..2^8-1>;
      } ClientHello;
復(fù)制代碼

與 SSL/TLS 在實現(xiàn)上的區(qū)別

在上文的握手過程和握手協(xié)議中已經(jīng)講述了一些 DTLS 與 SSL/TLS 的區(qū)別捡硅。此外哮内，DTLS 針對重復(fù)、亂序病曾、丟包等問題增加了一些防護(hù)機制牍蜂。

握手防護(hù)機制

重傳

TCP 天然的重傳機制保證了消息不會丟失漾根，而 UDP 對此沒有任何保證。因此 DTLS 額外增加了超時重傳機制來確定握手消息到達(dá)鲫竞，流程如下：

截屏2022-04-29 17.56.02.png

以握手的第一階段舉例辐怕，客戶端發(fā)送 Client Hello（不帶 Cookie，區(qū)別于握手流程中的第二次 Client Hello）之后从绘，啟動一個定時器寄疏，等待服務(wù)端返回 HelloVerifyRequest，如果超過了定時器時間客戶端還沒有收到 HelloVerifyRequest僵井，那么客戶端就會知道要么是 Client Hello 消息丟了要么是 Hello Verify Request 消息丟了陕截，客戶端就會再次發(fā)送相同的 Client Hello 消息，即使服務(wù)端確實發(fā)送了 Hello Verify Request 還是收到了 Client Hello 消息批什，它也知道是需要重傳农曲，并再次發(fā)送 Hello Verify Request 消息，同樣地驻债，服務(wù)端也會啟動定時器來等待下一條消息乳规。

序列號

TCP 消息中自帶了序列號 seq，并處理了亂序的問題合呐，而 UDP 對亂序問題也沒有任何保證暮的。為了保證握手消息的有序性，DTLS 在握手報文中增加了 message_seq 字段便于接收方處理亂序消息淌实。接收方直接處理屬于當(dāng)前步驟的消息冻辩，提供一個緩存隊列來緩存提前到達(dá)的消息。

報文大小限制

TCP 面向字節(jié)流拆祈，而 UDP 面向報文恨闪。因此 TCP 會自動將報文進(jìn)行拆分和組裝，無需上層操心缘屹；而 UDP 報文如果超過了 MTU（鏈路層的最大傳輸單元） 限制凛剥，會在 IP 層被強制分片，使得每一片大小都小于 MTU轻姿，接收方 IP 層需要進(jìn)行數(shù)據(jù)報的重組犁珠，這樣就會多做許多工作，更麻煩的地方在于只要其中一片丟失就會造成重組失敗互亮，造成整個 UDP 報文丟失犁享。 因此 DTLS 直接在 UDP 之上就對握手消息做了分段，握手報文中的 fragment_offset 和 fragment_length 就是為了這個目的豹休，分別代表這段報文相對消息起始的偏移量以及這段報文的長度炊昆。

Cookie

在上文的握手過程中 TLS 1.2 及之前都沒有嘗試解決 DoS 攻擊的問題，直到 TLS1.3 才通過加入了 HelloRetryRequest 和 Cookie 來解決 DoS 攻擊的問題（并且在 TLS 1.3 的 RFC 中提到主要用于非面向連接的通道，也就是 UDP 連接）凤巨。相對 TCP 來說视乐，UDP 連接對 DoS 攻擊更加敏感，因為 TCP 可以使用 SYN Cookie 的機制來防范 DoS 攻擊敢茁。 如果在 UDP 上直接使用 TLS 的握手方式佑淀，就可能發(fā)生以下兩種情況：

1. 攻擊者可以通過發(fā)送一系列握手啟動請求來消耗服務(wù)器上的資源，例如服務(wù)端可能會為此分配緩沖區(qū)彰檬，并且加密過程也是一個非常消耗 CPU 資源的操作伸刃；
2. 攻擊者可以偽造受害客戶端的 IP 地址向服務(wù)端發(fā)起 DTLS 握手，迫使服務(wù)端發(fā)送 Certificate 消息給受害客戶端逢倍，上文提到過 Certificate 攜帶了很多信息捧颅，包括數(shù)字證書等，所以這個消息會非常大较雕，使得受害客戶端不得不接受大量無用消息碉哑。

因此 DTLS 在 1.0 版本就加入了 HelloVerifyRequest 和 Cookie，用于服務(wù)端對客戶端的二次校驗郎笆，避免 DoS 攻擊谭梗。具體實現(xiàn)方式如下：

1. 當(dāng)客戶端首次給服務(wù)端發(fā)送 Client Hello 時，服務(wù)端只會生成一個 Cookie 并通過 HelloVerifyRequest 發(fā)送給客戶端宛蚓，不會執(zhí)行分配緩沖區(qū)等操作，直到收到帶上相同 Cookie 的 Client Hello 才會繼續(xù)握手设塔，可以使得偽造 IP 的攻擊難以實現(xiàn)（使用真實 IP 的 DoS 攻擊無能為力）凄吏；
2. HelloVerifyRequest 足夠小，即使服務(wù)端被攻擊者當(dāng)槍使來攻擊其他機器闰蛔，也不會造成大量數(shù)據(jù)發(fā)送痕钢。

截屏2022-04-29 17.56.26.png

加密方式

由于 SSL/TLS 依賴 TCP，所以 SSL/TLS 有如下幾個特性：

1. SSL/TLS 不能獨立解密單個封包序六，SSL/TLS 對于封包的認(rèn)證需要序號作為輸入任连，在 SSL/TLS 中并未直接傳遞序號，因為 TCP 是可靠的例诀，所以 SSL/TLS 的兩端各自維護(hù)自身的收發(fā)序號随抠；
2. SSL/TLS 的某些加密算法不是獨立解密的，需要依賴上個封包繁涂，典型的就是 RC4 流加密算法拱她。

由于 UDP 本身的不可靠，為了解決上面提到的第一個問題扔罪，DTLS 在每條記錄中顯式攜帶的序號作為解碼的輸入秉沼；而對于第二個問題，DTLS 的現(xiàn)狀是不能支持 RC4 等流式加密算法。

消息重放檢測

消息重放也是 DoS 攻擊的一種唬复，攻擊者可以截取發(fā)送者發(fā)送的數(shù)據(jù)矗积，并直接原封不動地發(fā)給接收方，來達(dá)到欺騙接收方的目的敞咧。 DTLS 增加了類似 IPsec AH/ESP 的消息重放檢測棘捣，使用一個 bitmap 滑動窗口來接收消息，結(jié)合消息本身的序號妄均，bitmap 可以判斷該消息是否是太老的消息柱锹，是的話則直接拋棄。這個功能在 DTLS 中是可選的丰包，因為某些 UDP 報文的重復(fù)只是單純因為網(wǎng)絡(luò)錯誤禁熏。

答疑

1. DTLS 是否需要用戶自己實現(xiàn)？

OpenSSL 中有對 DTLS 的支持邑彪，在 WebRTC 中收到包并判斷是 DTLS 包后瞧毙，會通過 OpensslStreamAdaptor 將剩下的步驟交給 OpenSSL 來做，基本不需要用戶自行實現(xiàn)寄症。

2. 攻擊者做重放攻擊的收益是什么宙彪？為什么 DTLS 要做重放檢測？如果不是中間人有巧，而是發(fā)送端不斷重復(fù)發(fā)送某條消息释漆，是否也會引起同樣的問題？

www.pcmag.com/encyclopedi…

www.kaspersky.com/resource-ce…

參考網(wǎng)上的一些案例：
a. 用戶 A 登錄某個網(wǎng)站篮迎，然后攻擊者直接把登錄過程記錄下來重放男图，雖然攻擊者不知道用戶 A 的密碼，但通過重放攻擊者也可以成功登錄甜橱，達(dá)到了盜號的目的逊笆；
b. 用戶 A 登錄某支付平臺給 B 轉(zhuǎn)賬 100 元，B 把 A 和支付平臺的通信過程記錄下來重放岂傲，這樣支付平臺就會給 B 轉(zhuǎn)非常多的錢难裆。

DTLS 其實不僅是給WebRTC 媒體傳輸用的，例如 OpenSSL 直接收錄了 DTLS镊掖，DTLS 有可能被用到一些非常重要的場合乃戈。作為一種標(biāo)準(zhǔn)協(xié)議，DTLS 需要考慮自身的安全性堰乔，因此 DTLS 需要在設(shè)計時考慮防范重放攻擊偏化。

對于第二個問題，發(fā)送端不斷重復(fù)發(fā)送某條消息镐侯，不是重放攻擊侦讨。當(dāng)然惡意客戶端可能想要消耗服務(wù)端的資源驶冒，瘋狂調(diào)用某些 API，DTLS 無法防止這種問題韵卤，需要靠上層業(yè)務(wù)來保證骗污。

參考資料

RFC：
tools.ietf.org/html/rfc371… SRTP
tools.ietf.org/html/rfc434… DTLS 1.0
tools.ietf.org/html/rfc634… DTLS 1.2（本文主要參考）
tools.ietf.org/id/draft-ie… DTLS 1.3
論壇資料：
www.bbsmax.com/A/RnJW0Rpg5…
yq.aliyun.com/articles/61…
juejin.cn/post/684490…

作者：MrCoderOrange
鏈接：https://juejin.cn/post/6915329869983252488
來源：稀土掘金
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)沈条，非商業(yè)轉(zhuǎn)載請注明出處需忿。