DTLS
TLSの暗号化や認証の仕組みを、UDPのようなデータグラム型の通信でも使えるようにしたプロトコル。CoAPやVPN、Web会議などで使われる。
イマシルちゃんの解説
TLSは、HTTPSなどで使われている暗号化の仕組みだけど、TCPの上で動くことが前提なんだ。
UDPは、パケットがなくなったり、順番が入れ替わったりすることがあるから、そのままだとTLSは使えない。
DTLSは、そういうUDPの性質に合わせて、TLSを作り直したものなんだよ。
さらに、送信元をごまかした攻撃に悪用されないための工夫も入っているんだ！
より深い解説
定義
DTLS（Datagram Transport Layer Security）は、UDPの上で、TLSと同等の機密性、完全性、認証を提供するプロトコルである。DTLS 1.2はRFC 6347、DTLS 1.3はRFC 9147で定められている。CoAPでは、データの保護が必要な場合にDTLSを使う（coaps、ポート5684）。
TLSとの違い
UDPはパケットの損失や順序の入れ替わりがあるため、DTLSは次のような仕組みを独自に持つ。
| 仕組み | 内容 |
|---|---|
| ハンドシェイクの再送 | ハンドシェイクのメッセージが失われたら、タイマーで再送する |
| シーケンス番号 | レコードに明示的な番号を付け、順序の入れ替わりや重複、再送攻撃に対処する |
| メッセージの分割 | 大きなハンドシェイクのメッセージを、IPのフラグメントを避けるために分割する |
| クッキーの交換 | 送信元の偽装による攻撃を防ぐ（下記） |
UDPでのハンドシェイクの危険性
TCPでは、3ウェイハンドシェイクを終えないと通信が始まらないため、送信元のアドレスを偽装した通信は成立しにくい。UDPにはこの仕組みがないため、TLSのハンドシェイクをそのままUDPで行うと、次の攻撃が成立する。
- 攻撃者が、送信元のIPアドレスを攻撃対象のアドレスに偽装して、小さなClientHelloを送る
- サーバは、証明書などを含む大きなServerHelloを、攻撃対象に送り返す
- 小さな要求で大きな応答を送らせるため、サーバが、DDoS攻撃の加害者（踏み台）になる
この攻撃は、リフレクション（反射）攻撃、増幅攻撃と呼ばれる。
クッキーによる対策
| 順 | メッセージ | 内容 |
|---|---|---|
| 1 | ClientHello | クライアントが接続を求める |
| 2 | HelloRetryRequest ＋ cookie | サーバは、大きな応答を返さず、小さなメッセージにクッキー（クライアントのアドレスなどから作る値）を付けて返す |
| 3 | ClientHello ＋ cookie | クライアントは、受け取ったクッキーを付けて、もう一度ClientHelloを送る |
| 4 | ServerHello 以降 | サーバは、クッキーが正しいことを確かめてから、ハンドシェイクを続ける |
クッキーが正しければ、そのクライアントが、送信元のアドレスで実際に応答を受け取れる、すなわち最初の ClientHello の送信元が偽装されたものではないと判断できる。クッキーが不正な場合、サーバは ServerHello を送らずに、ハンドシェイクを終了する。
DTLS 1.2では、同じ役割を HelloVerifyRequest というメッセージが担う。
IoTでのDTLSの判断
DTLSの暗号処理は、処理能力やバッテリーの限られたIoT機器には負担になることがある。機器とサーバの通信が、インターネットを通らない閉域網の中だけで行われる構成なら、DTLSを使わずに済ませるという判断もありうる。