DNS・TCP・TLS・HTTPの順序

利用者がhttps://shop.corp.example/ordersを開くとブラウザは『接続は安全』と表示しました。それだけで受注APIとの通信がすべて暗号化され、業務操作も成功したと言えるでしょうか。DNS、TCP、TLS 1.2/1.3のハンドシェイク、証明書、HTTPの要求・応答、TLS終端位置を一つの接続で追います。

読む順序は、用語→実際の構成と処理→記録の照合→異常の成立条件→変更・復旧→短答演習です。以下の組織、アドレス、時刻、識別子、ログは教材用の架空例です。観測できた事実と、追加調査が必要な推論を分けて読みます。

1. 用語をこの事案の判断に結び付ける

用語	意味とこの事案での判断の限界
HTTP	メソッド、ターゲット、ヘッダ、本文、状態コードで要求と応答を交換するアプリケーションプロトコル。200はHTTP応答であり、TLS検証や業務上の注文成功を単独で示さない。
HTTPS	https URIに対するHTTP通信をTLS等の安全なチャネルで保護する方式。この例はTCP 443上のTLSを使う。HTTP/3のQUICなど他の転送形態もあり、HTTPSが常にTCPとは限らない。
TLSハンドシェイク	クライアントとサーバが対応版、暗号方式、鍵合意、サーバ認証などを行い、アプリデータの保護に使う鍵を確立する段階。TCP接続成功とは別。
ClientHello	クライアントが対応TLS版、暗号方式、鍵共有の候補、SNI、ALPN等を提示する。提示した版・方式が最終合意されたとは限らない。
ServerHello	サーバが版、暗号方式、鍵共有の選択を返す。TLS 1.3では後続の多くのハンドシェイクメッセージが暗号化される。
サーバ証明書	公開鍵と名前を認証局の署名で結び付ける。クライアントは信頼連鎖、期間、用途、接続先名との一致などを検証する。有効な証明書でもアプリの安全性は保証しない。
SNI	ClientHelloで接続したいサーバ名を伝え、共有IP上の証明書や設定選択に使う。通常のSNIは見える場合があり、暗号化された通信内容と同一ではない。
ALPN	TLSでHTTP/1.1やh2などのアプリプロトコルを選ぶ拡張。TLS 1.3の選択結果は暗号化された後続メッセージ内に入るため、外部の受動観測点から常に読めるとは限らない。
TLS終端	この例ではLB-1がブラウザとのTLSを終え、APP-1へ別接続を作る。利用者→LB-1が安全でも、LB-1→APP-1の保護は別設定・証拠で確認する。

2. 構成と判断する位置

ブラウザC-41はshop.corp.exampleを203.0.113.20へ名前解決し、LB-1のTCP 443へ接続します。LB-1はshop.corp.exampleを含む証明書を提示し、TLS 1.3とALPN h2を合意します。ブラウザはGET /ordersを送り、LB-1はAPP-1（10.20.5.20）へ別のTLS接続で転送する設定です。

古い端末C-42はTLS 1.2までしか使えないため、LB-1は保守対象のTLS 1.2設定でも受けます。ただしこの例ではTLS 1.2のRSA鍵交換は許可せず、ECDHEを使う方式だけに限定します。設定変更時にはC-42の対応可否と業務影響を調べます。

DNS・TCP・TLS・HTTPの順序

この事例のHTTPSはTCP上のTLS 1.3。LB後段は別接続。

図は概念的な順序です。実際のTLS 1.3ではサーバの証明書はServerHelloと同じ平文の一塊ではなく、鍵共有後の暗号化されたハンドシェイクで送られます。図の『ServerHelloと証明書』は複数メッセージをまとめた表示です。HTTPはブラウザがTLSの検証を成功させてから送ります。

3. 正常時の処理と管理

