Scribble at 2024-04-24 09:13:05 Last modified: 2024-04-24 09:29:23

もう随分と前の話だが、何かの雑誌記事だかメディアの記事ページだかで、無線 LAN や Wi-Fi の話題で頻出する "SSID" という略語を "Session ID" の略だと説明してる人がいたのを覚えている。もちろん、これは間違いだ。正しくは "Service Set Identifier" の略であり、無線通信機器がアクセス・ポイントとしてブロードキャストしデバイスとの接続に使っている識別子のことであって、セッションなんかじゃない。

この間違いが起きる原因は、かなりはっきりしている。それは、PHP のセッション管理に関する文章で、セッション ID を URL クエリ文字列として GET 送信するという場合に、変数名に "SSID" という大文字表記を使う事例が多いからだ。脈絡で区別はできると思うが、あまり指摘する人がいないので注意しておこう。

なお、これは Wi-Fi 通信では何度も出てくる話題だが、いまどき SSID をアクセス・ポイントからブロードキャストしないようにする「ステルス・モード」なんてものをセキュリティ対策と称して実装している通信機器は信用しないほうがいい。技術力があろうと、素人の不安に訴えてそういうブゥードゥー教のような信仰を広げる会社は迷惑だ。

https://www.ntt-bp.net/column/blog/2022/06/post-84.html

それから、SSID を隠蔽してもセキュリティ対策にならないという説明にすら、間違った説明があるのも更に酷い。たとえば上のページで、アクセス・ポイントが SSID をブロードキャストしなくても子機が 「SSID を叫び続ける」から危険だなどと書いてあるが、そんなことはありえない。正しい SSID を通知していれば接続が確立するのだから、子機から正しい SSID 送信している状況でアクセス・ポイントが応答しない（にもかかわらず「叫び続ける」から危険だ）なんてことはありえないからである。そもそも SSID のブロードキャストはなくても、MAC アドレスは送信され続けているから、SSID が分からないアクセス・ポイントにも接続できるのである。もちろん、MAC アドレスの送出信号は暗号化などされていない（ハンドシェイクしていないのに暗号化されている通信を処理できるわけがないからだ）。

ついでで書いておくと、なんでセッション ID を URL にクエリ文字列として追加するのかというと、HTTP はステートレス、つまりリクエストごとにコンテクストが独立していて、或るリクエストと他のリクエストが同じ UA と同じリモート・ホストから送られていて、それが連続した一式の処理であるという関連付けができないからだ。それら複数のリクエストを連携させるためにセッションを利用するのだが、ページを遷移する場合にセッションを次のリクエストと共有するためには、セッション ID を次のページへ渡すために三つくらいのやり方がある。一つめはフォームで送信すること、二つめは Cookie に記録すること、そして三つめがクエリ文字列として URL に SSID を含めてしまうことだ。もちろん、これらにはそれぞれ一長一短があって、どういうアクションであろうとフォームの体裁をとるという融通のなさは扱いづらいので、オンライン・バンキングや問い合わせフォームなど選択肢が限られている場合を除けば、フォームとしてセッション ID を共有することはない。多くのサイトでは Cookie を使うが、ただし Cookie はクライアント側で禁止している場合があり、それを見越してエラー処理を入れるとビジネス的には機会喪失や顧客対応の手間が増える可能性がある。かといって、URL にクエリ文字列として追加すればいいかというと、これはきちんと対策しないと URL をチャットや掲示板などに貼り付ける馬鹿がいるので、第三者にセッション ID を盗まれる恐れがある。