CloudFrontのHost Header転送設定でパケットの中身はどう変わるのか？

JAWS-UG東京 ランチタイムLT会 #33

Transcript

1. JAWS-UG 東京 ランチタイムLT 会 #33 CloudFront のHost Header 転送設定で パケットの中身はどう変わるのか？ 五味なぎさ 1
2. 自己紹介 名前：五味 なぎさ (Gomi Nagisa) 仕事：SIer クラウド関連グループマネージャー 趣味：キックボクシング、スキューバダイビング 好きなAWS サービス：NW 系サービス全般 AWS に関する活動： AWS Community Builder (Networking and Content Delivery) AWS Ambassador JAWS-UG クラウド女子会/ 彩の国埼玉支部運営 2
3. 🙇‍♀️ おことわり 本LT は、私が以前から個人的に気になっていたことを 検証し、共有する、かなり趣味要素の強い内容です。 途中「？？」となるかもしれませんが、ご了承ください🙏 また、時間の都合上詳細は割愛しているため、詳しい方から見ると別の気に なりがあるかもしれませんが、その点もご了承ください🙏 3
4. 気になっていたこと CloudFront → オリジン間HTTPS 通信においては、ビューワーリクエスト時の Host Header を転送するか否かにより、オリジンに設定する証明書のドメイン の考え方が変わる。 Host Header 転送 オリジンの証明書のCN/SAN （ドメイン）の値 なし オリジンドメイン名 あり ビューワーリクエストに含まれるHostHeader の値 （≒ CloudFront に設定するドメイン名）※P6 に補足 ※ CN : Common Name, SAN : Subject Alternative Name 4
5. 参考：公式ドキュメントの記載 出典：CloudFront とカスタムオリジンの間の通信に HTTPS を要求する 出典：オリジンの設定 オリジンから返される証明書には、次のいずれかの ドメイン名が含まれている必要があります。 オリジンのオリジンドメインフィールド （CloudFront API の DomainName フィールド）のドメイン名。 キャッシュ動作が Host ヘッダーをオリジンに転送するように 設定されている場合は、 Host ヘッダーのドメイン名。 “ “ ビューワーホストヘッダーをオリジンに転送するオリジンリクエストポリシーを使用している場 合、オリジンはビューワーホストヘッダーに一致する証明書で応答する必要があります。 “ “ 5
6. ※補足 ビューワーHost Header を転送する場合でも、オリジンドメイン名の証明書を 設定する形で通信できるケースはあるが（デフォルト証明書とCloudFront が 指定するオリジンドメイン名が一致したケースなど） 、前ページ2 点目の記載 もあるため、P4 の形で設定することが望ましいと考えられる。 また、オリジンアクセスにカスタムドメインを利用せずにAWS のデフォルト ドメイン名で接続するケースでHTTPS 通信を行う場合、利用するドメインに 該当する証明書の発行は不可のため、Host Header 転送 ＋ CloudFront と同一 のドメインの証明書を利用する形となる。 6
7. 気になっていたこと 🤔 Host Header を転送する場合、 SNI の値ってどうなっているんだろう？ 7
8. 前提知識 SNI(Server Name Indication) ： 接続先ホスト名をサーバーに伝える TLS 拡張 HTTPS 通信の流れ① TLS ハンドシェイク（TLS1.2 の場合） ステップ 送受信 内容 ① Client Hello Client → Server 対応するTLS バージョン・暗号スイートを提示 SNI で宛先ホスト名を送信 ② Server Hello Server → Client 使用するTLS バージョン・暗号スイートを決定 ③ Certificate Server → Client SNI に対応するサーバー証明書を送信 ④ Server Key Exchange 　 Server Hello Done Server → Client 鍵交換パラメータを送信 Server Hello の終了を通知 8
9. 前提知識 HTTPS 通信の流れ① TLS ハンドシェイク（TLS1.2 の場合） ステップ 送受信 内容 ⑤ 証明書の検証 Client 側 証明書のCN/SAN が 宛先ホスト名 と一致するか確認 証明書チェーン・有効期限等も検 証 ⑥ Client Key Exchange/Change Cipher Spec/Finished Client → Server 鍵交換を完了し暗号化通信を開始 ⑦ Change Cipher Spec/Finished Server → Client サーバー側も暗号化通信を開始 → TLS セッション確立 CN/SAN ：証明書が有効なホスト名を定義するフィールド 9
10. 前提知識 HTTPS 通信の流れ② HTTP リクエスト ステップ 送受信 内容 ⑤ HTTP リクエスト Client → Server Host Header でリクエスト先を指定 ⑥ コンテンツ選択 Server 側 Host でバーチャルホストを決定 ⑦ レスポンス Server → Client 対応コンテンツを返却 Host Header は TLS 確立後の暗号化通信内で利用される 10
11. 気になっていたこと 🤔 つまり、宛先ホスト名に応じた証明書を返すためには、 SNI の値も一緒に書き変わっているはず → 本当にそうだよね、を確認したい！ 11
12. これはもう パケットの中身を見てみるしかない！ 12
13. 検証の前提①：構成 👤 ユーザー ブラウザ HTTPS CloudFront ディストリビューション Host ヘッダー転送 あり HTTPS ALB 固定レスポンスで カスタムページを返却 🔍 この区間のパケットを検証 13
14. 検証の前提②：検証内容 CloudFront のポリシー設定で Host ヘッダーを転送 ALB への通信のパケットキャプチャを取得 Client Hello 内の SNI を確認 14
15. 検証の前提③：パケットキャプチャの取得方法 VPC Traffic Mirroring （ENI のトラフィックミラーリング）を使用 ALB の ENI をミラーソースに指定 ミラーターゲット：同一 VPC 内の EC2 インスタンスの ENI フィルター：インバウンド ターゲット EC2 上で tcpdump を実行しキャプチャ取得 ミラーリングしたパケットを受信するために、Inbound UDP 4789 （VXLAN ） 通信を許可 取得した pcap ファイルを Wireshark で解析 [CloudFront] --HTTPS--> [ALB (ENI)] --mirror--> [EC2 (tcpdump)] 15
16. 検証の前提④：CloudFront の代替ドメイン名 16
17. 検証の前提⑤：ポリシー設定 17
18. 検証の前提⑥：ALB に設定した証明書 CloudFront に設定した代替ドメイン名と同様のCommonName, SAN を 設定した証明書を利用 18
19. 結果 19
20. SNI も 書き変わっていることが確認できた！ 20
21. まとめ Host Header 転送 なし Host Header 転送 あり SNI オリジンドメイン名 （未記載だが別途確認済） ビューワーリクエストに含まれる HostHeader 値 Host オリジンドメイン名 ビューワーリクエストに含まれる HostHeader 値 → Host Header のオリジンへの転送を有効化すると 　 SNI も連動して書き換わることが確認できた 21
22. 🙇‍♀️ 趣味にお付き合いいただき ありがとうございました 22