ブラウザがDNSでLB-1のIPを得てTCP 443を確立する。DNS応答やTCP成功だけではLB-1の身元確認は終わらない。
ClientHelloでsupported_versions、cipher_suites、key_share、SNI、ALPN等を送り、LB-1がTLS 1.3の方式を選ぶ。
LB-1が鍵共有と証明書等を送り、ブラウザが信頼連鎖、shop.corp.exampleの名前、有効期間等を検証して双方のFinishedを確認する。
保護されたチャネル上でGET /ordersが送られ、LB-1がAPP-1へ別TLS接続を張って転送する。APP-1からの応答をLB-1がブラウザへ返す。
ブラウザ、LB-1、APP-1のログをrequest IDで結び、TLS合意とHTTP・業務結果を別に確認する。

TLS 1.2でも通常のFull HandshakeではClientHello、ServerHello、証明書、鍵交換、Finishedなどを交換しますが、方式によって詳細が異なります。TLS 1.3は鍵合意と暗号スイートの設計を整理し、静的RSA鍵交換を使いません。どちらの版でも、サーバ名の検証を無効化すれば偽サーバを受け入れ得ます。

4. 設定・記録のフィールドを読む

項目	読み方と注意点
tcp_connect	IPとポートへの到達。TCP 3ウェイハンドシェイク成功でもTLSは失敗し得る。
supported_versions / selected	ClientHelloで提示した版とServerHelloで選ばれた版。TLS 1.3 ClientHelloのlegacy_versionだけで実際の版を判定しない。
cipher / key_share	AEAD等の保護方式とECDHE鍵共有の選択。TLS 1.2では暗号スイート名に鍵交換方式が含まれる場合がある。
sni / certificate SAN	選択した証明書と接続先名。SNIは入力であり、証明書の名前一致検証に代わらない。
alpn	h2またはhttp/1.1などの合意。ALPNがない/失敗した場合のアプリプロトコルは設定次第。
alert / verify_error	handshake_failure、unknown_ca、name mismatch等、失敗した段階を区別。LBログとブラウザ表示の粒度が異なる。
upstream_tls / request_id	LB-1→APP-1の別TLS検証とHTTP転送を確認。外側TLSの成功だけで後段が保護されたとは言えない。

次は架空のブラウザ、LB-1、APP-1のログです。TLSログのフィールド名は製品依存であり、ここでは意味を読みやすく簡略化しています。

text

12:00:00 C-41 tcp dst=203.0.113.20:443 result=ok
12:00:00 LB-1 tls sni=shop.corp.example
  selected=TLS1.3 cipher=TLS_AES_128_GCM_SHA256
  alpn=h2 cert_name=shop.corp.example
12:00:01 C-41 cert_verify=ok tls_finished=ok
12:00:02 LB-1 http id=R-41 method=GET path=/orders
  upstream=APP-1 upstream_tls=ok status=200
12:00:02 APP-1 id=R-41 business=orders_view
  result=success

この一連のログから、C-41とLB-1のTLS 1.3、ブラウザ側の証明書検証、GETの到達、LB後段TLS、APP-1の一覧表示成功を個別に確認できます。ただしGET /ordersは注文の登録ではありません。外部の受動センサーは暗号化されたTLS 1.3の証明書やHTTPパスを通常そのまま読めず、LBやブラウザのログを使います。

5. 異常が成立する条件と証拠

状態・攻撃	成立条件、証拠、対策の位置
偽サーバ	DNSや経路を誘導できても、ブラウザが証明書名と信頼連鎖を検証すれば偽の証明書は拒否される。検証無効化や信頼CAの不正追加があると危険。
弱い版へフォールバック	古い端末のためTLS 1.2を残すと対象面が広がる。許可する方式、版、利用者数を評価し、古い方式を安易に追加しない。
証明書期限切れ	TCPは成功してもブラウザがTLSを拒否。更新時のSAN、チェーン、LBの配布、失効と戻し方を確認する。
LB後段の平文	ブラウザ→LB-1だけTLSでもLB-1→APP-1がHTTP平文なら内部区間は暗号化されない。後段TLS設定と実接続を確認する。
誤ったSNI	共有IPで別の証明書や仮想ホストへ送られる。SNI、証明書SAN、HTTP Host/authorityの整合を確認する。
0-RTT再送	TLS 1.3の0-RTT早期データはリプレイに注意が必要。注文登録のような状態変更には受け入れない方針とし、通常ハンドシェイク完了後に処理する。

