Transport Layer Security (TLS) is a cryptographic protocol that provides confidentiality, integrity, and endpoint authentication for data transmitted between applications over networks, with TLS 1.3 (RFC 8446) removing legacy features to ensure forward secrecy. DNS over TLS (RFC 7858) encrypts DNS queries on TCP port 853 to prevent observers from reading or altering queries, differing from DNS over HTTPS which carries DNS inside HTTP on port 443. Poor TLS management causes outages and security exposures through expired certificates, weak cipher suites, and unmanaged private keys, requiring teams to maintain certificate inventories, implement automated renewal, and enforce minimum protocol versions across all services.
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にフォールバックします。その結果、クライアントの設定に応じて、ホスト名の解決に失敗するか、あるいは暗号化が気付かれないまま失われることになります。