SSTP と SSL 3.0：ラベルと実際に交渉されたバージョン

同じ SSTP 配備を見ても、二人は正反対の結論に達することがある。一方は製品ドキュメントを読み、SSL の文字を見て、何年も前に廃止されたプロトコルがトンネルで動いていると考える。もう一方は現代的なハンドシェイクを指して、疑問は片付いたと言う。どちらも交渉されたバージョンではなくラベルで議論しており、証拠になるのは片方だけだ。行う価値のある比較は、名前が約束するものと、サービスが実際に選ぶものの間にある。

同じ問いへの二つの答え

ラベルの議論は言いやすい。SSTP は安全なソケットトンネリングプロトコルと説明され、歴史的な名前には SSL が入っている、だから接続は SSL 3.0 に違いない。これが生き残るのは、名前が本当にその系譜から来ているからであり、繰り返す人のほとんどがハンドシェイクを一度も見たことがないからだ。さらに、結論が慎重に聞こえるからでもある。最悪を仮定することが安全な選択だというわけだ。最悪を仮定することと実際のバージョンを測ることは別の行為であり、何かを変えるのは片方だけだ。

証拠の議論はもっと狭い問いを立てる。このクライアントとこのサーバーは、このエンドポイントで、この時点で、どのプロトコルバージョンに合意したのか。答えは TLS を終端するサービスから来るのであって、マーケティングページや、似た名前のサイトに到達したブラウザからではない。

二つの議論は証明できるものが違う。ラベルは古い配備と修正済みの配備を区別できず、ハンドシェイクは同じホスト上の無関係なサービスが何をしているかを教えてくれない。後者を使い、前者を使うのはやめること。

サービスが実際に選ぶバージョンを読む

まず構成要素を名指しする。クライアント実装、サーバー実装、TLS エンドポイント、そしてその間で TLS を終端し再確立するすべてのもの。TLS を終端してバックエンドとは平文 HTTP で話すロードバランサーがあれば、読むべきはどの機器のポリシーかが変わる。

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null> | grep -E 'Protocol|Cipher'
Get-WinEvent -LogName System -ProviderName Schannel -MaxEvents 20

結果と一緒にエンドポイントと時刻を記録する。後でポリシーが変われば、日付のない観察は役に立たなくなるからだ。気にかける利用者と同じネットワーク経路にあるクライアントから再試行する。途中の傍受機器が独自の設定で TLS を終端している可能性があるからだ。二つの位置の結論が食い違えば、重要な構成要素を見つけたことになる。一致すれば、スローガンではなく証拠が手元にある。

レコードのフィールドと交渉を分けて考える

あるフィールドの古めかしいバージョン番号は、SSL 3.0 セッションと同じ事実ではない。RFC 7568 はレコード層のバージョンと交渉されたプロトコルを別の問題として扱っており、自信に満ちた誤答はまさにこの区別から生まれる。交渉されたプロトコルを読み、次に暗号スイートを読み、それから初めてセッションについて結論を出すこと。

同じ文書はプロトコル自体について明確だ。SSL 3.0 は使用してはならず、それへの交渉やフォールバックは禁止されている。理由は POODLE 攻撃が悪用した壊れた CBC 構造であり、これはプロトコルの性質であって、一つのアプリケーションの設定ではない。

だから「このワークロードは悪用が難しいだろう」は SSL 3.0 を有効のままにする理由にならない。求められているのはプロトコルを取り除くことであり、一つの実演についての議論に勝つことではない。

説明できるポリシーで SSL 3.0 を廃止する

Windows では Schannel のプロトコル設定は Protocols キーの下にあり、クライアント役割とサーバー役割で別々に読まれる。だから片方向を直す変更がもう片方をそのまま残すことがある。現在の設定と再起動の要件は Microsoft が文書化しており、同じホスト上のサードパーティ製 TLS ライブラリはそれらをまったく無視する。

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server'
Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols'

サポートされた管理経路でポリシーを変更し、所有サービスが構成を読み直したことを確認し、承認済みの戻し道を残す。別環境の広範なレジストリスクリプトを貼り付けるのは、一つのサービスの修正がマシン上のすべての TLS クライアントの停止になるやり方だ。再起動の範囲はここで効く。適用されたように見える設定が、読み直していないサービスのメモリに残っていることがある。

まだ古いバージョンを要求する相手には、更新か移行計画が必要だ。文書化されていない例外で古いプロトコルを静かに復活させるのは互換性の戦略ではなく、次の監査も持たない。

新しい接続で変更を受け入れる

ポリシー変更後は新しいセッションで試験する。変更前に確立した接続は、今有効な構成について何も証明しないからだ。許可されたプロトコルが成功し、禁止されたものが承認された検証手順で失敗することを確認し、証明書の識別と信頼の確認はそのままにしておく。

ハンドシェイクが覆わないものを忘れないこと。SSTP は TLS 層の後に PPP 認証を運ぶので、現代のプロトコルバージョンは、誰が認証されたか、セッションがどの資源に届くかについては何も語らない。それらは別の統制であり、別の証拠が要る。

結果は、サービス、バックエンド、許可されたポリシー、観測されたバージョンとして書き留める。その記録だけがセキュリティの問いに正確に答える。ラベルの議論も、面倒だという議論も、それをできない。