前提

• この記事は2019/6/4時点の内容です。（かつ、Qrunchからの移管記事です）
• 筆者の知識不足が著しいため、内容に誤り等ありましたらコメント欄にて指摘お願いします。

記事の目的

• AzureFirewallのログを参照して
  「[SNI TLS extension was missing]のメッセージとともに通信が拒否されている！
  だけど何のことだかよくわからない！」という感じになっている人向けの内容です。
• 「メッセージの通りじゃん」となる有知識者はお帰りください。

結論

• AzureFirewallを介するTLSで暗号された通信については、
  Client Hello時にTLS拡張「server_name」が存在しない場合、通信が許可されない。
• これはAzureFirewallの意図的な動作であり、仕様である。

経緯

Azure上のVMにソフトウェアをインストールし、そのソフトウェアのライセンス認証を
オンラインで実施しようとしたところ失敗した。
↓
VMがインターネットへでる際は
「VM⇒AzureFirewall⇒インターネット」の経路を通るため、AzureFirewallのログを確認。
↓
ライセンスサーバとの通信が拒否されたログを確認。
そこに[SNI TLS extension was missing]のメッセージが出力されているが、よくわからない。
（意味もよく分からないし、何で出ているのかもよく分からない）
↓
問い合わせした結果、上述の通り仕様であることが判明。
解決策としては「ライセンス認証に関するクライアント⇔サーバ間の通信内容の設定を変える」か、
「AzureFirewallを介さないで通信する」かのどちらかになる、とのこと。

ソフトウェアのサポートと話をしたところ、
「IPアドレス単位でFirewallの許可設定をしても同事象が発生するか確認してほしい」
といわれたのでNetworkRuleコレクションのほうで認証サーバのIPアドレスを許可したところ、
事象が解消しました。
（ApplicationRuleのみ発生する事象なのだろうか）

SNI、TLS拡張「server_name」とは

• SNI（Server Name Indication）
  1つのグローバルIPアドレスで、複数の証明書を利用できるようにする仕組み。
• server_name
  SNIを実現するためにのTLS拡張。
  TLS通信を行う際のクライアント⇔サーバ間の手続き（TLSハンドシェイク）において、
  最初にクライアント⇒サーバへ「Client Hello」の要求をした際、クライアントが希望するドメイン名を平文で伝える。
  それによってサーバがドメインに対応する証明書を使えるようになる。
• 今回AzureFirewallは、クライアントからのリクエストについて、宛先ドメイン名をTLS拡張「server_name」で指定していない場合、その通信はAzureFirewallで破棄します、と言っているわけですね。
• 詳細はWikipedia参照
  https://ja.wikipedia.org/wiki/Server_Name_Indication

所感

• そもそもSSL/TLS周りの知識が無さすぎて、何のことだか全然分からなかった。
• 問い合わせまでしてしまった。
• 知識がある人ならログを見ただけで「そういうことね」となる事象なのでしょう・・・
• 勉強が足りないなぁ・・・