tls-auth と tls-crypt：OpenVPN でそれぞれが何を守るか

どちらのオプションも共有鍵ファイルを使い、どちらもハンドシェイクの通信を偽造しにくくします。そのため同じ機能の別名のように扱われます。そうではありません。片方は制御パケットに署名し、もう片方はそれを暗号化もし、どちらもペイロードを守る暗号とは関係がありません。

この区別は、プロファイルが接続できないとき、セキュリティレビューで鍵が何を守るのかと問われたとき、追加ファイルによってトンネルが漠然と暗号化されると思い込まれたときに重要になります。

共有鍵が実際に守るもの

これらのオプションが使う鍵は制御チャネルに属します：パラメータを交渉し、身元を証明し、データ鍵を導出するやり取り。これはハンドシェイクを進める前に両端が持っていなければならない事前共有の秘密です。身元確認より前に位置するため、誤った鍵は誤ったパスワードよりも早く会話を止めます。この順序が、失敗の現れ方があれほど静かな理由です。

tls-auth はその秘密を使って制御パケットの HMAC を計算します。有効な署名のないパケットは、より高コストな TLS 処理に届く前に破棄されます。だからこのオプションは TLS の代替ではなく最初のフィルタと説明されます。

tls-crypt はさらに進み、保護された制御トラフィックを認証するだけでなく暗号化します。証明書の中身、交渉された暗号名、その他のハンドシェイクの詳細はもうネットワーク上に見えず、鍵を持たない観測者はどの TLS バージョンを試みているかさえ見えません。自社の VPN 指紋が明らかになるのを恐れる配備にとって、この性質が選ぶ主な理由です。それでもグループの秘密であり、利用者ごとの資格情報ではありません。

どちらの仕組みも身元を発行しません。共有鍵はグループの秘密であり、それを持つ者なら誰でもこの層の検査を満たせます。

二つのオプションが異なる点

観測できる違いは、観測者に何が見えるかです。tls-auth ではハンドシェイクは見えますが、鍵なしでは検証できません。tls-crypt ではハンドシェイクは鍵を持たない者にとって不透明です。

設定も異なります。tls-auth は方向の値とともに使うため、一方が鍵素材の半分を使い、もう一方が残りの半分を使います。tls-crypt は両方向で単一の鍵を使うため、方向の指定はその構成に含まれません。

現代のリリースでは二つのオプションは排他的です。プロファイルはどちらか一方だけを持つべきで、両方ではありません。サーバーとクライアントは、同一の鍵素材でどちらを使うか合意しなければなりません。古い指定を新しい指定の隣に残すのはよくある移行の名残です。使っていない方を削除して、次に読む人がどの層が実際に有効かを分かるようにしてください。

より新しい派生形である tls-crypt-v2 は、各クライアントをそれぞれのラップされた鍵に結び付けるため、一つのクライアントを取り消してもグループ鍵を再発行する必要がありません。知っておく価値はありますが、別のオプションであり、ここで扱う二つの同義語ではありません。

不一致が何も起きていないように見える理由

共有素材が一致しないと、相手側は送信者に理由を告げずにパケットを捨てます。読むべき認証エラーはありません。パケットが、それを生成する層に決して届かなかったからです。

クライアントは再試行し、サーバーは何も言わず、症状はネットワークの問題のように見えます。そこで人はサービスを再起動し、アカウントのパスワードを打ち直し、あるいは「試す」ために保護の指定を外します。これは診断ではなく配備の変更です。

サーバーログでは、最後の再試行行ではなく、最初のパケットレベルの不満を読みます。両側が同じ鍵素材で同じオプションを持っていること、鍵ファイルが片側だけで再生成されていないことを確認します。

指定を外すのは安全な修理ではありません。すべてのクライアントで保護の層が無効になり、その後にトンネルが動いても、その層が不一致だったことしか証明できません。

別に設定しなければならないもの

これらのオプションは相手が誰かを検証しません。証明書の検証、信頼の起点、期待するサーバー名は別個の要件のままであり、共有鍵があるからといってどれも任意にはなりません。

データ暗号も選びません。それは両端のデータチャネル設定が制御する別の交渉です。そして tls-crypt で保護されたトンネルでも、意図しなかった暗号を使うことがあります。

最後に、共有鍵そのものの扱いが要ります。秘密として扱い、承認された経路で配布し、それを持っていた人が去ったら交換してください。共有されているため、その露出はそれを使うすべての端点の露出です。