トランスポート層セキュリティ(TLS)は、ネットワーク上のアプリケーション間でデータを暗号化および認証する暗号プロトコルであり、TLS 1.3(RFC 8446)では、フォワードシークレシーを確保し、HTTPS、電子メール、DNS over TLS を含む企業トラフィックを保護するために、レガシー機能が削除されています。 TLSの管理が不十分だと、有効期限切れの証明書、古いプロトコルバージョン、管理されていない秘密鍵によってサービス停止やセキュリティ上のリスクが生じるため、組織は証明書のインベントリ管理、更新の自動化、および最低プロトコルバージョンポリシーの徹底が必要となります。 DNS over TLS(RFC 7858)は、TCPポート853上のDNSクエリを特に暗号化し、クエリの傍受を防止します。一方、DNS over HTTPSは、ポート443上の標準的なHTTPSトラフィック内にDNSを組み込んで伝送します。それぞれのアプローチは、ネットワーク管理者にとって、可視性と導入における異なるトレードオフをもたらします。
TLSの仕組み
TLSは、クライアントとサーバーがプロトコルパラメータについて合意し、サーバーの認証を行い、共有セッションキーを導出する「ハンドシェイク」から始まります。ハンドシェイクの後、アプリケーションデータは暗号化され、完全性が保護されたレコードとして送信されます。
- クライアント・ハロー:クライアントがTCP接続を開き、サポートしているTLSのバージョン、暗号スイート、および鍵交換情報を送信します。
- サーバーのHelloメッセージと証明書:サーバーはパラメータを選択し、クライアントがその身元を確認できるよう、自身の証明書を送信します。
- 証明書の検証:クライアントは、証明書が信頼できる認証局に連鎖していること、有効期限が切れていないこと、および要求された名前と一致していることを確認します。
- 鍵交換:双方が一時的な鍵交換を行い、ネットワーク上で送信することなく、同一のセッション鍵を導出します。
- 暗号化されたアプリケーションデータ:エンドポイントはネゴシエーションされた暗号方式に切り替わり、保護されたレコード内でアプリケーションデータを交換します。
RFC 8446で定義されているTLS 1.3は、ハンドシェイクを短縮し、古くて脆弱なアルゴリズムを排除しています。相互TLSではクライアント証明書が追加されるため、サーバー側もクライアントを認証できるようになります。上記の手順は、一般的なサーバー認証のケースを示しています。
TLSに関するよくある問題
更新されずに有効期限が切れた証明書は、ブラウザの警告やAPI呼び出しの失敗を引き起こし、その多くは予期せぬ時間帯に発生します。ロードバランサーや管理インターフェースなど、エンドポイントの多いサービスは、見落とされがちです。
自身の証明書のみを送信し、中間証明書を省略するサーバーは、一部のブラウザでは正常に動作しますが、コマンドラインツール、Javaクライアント、および組み込みデバイスでは失敗します。複数のクライアントタイプでテストを行うと、この差異が明らかになります。
クライアントは、要求されたホスト名が「サブジェクトの別名(SAN)」フィールドに含まれていない場合、証明書を拒否します。これは、IPアドレスや、証明書の対象外である新しいエイリアスを介してサービスにアクセスした際に、よく発生します。
TLS 1.0 または 1.1 のみをサポートする古いクライアント、あるいはクライアントが提示する暗号スイートを無効にしているサーバーでは、ハンドシェイクエラーが発生します。パケットキャプチャでは、通常、クライアントヘローの直後にアラートが表示されます。
ファイアウォールがTCPポート853をブロックすると、DNS over TLSクライアントは接続に失敗するか、暗号化されていないDNSにフォールバックします。その結果、クライアントの設定に応じて、ホスト名の解決に失敗するか、暗号化が気付かれないまま失われるかのいずれかになります。