HTTPSは通信路の機密性・完全性と接続先の認証に関わりますが、ブラウザへ返されたページの業務内容が安全か、ユーザーが正しい注文をしたかまでは保証しません。アプリの認証・認可、入力検証、Cookie設定、XSS対策は別に必要です。

6. 調査で結論を強くする順序

判定段階	必要な証拠と結論の上限
名前解決	DNS応答と接続先IPを確認。DNSが誤ってもTLSの名前検証が適切なら偽サーバは通常拒否される。
TCP到達	SYN/SYN-ACK/ACK、FW、LBの待受を確認。TCP成功はTLSやHTTPの成功を示さない。
TLS合意	提示/選択版、cipher、SNI、証明書検証、Finished、失敗alertを確認。ClientHelloだけで成立としない。
HTTP到達	LBのrequest ID、method、path、status、APP-1の対応ログを照合。TLS成功でもHTTP 4xx/5xxになり得る。
業務成功	注文登録なら注文IDとDBコミット等が必要。HTTP 200の一覧表示とは別の操作として確認する。
経路全体の保護	C-41→LB-1とLB-1→APP-1を別のTLS接続として検証。LBがHTTP内容を見られる信頼境界も明示する。

TLS 1.3のClientHelloにはsupported_versionsで対応版を示します。legacy_versionにTLS 1.2相当の値があっても、それだけで『TLS 1.2接続』とは言えません。実際の合意版はServerHello側の選択と接続ログで確認します。暗号スイート名だけで証明書の名前検証や後段通信の保護を判断しません。

サーバ証明書の検証は『公開鍵がCA署名された』だけで終わりません。接続するshop.corp.exampleがSANに含まれるか、有効期間と用途が合うか、信頼する発行者へつながるか、失効方針がどうなっているかを確認します。利用者が警告を無視して進める運用は偽サーバへの耐性を下げます。

TLS 1.2ではRSA鍵交換を使う構成もありましたが、この例のLB-1はECDHEに限定します。TLS 1.3では静的RSA鍵交換を廃し、鍵共有からセッション鍵を導出します。古い秘密鍵が後で漏れても、過去通信を復号しにくい性質は鍵交換方式や鍵管理の条件に依存するため、単に『TLSだからPFS』とは書きません。

TLS終端のLB-1はHTTPのpath、Cookie、本文を見られます。LBログやWAF検査には利点がありますが、そこで平文が扱われるため管理者権限とログへの秘密情報の出力を制限します。APP-1への再暗号化は別のTLS接続であり、LB-1がAPP-1の証明書を検証する設定まで必要です。

TLS 1.3の0-RTTは対応する再開接続で早期データを送れる選択機能ですが、通常のハンドシェイクと同じリプレイ耐性を持ちません。GETのように副作用がないと設計された操作でも実装を確認し、注文登録や支払変更を0-RTTで受けないようにします。この事例のC-41は0-RTTを使っていません。

7. 変更・障害・例外運用

運用場面	崩れやすい条件と確認
証明書更新	新証明書のSAN、チェーン、鍵、LB設定を事前確認し、切替後にブラウザと監視で検証。期限切れ前に戻し方も用意する。
TLS版変更	利用端末の比率を測り、古い方式を段階的に廃止。互換性のための例外は対象、期限、責任者を限定する。
LB移設	DNS、SNI、証明書、ALPN、LB→APP-1のTLS、ヘッダ、監視点を一組として移す。
障害時の迂回	LB障害でAPP-1へ直接接続させるなら、APP側の証明書と認証・FWも必要。平文へ落として復旧としない。
TLS復号監視	復号装置を入れるなら証明書信頼、管理権限、プライバシー、除外、性能とログを設計する。

