NodeNanny

---
title: ネットワークと暗号の原理・応用編：TLS、AEAD、トラフィックフィンガープリンティング
summary: protocols-overview.md の応用編。TLSハンドシェイク、AEAD暗号化、DPIによるトラフィックフィンガープリンティングの背後にある原理を説明する、理論寄りで比較的古くなりにくい内容
order: 2
updated: 2026-07-28
tags: [tls, 暗号化, dpi, 原理]
---


> 本稿は protocols-overview.md の応用編で、「なぜ」の部分——すなわちDPIが具体的にどうやってトラフィックを識別するのか、各プロトコルの識別耐性がどこから来るのかを扱います。内容は理論寄りで比較的安定した基礎知識であり、正確性は具体的なプロトコル一覧や検出率の数字ほど頻繁に古くならないものです。

## TLSハンドシェイクが大まかに何をしているか

普通のウェブサイトにアクセスする場合でも、Reality/AnyTLSのような「TLSに偽装した」プロキシプロトコルを使う場合でも、TLSハンドシェイクが解決すべき問題は同じです：**見ず知らずのクライアントとサーバーが、安全でないネットワーク上でどうやって両者だけが知る暗号鍵を協議し、同時に相手の身元を確認するか**。簡略化した流れは次の通りです。

1. クライアントがClientHelloを送信し、自身がサポートする暗号スイートの一覧、乱数、アクセスしたいドメイン名（SNIフィールド。このステップは平文であり、初期のGFWがドメイン単位で遮断する際の重要な着眼点の一つでもありました）を含めます
2. サーバーがServerHelloを返し、暗号スイートを選定し、身元を証明する証明書を提示し、こちらも乱数を含めます
3. 両者はこの2つの乱数＋鍵交換アルゴリズム（現在の主流はECDHE）に基づき、それぞれ独立して同一のセッション鍵を算出します。鍵そのものはネットワーク上を一度も転送されません
4. 以降のすべてのアプリケーションデータは、このセッション鍵で暗号化されて伝送されます

Reality プロトコルの核心的な発想は、本物のウェブサイトのTLS証明書とハンドシェイク特徴を「借用」することで、GFWが能動的にプロービングした際に見えるものが、実際にそのウェブサイトにアクセスしている場合と区別がつかないようにすることです。AnyTLSは任意のプロキシトラフィックを標準的なTLSレコード層に包み込む方式で、発想としては同じ種類の「偽装」ですが、実装の詳細が異なります。

## AEAD暗号化が具体的に何を守っているか

現在主流のプロキシプロトコル（VMess、Shadowsocks-2022、Trojanのデータ層など）はいずれもAEAD（Authenticated Encryption with Associated Data）系の暗号アルゴリズムを使用しており、AES-GCMやChaCha20-Poly1305がよく使われます。AEADは同時に2つのことを行います。

- **機密性**：内容を暗号化した後、鍵がなければ元の内容を読み出せない
- **完全性/真正性**：各暗号文には認証タグが付与されており、受信側は「このデータが確かに正しい鍵を持つ側によって生成されたものであり、途中で改ざんされていないこと」を検証できます——もしGFWが能動的にプロービングする際に偽造/改ざんされたデータを送りつけた場合、AEADの検証は失敗し、接続は即座に切断されます。これは「能動的プロービング」という攻撃手段自体が直面する天然の障壁でもあります。

これは、初期の一部プロトコルが認証を行っていなかった（あるいは認証が十分に厳密でなかった）ために「能動的プロービング」で識別されやすかった理由でもあります——プロービング側が奇形のパケットを送り、サーバーの反応パターンを観察するだけで、プロトコルの特徴が露見してしまいます。

## DPIが具体的にどうやって「これがプロキシトラフィックだ」と見抜くのか

トラフィック自体がすでに暗号化されており、内容を直接読み取れないという前提のもとで、DPIは主に内容そのものではなく統計的特徴に依存します。よくある分析の切り口は次の通りです。

- **パケット長の分布**：異なるプロトコルのハンドシェイクパケットや制御パケットのサイズには往々にして規則性があり、プロトコル自身が能動的な長さのパディングを行わない限り、暗号化してもこの規則性を完全には覆い隠せません
- **時間間隔の特徴**：ハートビートやkeep-aliveの送信リズムは、プロキシソフトと通常のブラウザとで挙動が異なります
- **エントロピー分析**：真にランダムな暗号化データのエントロピーは理論上の最大値に近く、あるプロトコルの暗号文が特定のバイト位置で非ランダムな固定パターンを示す場合（初期のプロトコル設計上の欠陥）、統計的に検出されえます
- **最初の数パケットの特徴マッチング**：多くのプロトコルは接続確立の最初の数パケットに固定的な構造を持ちます（たとえ内容が暗号化されていても、長さや順序のパターンは変わらないことがあります）
- **能動的プロービング**：あるIPがプロキシサービスを運用していると疑われる場合、直接接続を試みてサーバーがどう応答するかを見ます——正常なHTTPSサイトと応答の仕方が異なる場合（ハンドシェイク失敗の仕方が違う、奇形リクエストへの反応が違うなど）、マークされる可能性があります

この層を理解することで、protocols-overview.md にある「なぜTLS偽装系プロトコルの方が識別耐性が高いのか」という結論の仕組みを説明できます：Reality/AnyTLSのようなプロトコルの目標は、単に暗号化するだけでなく、上記のいくつかの次元（パケット長、ハンドシェイク構造、能動的プロービングへの応答）をできるだけ本物のウェブサイトに近づけることです。**暗号化が解決するのは「内容が読めるかどうか」であり、フィンガープリント耐性が解決するのは「振る舞いのパターンが疑わしく見えるかどうか」であり、これは2つの異なるレベルの問題です。あるプロトコルが暗号化をきちんと行っているからといって、識別耐性があるとは限りません。**

## この部分の内容が比較的古くなりにくい理由

TLSハンドシェイクの流れ、AEADの設計目標、DPIが内容ではなく統計的特徴に依存するという点は、暗号学とネットワークプロトコルのレベルでは比較的安定した基礎的事実であり、短期間である技術のアップデートによって全体が古くなることはあまりありません。実際に変化し、定期的な見直しが必要なのは、「具体的にどのプロトコルが現在識別耐性が強い/弱いか」「GFWの具体的な検出率の数字」といったアプリケーション層の結論です——この部分については本稿ではなく protocols-overview.md を参照してください。