原文地址
WebRTC中使用了DTLS，這篇關于DTLS的文章寫的比較詳細，轉載過來重新排版了一下。
1.DTLS介紹
1.1 DTLS的作用
互聯網先驅們最開始在設計互聯網協議時主要考慮的是可用性，安全性是沒有考慮在其中的，所以傳輸層的TCP、UDP協議本身都不具備安全性。SSL/TLS協議是基于TCP socket，在傳輸層和應用層之間構建了一個端到端的安全通道，保證了傳輸數據的加密性。
但是SSL/TLS協議并不能用于UDP協議，而UDP也有安全傳輸的需求，于是產生了DTLS協議（Datagram TLS）。
即DTLS的作用為給UDP提供端到端的安全通道，就像SSL/TLS對TCP的作用一樣。并且DTLS盡可能參考了SSL/TLS協議的安全機制，在具體實現上復用了70%的TLS代碼。
1.2 DTLS的特點
UDP協議是不面向連接的不可靠協議，且沒有對傳輸的報文段進行加密，不能保證通信雙方的身份認證、消息傳輸過程中的按序接收、不丟失和加密傳送。
而DTLS協議在UDP提供的socket之上實現了客戶機與服務器雙方的握手連接，并且在握手過程中通過使用PSK或ECC實現了加密，并且利用cookie驗證機制和證書實現了通信雙方的身份認證，并且用在報文段頭部加上序號，緩存亂序到達的報文段和重傳機制實現了可靠傳送。
在握手完成后，通信雙方就可以實現應用數據的安全加密和可靠傳輸。
1.3 DTLS協議層次
DLTS協議分為兩層，下層為記錄層（記錄層），record包的內容分為頭部和載荷兩部分。記錄包的載荷即為上層的內容。DTLS上層的包的類型分為三種，分別是握手消息，警告消息，應用數據；如圖一所示。
在整個DTLS協議的通信過程中，通信雙方構造報文段的過程都是先產生上層的載荷消息（如握手消息，應用數據，警告消息），然后添加頭部，構成完整的上層消息。接著再以此作為記錄層的載荷，最后添加記錄層的頭部，構成完整的記錄報文段，最后調用UDP的socket接口，發送給另一方。
加密過程是只對記錄層的載荷(即上層消息，此協議中被加密的消息是finished消息和應用數據兩種)進行加密，所以接收方在收到記錄消息后，首先要做的也是判斷記錄消息是否被發送方加密，若是，則應先解密才能讀取出明文數據以進行后面的處理。
2.DTLS傳輸階段
2.1 整個握手階段的交互過程
DTLS的傳輸階段分為兩個：握手階段和握手建立之后的傳輸應用數據階段。
DTLS的握手階段如下圖二所示：
客戶機向服務器發起連接，服務器可以根據配置選擇是否驗證客戶機的cookie和證書（即是否向客戶機發送client_hello_verify和certificate_request報文段）。
2.2 DTLS的cookie驗證機制
由于DTLS是基于UDP的，所以可能會遭受兩種形式的拒絕服務攻擊。一種是類似于對TCP的資源消耗攻擊，另一種是放大攻擊，即惡意攻擊者仿造被攻擊者的IP地址發通信初始化報文段給服務器，而服務器會返回一個體積大很多的證書給被攻擊者，超大量證書有可能造成被攻擊者的癱瘓。
cookie機制要求客戶機重復發送服務器之前發送的cookie值來驗證通信方的源IP地址確實可以通信，由此可以減少拒絕服務攻擊的危害。
cookie驗證身份的具體機制為：
協議規定客戶機發送的第一個報文段client_hello中含有cookie的值這一項（有可能為空）。服務器檢驗收到的該報文段中的cookie值，如果cookie為空，則說明之前沒建立過連接，服務器根據客戶機的源IP地址通過哈希方法隨機生成一個cookie，并填入client_hello_verify中發送給客戶機。
客戶機再在第二次發送的client_hello報文段中填入服務器之前發過來的cookie，服務器第二次收到該報文段之后便檢驗報文段里面的cookie值和服務器之前發給該主機的cookie值是否完全相同，若是，則通過cookie驗證，繼續進行握手連接；若不是，則拒絕建立連接。
2.3 client_hello報文段和server_hello報文段的內容
client_hello報文段的內容除cookie外，還有客戶機產生的32字節的隨機數，其中前4字節為時間戳，后28字節為系統產生的隨機數。此外，該報文段的內容還有客戶機支持的加密方式（PSK或者ECC）和壓縮方式，供服務器進行選擇。
在通過cookie校驗后，服務器發送server_hello報文段給客戶機。該報文段包含有服務器產生的32字節的隨機數，和服務器選中的用來進行之后的會話的加密方式和壓縮方式。
2.4 certificate報文段的內容
在服務器發給客戶機的證書報文段中，包含有服務器證書的公鑰；客戶機接收到該報文段后，按照協議規定，從報文段的對應位置中讀取出服務器證書的公鑰存入相關變量中。
2.5 基于ECC加密方式的ECDH秘鑰交換協議和ECDSA數字簽名算法
若協議所選加密方式為ECC（橢圓曲線加密），則在server_key_exchange報文段的構造過程中會使用ECDH（橢圓曲線秘鑰交換協議）和ECDSA（橢圓曲線數字簽名算法）。ECDH和ECDSA分別是ECC和DH（diffie-hellman）秘鑰交換協議、DSA（數字簽名算法）的結合。
在server_key_exchange報文段中，包含有所選用的橢圓曲線E，階N和基點G的x,y坐標，客戶機在收到這個報文段后，進行對應的格式檢驗，并讀取數據，因此服務器和客戶機共同獲得約定好的用來進行ECDH秘鑰協商交換協議的參數，從而可以共同協商出相同的對話秘鑰用于加密之后的會話內容。
同時，為了防范中間人攻擊，服務器還在server_key_exchange報文段的末尾對整個報文段進行了ECDSA數字簽名。具體簽名過程為先用client_hello報文段和server_hello報文段中的2個32字節的隨機數作為函數參數，利用sha256哈希算法對server_key_exchange報文段本身的載荷產生摘要，然后再用服務器的私鑰和sha256哈希算法進行ECDSA數字簽名，得到簽名結果r和s,并寫入server_key_exchange報文段的末尾。
客戶機在收到server_key_exchange報文段后，先進行各數值項格式的校驗，然后提取出報文段末尾的簽名值r和s。之后，用已經讀取出的服務器的公鑰的x,y坐標值來對server_key_exchange報文段進行ECDSA簽名驗證，若結果和報文段中的r和s值一致，則報文段通過驗證。
2.6 基于PSK加密方式的身份認證過程和會話秘鑰產生過程
整個DTLS協議的加密方式可選用ECC或PSK（預共享秘鑰，PreSharedKey）兩種。若為ECC，則通過ECDH協議來進行通信雙方的秘鑰協商；若為PSK，則直接以通信雙方事先就已經約定好了的秘鑰為基礎來進行加密通信。
對于PSK加密通信來說，驗證對方的通信身份非常關鍵。所以通信雙方會在本地存取對方的psk_id（即身份標志）和psk_id_length（身份標志長度），通過比較收到的報文段中的psk_id,psk_id_length和本地存儲的是否完全一致來進行對方身份的驗證。
在整個通信過程中，采用PSK與ECC的區別主要體現在server_key_exchange報文段、client_key_exchange報文段的內容不同和雙方計算得到預主秘鑰方式的不同。
當采用PSK加密時，server_key_exchange報文段和client_key_exchange報文段的內容分別是服務器與客戶機各自的psk_id和psk_id_length，由此雙方可以互相知道對方的psk_id和psk_id_length。
之后，雙方都會對收到的報文段進行檢驗，只有psk_id和psk_id_length與本地存儲的完全一致才會進行后面的通信。
當雙方都通過身份驗證后，雙方再各自用相同的函數產生預主秘鑰，而函數的參數包括之前通信階段中雙方各自產生的32字節的隨機數，由此可以保證雖然本地存儲的psk秘鑰不變，但每次臨時通信時的會話秘鑰還是會一直變化的，從而增強了抗攻擊性。
雙方產生預主秘鑰后，再調用和使用ECC加密的相同方式來產生主秘鑰，即用于之后會話通信的對稱秘鑰，該過程中依然會用到雙方產生的32字節的隨機數。
由此，通信雙方使用PSK加密方式來實現了身份認證和會話秘鑰的產生。
2.7 server_hello_done報文段和client_key_exchange報文段的內容
服務器發送的server_hello_done報文段的載荷部分為空，只是發給客戶機來作為標志，表示服務器當前階段的報文段已經發送完畢。
客戶機在收到server_hello_done報文段后，發送client_key_exchange報文段給服務器，里面包含了用于秘鑰協商的基點的x,y坐標,并且不同于server_key_exchange報文段，客戶機并沒有在報文段的末尾進行ECDSA數字簽名。
2.8 客戶機產生會話秘鑰
之后，客戶機再通過ecdh_pre_master_secret函數來產生用于之后會話的預主秘鑰。其中函數的參數包括客戶機自己的私鑰，和服務器共享的用于ECDH秘鑰協商算法的基點的x,y坐標。
產生預主秘鑰后，再根據之前階段客戶機和服務器分別產生的32字節的隨機數產生主秘鑰master_secret，此時主秘鑰為對稱秘鑰，用于之后會話的加解密。
2.9 change_cipher_spec報文段和finished報文段的內容
客戶機計算出會話秘鑰后，發送change_cipher_spec報文段給服務器，這個報文段的有效載荷為空，用來作為標志通知服務器，表示客戶機已經算出主秘鑰，之后發送的報文段會采用主秘鑰加密。
握手階段中客戶機發送的最后一個報文段為finished報文段，載荷內容為MAC值（消息驗證碼），用于給服務器做認證。并且值得注意的是，finished報文段作為記錄層的載荷部分在發送時已經用上一步產生的會話秘鑰進行加密編碼。
2.10 服務器產生會話秘鑰
服務器在收到客戶機發送過來的finished報文段后，也會和客戶機用ECDH秘鑰協商算法經過相同的流程，調用相同的函數先產生預主秘鑰，再產生主秘鑰。
2.11 握手階段的結束
最后，服務器產生經會話秘鑰加密后的finished報文段給客戶機，標志整個握手階段的結束。
客戶機收到服務器發過來的finished報文段后，便可發送應用數據。并且應用數據會一直用會話秘鑰加密，從而實現了UDP所不具備的安全性。