証明書の自動更新が成功しても、LB-1へ新しい証明書が配布・選択されたかは別です。共有IPに複数の名前があるなら、SNIごとに接続試験を行い、C-41/C-42の両方で選択版とALPNを確認します。

8. 封じ込めと復旧条件

HTTPS障害の段階別切り分け

1. TCP：対応 443への到達確認／確認する証跡 FWとLBの接続
2. TLS：対応版と証明書を検証／確認する証跡合意とalert
3. HTTP：対応要求と応答を照合／確認する証跡 request ID
4. 業務：対応注文処理を確認／確認する証跡操作とDB記録

TCP、TLS、HTTP、業務処理の順に観測する。

図は障害の所在を探す順序です。TLSで失敗した場合はHTTP要求がLB-1へ届かないため、APP-1のアプリログに何もないのが自然です。HTTP 200が出ても注文登録の成功は別に調べます。

C-41/C-42の接続先、DNS、TCP、LBのログを保全し、どの段階で失敗したかを分ける。
TLS失敗なら合意版、SNI、証明書SAN・期限・チェーン、ALPN、alertを確認し、変更履歴と照合する。検証無効化を暫定策にしない。
LB-1→APP-1の別TLSとFW、名前検証を確認し、外側TLSだけ正常な部分障害を見落とさない。
修正後にC-41/C-42でTLS合意、GET /orders、注文登録、APP-1のDB記録を試験する。旧方式の例外と期限を記録する。
監視で証明書期限、失敗率、選択TLS版、後段TLSの検証結果を追い、責任者が業務再開を承認する。

TLS障害を回避するためにブラウザの証明書警告を無視させたり、HTTPへ戻したりすると、接続先認証や通信保護を失います。原因を特定して正しい証明書・設定へ直し、受注業務の正常処理まで確認します。

9. 科目B（午後）の解答手順

パケットやログでは、DNS→TCP→ClientHello/ServerHello→証明書検証→Finished→HTTP要求→アプリ処理を順に追います。『成功』という語がどの層の成功かを必ず明示し、LBでTLSが終わるなら後段の保護を別に答えます。

提示版と合意版を区別する。
TCP接続とTLS成立を分ける。
証明書名検証と単なる証明書提示を分ける。
LB前段と後段のTLSを分ける。
HTTP応答と業務操作を分ける。

10. 短答演習

演習1：TCP成功

条件：C-41が203.0.113.20:443へ接続。

質問：HTTPS成功か。

解答：未確定。TLSとHTTPの結果を見る。

誤答の理由：TCP接続をTLS・HTTP成立と混同している。

演習2：legacy_version

条件：ClientHelloのlegacy_versionは0x0303。

質問：TLS 1.2で確定か。

解答：確定しない。supported_versionsとServerHelloの選択を見る。

誤答の理由：互換性用のフィールドを合意版とみなしている。

演習3：証明書

条件：CA署名は有効だがSANがshop.corp.exampleと不一致。

質問：接続を受理すべきか。

解答：拒否する。接続先名の検証が失敗。

誤答の理由：署名有効だけで名前の一致を省いている。

演習4：後段

条件：C-41→LB-1はTLS 1.3。

質問：APP-1まで暗号化確定か。

解答：未確定。LB-1→APP-1を別に確認する。

誤答の理由：TLS終端を見落としている。

演習5：HTTP 200

条件：GET /ordersが200を返す。

質問：注文登録成功か。

解答：いいえ。一覧表示であり注文操作とDB記録は別。

誤答の理由：HTTP状態と業務結果を混同している。

演習6：0-RTT

条件：状態変更POSTを0-RTTで受ける設定。

質問：何を懸念するか。

解答：リプレイによる重複処理。通常ハンドシェイク後に処理する方針を検討。

誤答の理由：早期データを通常データと同じ耐性とみなしている。

11. 一次資料

RFC 8446：TLS 1.3

RFC 5246：TLS 1.2

RFC 9110：HTTPとhttps URI

RFC 6066：SNI

RFC 7301：ALPN

HTTP・HTTPS・TLS 1.2/1.3とハンドシェイク