この記事はNTTドコモソリューションズ Advent Calendar 2025 5日目の記事です。

2025/7/1に社名変わりましてNTTドコモソリューションズの小田です。
IPS/WAFなどセキュリティ製品の地道な運用やってます。
製品の仕様に詳しくなれることが楽しく、それを年1このようにアウトプットできるのがうれしいです。

何故復号して検査することを疑問に思うのか

TLS1.3の公式リリースが2018年。
ネットワーク機器ではDraft版が試験的にサポートされたものの、まともに利用できるようになったのはコロナの頃。
意外と最近じゃないでしょうか。
昔は、クライアントのネットワーク環境（データセンタ）からインターネット方向の通信に対するTLS1.3通信は、性能面から推奨されない場合もあり、復号化しない理由の1つに充分なっていました。さらには、

1.　復号対象外にできない可能性があった
　　　アクセスできない！と、クレームへ。
2.　URLフィルタができない可能性があった
　　　悪性な通信先が素通り。

といったことで「いやぁ、無理だなぁ」と思ってきました。
が、最近のご時世的にダメですというのも変だし、できる理由を考えねば。

その考えたこと書いていきます。

ご時世的って？

今時TLS1.3使えない理由って何？と聞かれる
　正直、自分でもそう思う。
単純に復号する側の上限が1.2だったことはもう理由にならない。
TLS1.3が使えない=実質TLS1.2のみ　いいの？
世の中のWebサイトは大体TLS1.2/1.3の両方をサポートしており「困らない」よ。
TLS1.3のみを待ち受けるサイトなんてURだし、そのせいでアクセスできないなら個別対処でいいでしょう。
と思ってきたものの、最近SSRくらいになってきたというフィールドの肌感。
（サイトを調べてみたところまた1.3のみ対応）
TLS1.2って安全？
TLS1.1/1.0などが廃れた理由は、それ自体が脆弱性を持っていたから。
だからTLS1.2/1.3を使いましょうとなっていますが、1.2もまま脆弱性はある。
変という話ではないものの、急に使うなとお達しがでたら対応が大変かもしれない。

できる理由

を頑張って考えるのが~~サラリーマン~~エンジニアだよと奮い立たせて変化に対応します。

理由1：最近はSNIがデフォルトでついてくるから。

SNIとは、「このドメインにアクセスしたいよ。」と明示的にクライアントが発信するTLSヘッダ。
hostnameをHTTP body部でなくTLSのネゴシエーションの段階で伝える機能。

ブラウザは最新の機能を（良くも悪くも）情勢に応じて採用してくれるのでケアしなくていいのですが、組み込み系・アプリケーション・モバイルアプリではTLSライブラリのバージョンが古く、SNIがデフォルトで付加されない場合がままありました。
今はそんな古いライブラリバージョンを使うこともないし、意図的に no SNI をしている開発者もいないでしょう。

理由2：SNIを暗号化されるケースは防げる

SNIが付加されていても、暗号化されてはドメイン情報で復号除外判定することができません。
※復号するポリシーの上位には復号させないポリシーを定義しているという前提
TLS1.3では　Encrypted SNI　ということでSNIを暗号化することがあるのですが、これを実現するための条件がそれなりにあるので、企業ユースであれば条件を満たすようなインフラは作っていないでしょう。
他にも　Encrypted Client Hello　による暗号化もありますが、同じく企業ユースで暗号化の条件を満たすのは大変です。
※パブリックDNSを利用するなど、シンプルなネットワーク構成だと簡単に条件を満たしてしまうことがあります

理由3：サーバ証明書を暗号化されても大丈夫

SNIが無い・暗号され読めずともサーバ証明書のCNで接続先ドメインを判定する場合もある（モノによる）わけですが、TLS1.3仕様により暗号化され判別できません。

TLS1.2以下で暗号化されていないとしても、CNでなくSANsにドメインを記載する運用をされていたらもうどうしようもありません。（CNだけでなくSANsも見てドメインを判別してくれてしまうと、それこそマルチドメイン証明書特有の何でもあり（判定対象にする）になってしまう）
復号除外の判定優先度は　SNI＞証明書　が通常であり、SNIがある限りSNIでドメインは判別できます。
※プロキシサーバで復号を考える場合（クライアント側がProxyを明示的に指定する）、平文のCONNECTメソッドでドメイン判定するから大丈夫でしょう。

（ユーザ曰く）じゃぁ使って大丈夫なの？

大丈夫でしょう。

みんなが使ってるSWG（Secure Web Gateway）でもTLS1.3使えてますよ？

TLS1.3を復号・再暗号化できるCipher SuiteはどのHW・SWGでもおよそ同じです。
そのため今のところTLS1.3を検査できるCipher Suiteは決まっており、サーバで実装すべきCipher Suiteに含まれます。
Cipher suiteに関するベストプラクティスに沿わないサイトにはアクセスできないかもしれませんが、事象としては多くない上、セキュリティ運用上好ましくない場合も多いアクセス出来なくてもいいはずです。必要なら個別に許可するしかありません。
また、ピン留め証明書、クライアント証明書を利用されていたら個別対応することは変わりません。

体制張りますから。

※急にアナログな話…安全と安心は両立しないから…
TLS上限を1.2から1.3に変えたとき、やはりアクセスできないといわれる可能性は残ります。
　・珍しいCipher SuiteしかサポートしないTLS1.3サイトの存在
　・TLS1.2で正常に復号除外されていたものがTLS1.3でネゴするようになったところ復号除外判定されなくなり、復号しようとして失敗し通信不成立（証明書で判定する場合に起きる）

問題あればすぐに他の復号除外の方法で対応できるよう事前に手順化するし、変更タイミングは早朝にしてその日1日待機しますから…（これは架空のお話…）

記載されている会社名、製品名、サービス名は、各社の商標または登録商標です。