Hobby::.NETの最近のブログ記事

Forms.Formでアプバーっぽくできたのは昔の話。

今度はWPF。
Forms.Formと同じでできると思ったら、できねぇでやんの。

WPFのListBoxとかでキーボード操作を想定したときに困るのが、Clickイベントが無いことだったりする。

でも、キー入力を確認してEnterキーなら処理を・・・なんてやるのは面倒だ。

正しいかどうか分からないが、埋め込みTwitterの取り込み処理と、そこからデータをDOM操作する処理を初回BackgroundWorkerでやってたのだが、BackgroundWorkerだとそのオブジェクトを生成するのに時間が掛かるらしい。
＃確かなことは分からないが、デフォルトドキュメントのカウンタログを見ると、/ と /index.htmlとの間に最大で5秒以上のタイムラグが発生しているらしい。

そこで、BackgroundWorkerをやめて、ThreadPoolを使うようにした。
すると、タイムラグは1秒以内に収まるようになった(今のところ)。

プール数とリクエスト数にも依存するかも知れないけれど、まずまずの結果かな？
これで問題が出なければ、今後、ThreadPoolを使える場所ではThreadPoolを使うことにしよう。

とりあえず、方法だけ書いておくか。

IIS用のマネージモジュールで、HTMLコンテンツに対し、カウンタと一緒に書き換えフィルタ処理を入れてある。
＃フィルタを使ったマネージモジュールの創り方は、ウィジェットのサイトカウンタって文字列をクリックな。

ただ、書き換え時にいちいちrssを取りに行くと、twitterサイトが重いときとか、回線混雑のときに応答待ちが大きくなるので、定期的にメモリ上に取り込むのを別途タイマーかけてやってる。

本当にちゃんと保持できてるかは未確認だけど、一応、シングルトンクラス内でタイマー使ってるから、保持できているはずだ。

保持したrss(XML)をごにょごにょ弄って書き換えるのは、いちいちやってる・・・のは無駄だな。
＃本当なら、保持するのは書き換えに必要な加工状態のものでいいはずだよなぁ・・・ま、いいか。

OverSsl Clientのコンセプトは良いはずだ。
暗号化で安全な通信経路を保障しちゃうのは結構ありがたいはずだ。
だが、問題はいくつかある。
＃STARTTLSに対応できないのはコンセプト上、仕方ないのだが。

一番の問題は、アプリケーションの設定を変更しなければならないことだ。
この変更に対応できない場合はとても残念なことだが利用できない。
例えばWWWブラウザなどはその最たるものだ。

そして、それは、サーバーを固定指定することに起因する。
OverSsl Serverの場合は、この仕様で問題ないのだが、Clientでは問題となるわけだ。

他にも問題はあるのだけれど、この問題が解消できると、クライアントアプリケーションの設定を不要にできる可能性が出てくる。
つまり、あまりネットワークを知らない一般ユーザでも導入が簡単になる可能性がある。

http://internet.watch.impress.co.jp/docs/column/jirei/20100714_380352.html
↑この事例とそのあとの話の繋がりは少しおかしい。

無線LANの暗号化は、アクセスポイント－無線機器の間で行われるもので、通信経路全体を暗号化しているわけではない。
だから、WEPだろうがWPA/WPA2だろうが、アクセスポイントまで到達できてしまった通信は、それより先では無防備になる。
WEP解読云々は別の話である。
APで受け取ったパケットを解析すれば、無線LANの暗号化なんて、関係ないのだから。
＃だからといって、無線LAN暗号化が不要だとか、知らないAPを使っていいというわけではないので、注意。

記事の事例に限れば最も重要な解は、記事の最後の方にあるメールのSSL暗号化だ。

通信中の情報保護をするのなら、通信経路全体を暗号化する必要がある。
通信経路全体を暗号化するのならば、やはり、クライアントからサーバーまでEnd-to-Endの暗号化が保障されたほうがいい。
SSL暗号化はその一つの解で一般的だと思う。

古いクライアントアプリケーションだと、SSL暗号化通信に対応できてないものもあるので、そういう場合は、OverSsl *を使えばいいのにって話になる。
＃iOSには対応しておりませんが。

ただ、メールの場合、暗号化されたところで、所詮メールサーバーまで。
そこから先の転送(目的のアドレスのメールボックスを保有しているサーバーへの通信)が暗号化されていないと意味は薄れるわけだが。

なんか、できそうだったので、やってみた。
元ソースは過去のC/C++コード。

非同期パケットダンプがちょっと固まりやすいけれど、一応できた。
＃固まるってのは、Rawパケ採取にBackgroundWorker使ってんだけど、激しいProgressChangedによって、Form描画が詰まっちゃってるっぽい。←応急処置入れたので固まりにくくなったと思う。
あと、停止時に例外出るのは仕様。

一応、実行ファイルだけ置いておく。

OverSsl使った場合、ちゃんと暗号化されていることが、視覚的に分かるぞ。

さすがに、XP以降じゃないとダメかも。
要.NET Framework 3.5だし。
IPv6でも動くかも知れないけど、未確認。
＃IPv6ヘッダ解析はIPアドレス部分だけ入れてあるつもりだけど。
(追記)実行には管理者権限が必要です。

とりあえず、フルマネージコードでRawパケ採取できることが分かったことは収穫。

ま、PRですし、既出ですが。

まずは、OverSsl Clientをインストールして、↓こんなふうに設定を追加しますよ。

手順書は過去記事に載せてあるけど、やはりCA局を組んで、サーバー証明書を取得するのは手間であろうということで、サーバー証明書のサンプルでござる。
オレオレでござる。

OverSsl Serverで使える。
当然、IISでも使えるけどな。

FQDNは、*.sample.localになってるので、mail.sample.localとか、ftp.sample.localとか、適当な名前でどうぞ。

ルートCA証明書ととペアなので、適切にインストールすれば、そこそこ使える。

ルートCA証明書はローカルコンピュータの信頼されたルート証明機関へインポート。
サーバー証明書はローカルコンピュータの個人へインポート(パスワードはSample)。
ルートCA証明書は利用するすべてのサーバーおよびクライアントへインポート。
サーバー証明書は利用するサーバーへインポート。
＃分からなければコメントを。

公的証明機関だと、あらかじめOSに組み込まれていることが多いため、サーバー証明書の設定だけで済むのが利点。
こと暗号化通信に関して言えば、その程度の差しかない。
＃認証となると、また別の側面がある。

といっても、サポートの方だけど。
OverSsl Server / Client のサポートページを用意してみたんだけど、本当は、使用感なんかを知りたかったりする。
あと、SI(お安くしますよ)可能性について、知りたいのだけど・・・
＃証明書って買うと高いけど、小規模なら買わなくても何とかなるんですよ、ホント。

推奨する使用方法は、サーバーマシンとクライアントマシンにそれぞれインストールしてEnd-to-Endの通信暗号化なんだけど、そうじゃなくても、たとえば、サーバーマシンがLinux系だったりする場合には、リバースプロキシっぽくOverSsl Serverを間に挟んで暗号化したりもできる。
＃この挟む方法ってのはクライアントマシンでも同様なんだけどさ。

仮に既にSSL暗号化されていたとしても、そこにTCP通信があるのなら、SSL暗号化することができるので、ぜひ使ってみて欲しいんだけど・・・最近は殆どがHTTPSで済んじゃうんだよなぁ・・・
＃余談だが、認証だけHTTPSで、認証後がHTTPってのは改ざんに対しての対策になってないと思う。