SSTP周辺の仕様について、特にここ数年のSSPの拡張仕様についてあまり詳しくないので色々調べてみた。
descript.txtのsstp.allowunspecifiedsendに至ってはmateria時代からサポートされている由緒正しき仕様なのだけれども、以前色々揉めた時にあまり知られていないことがわかったりして、正しい知識を身に着けておくことは重要だと思ったので。
SSPが数年前にサポートした仕様。
SSTP SENDはどのベースウェアでも普通にOnTranslateを経由する。
しかしSSTPにはOptionヘッダにnotranslateというものを付けることが可能で、これによってSSTP送信者はOnTranslateを経由させなくすることができる。
notranslate は，IfGhost により既に対象ゴーストに最適化されたスクリプトを送信する際に，トランスレートによりセリフが不自然になるのを防ぐため，などに使用します。
http://www.ooyashima.net/db/sstp.html#option
トランスレートの用途としては語尾変化や、句読点や疑問符などにウェイトを自動挿入するというのがメジャーな使い方だと思う。
これがSSTP送信者にとっては致命的な事態になり得る。
NSPで歌わせようとした時にウェイト入れられたらズレまくるし、語尾変化も歌詞を台無しにする。
そういう事態を避けるために導入された仕様なのだろうと思う。
一方、OnTranslateは文字通りトランスレートするための仕様なのだけれども、全てのリクエストが経由するエンドポイントであることを利用して、ここでまとめて特定のSenderから投げられたSSTP SENDを無効化するために利用しよう、というアイディアが生まれた。
しかし上記で説明した通り、notranslateオプションが付けられたSSTPはこのイベントを経由しない。
そこでnotranslateオプションが付いていてもOnTranslateを経由させたいという要望が生まれた。
上記要望はSSPによってdescript.txtのsstp.alwaystranslateという形で実現された。
materiaが更新終了してかなりの年月が過ぎてからの話である。
このためmateriaやCROWなど、SSP以外のベースウェアでSSTP SENDを拒否することは事実上不可能となっている。
これは最近の更新。
OnTranslateのReference1にSSTP SENDかどうかの情報が付加されている。
前述の通り、SSPでは既にSSTP SENDを拒否するための仕組みは提供されていたのだけれども、「SenderがSSPかどうか」ではなくReference1の「SSTP SENDかどうか」で拒否判断できるようにしよう、というもの。
SSTP SENDのSenderが"SSP"に偽装されていた場合に対抗できるようになる（SenderはSSTP送信者の自己申告であるため、簡単に偽装できる）。
逆に言うと、それ以外の効用は無い。
2.2.86でより対応が容易になりました。
http://d.hatena.ne.jp/ponapalt/20120904/1346770589
これはウソだ。少なくとも「SSTP SENDをすべて拒否する」という目標に対しては。
まずSSP以外ではSSTP SENDを拒否することはできないのだからSSP以外での起動を不能にしておく必要がある。
そのあとはSSP以外を考慮する必要がない(SSP以外のSenderはSSTP SENDと考えて良い)。
＊OnTranslate ＞トランスレートSSTPSEND【タブ】！（compare、（Sender）、SSP） （Ｒ０） ＊トランスレートSSTPSEND ：何か電波が飛んできたね。 ：ワイらはSSTPには対応しとらんで。
が
＊OnTranslate ＞トランスレートSSTPSEND【タブ】（count、（Ｒ１）、sstp-send）＞０ （Ｒ０） ＊トランスレートSSTPSEND ：何か電波が飛んできたね。 ：ワイらはSSTPには対応しとらんで。
になっただけだ。容易でも何でもない。
Senderを確認することで特定のアプリケーションのみパスする実装は可能です。
http://d.hatena.ne.jp/ponapalt/20120904/1346770589
NSP等をSenderを確認して許可などしようものならSender偽装に対抗できなくなるため何の意味もなくなる。
自らセキュリティホールを開けて待っているようなものだ。
あくまでSender偽装にも対抗できるようSenderなどという不確かなものに頼らずにSSTP全拒否を確実にするための仕様が今回の追加仕様だと思っている。
SSTP SENDかどうかの判定ができるようになったというだけで、善いSSTP Senderか悪いSSTP Senderかの判定などできるはずもない。
SSTPに善いも悪いも無い。善悪はそのスクリプトを再生させた人の主観にすぎない。
今回のアップデートで何かが便利になったとか、今までできなかったことができるようになったとか、そういう宣伝がなされているとしたらちょっと危険な兆候なんじゃないかと思う。
テキトーな表現で煙に巻こうという意志が感じられる。
SSTP SENDと、SSTP NOTIFYの「保険用スクリプト」についての話ばかりが話題にされているけれど、NOTIFYのイベント部分は、使いようによっては上記のものと同等かそれ以上に危険な状況を引き起こすケースというのを個人的には想定しているのだけれども、この余白はそれを書くには狭すぎる。
また何か問題が起きてからでも遅くはないし、そうそう起こるものではないし。