ホットスポットでWeb 2.0は危険

Black Hat USA 2007 – ホットスポットでWeb 2.0は危険 – サイドジャッキングをデモ (マイコミジャーナル)
サイドジャッキングツール「Hamster」を試してみた (にわか鯖管の苦悩日記)

確かに。ホットスポットは馬鹿HUB(リピータ)で繋げたローカルLANと同じ状態ということか。(*1)
それなら同じアクセススポット(またはローカルネットワーク)に接続されているPCのパケットは全て覗き見できて当たり前だ。(ホットスポット提供側のセキュリティ設定にもよるが。)
ただ、これはログイン時だけではなくログイン以降もずっとSSLにしてないサービス側の問題だろう。

(*1) イーサネットの仕組みとしては銅線とか電波上をパケットが流れてる。で、受け取り側で必要なパケットを取ってね。という形。ケーブルなら、誰かのPCにつながっているイーサケーブルの途中で、皮膜を剥いて数本の銅線を自分のPCにつなげれば繋がる。昔の馬鹿HUBはこの状態。現在一般的に使われるスイッチングHUBは目的のPCにだけパケットを送るので、他人のPC向けのパケットが自分のPCへ届くことはない。本当は各レイヤーごとの話もあるのでかなりいい加減な説明だが。こんな感じ。

Reflex – DOUBLE

久しぶりにアルバムリリース。
DJ Lilyとしての活動が多かったのかな。体は一つしかないから仕方ない。
音楽はテキトーなモノを定期的に出されるより、クオリティを優先して間が開いてしまう方が良い。
米国ミュージックシーンの後追いではなく。流行も取り入れるけどオリジナルな色がある。なかなかそういう人は少ない。
オフィシャルはこちら

DELL PC alert! chipset heatsink not detected.

実家のPC、DELL Dimension 2400Cが動かなくなったので修理。「alert! chipset heatsink not detected.」

症状: チップセットのヒートシンクを固定しているピンが引っこ抜け、ヒートシンクがPCの中に転がってる状態。
対処: マザーボードを取り出し、取れたフックと付いてるフックにたっぷり半田付け。
原因: テンションがかかる場所にも関わらず、他の場所と同じ少ない半田しか付いてなかった。半田不足。明らかにDELL側のミス。
感想: これはリコール隠しだろう。明らかにDELL側のミスなのでサポートに電話でゴネれば期限切れでも無料修理になるだろうが、修理を待つ時間がないので自前で修理した。8年くらい前のDELLのタワー型は不良品だらけだったが、その後の薄型デスクトップでは特に問題は頻出していなかっただけに残念。
ノウハウ:
 必要な時間は2時間程度(私の場合)。
 必要なモノ。1.半田ごて。2.半田ごてスタンド。3.半田。4.はんだ吸取り器。5.ラジオペンチ。6.プラスドライバー。7.マイナスドライバー。8.BGM
 マザーボードまでの分解する方法。1.フタを開ける。2.取れてるヒートシンクを回収。3.マザーボード側に接続されている各種コネクタを外す。4.取れた留め金を探す。5.デジカメで本体内を撮影する。6.緑ボタンを押して電源を外す(スライド)。7.マザーボードを固定しているネジを外す(1本)。8.本体後ろ側の各種コネクタの箇所について、コネクタ脇にあるコネクタ固定用ネジを外す(4本)。9.マザーボードを乗せてる金属版)を本体ケースに固定している緑色の取っ手を引っ張る(バネ引っ掛けなので力必要)。10.CPUファンとヒートシンクを外す(外さなくてもできるが重いしバランス悪いので)。11.軍手を付け、基盤を本体後ろ面(各種コネクタある方)から本体前面(9.で外した方)にスライドさせる(結構力が必要)。12.これでマザーボード取り出し完了。13.既存の半田を取り除く。14.半田付け。以下略。

tomcat 認証化

「パスワードをダイジェスト化したBASIC認証」と「DIGEST認証」は別物。

http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#Digested%20Passwords
http://www.atmarkit.co.jp/fjava/javatips/054container008.html

筆者が確認した限り、Tomcat(Tomcat5.0.19)では現在のところ両者の併用はできないようです。
そのため、パスワードのダイジェスト化をしたうえで通信経路の安全性も確保したければ、SSL(Secure Socket Layer)を導入する必要があります。ここでは、基本認証におけるパスワードのダイジェスト化の方法について説明します。

tomcat フォームの日本語が文字化け

環境: apache-tomcat-6.0.13 + joseki-3.1
対象ページ: http://localhost/joseki/query.html

/opt/apache-tomcat-6.0.13/conf/server.xml
    <Connector server="anonymous" port="80" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443"
               useBodyEncodingForURI="true" />

/opt/apache-tomcat-6.0.13/webapp/joseki/query.html
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

/opt/apache-tomcat-6.0.13/webapp/joseki/WEB-INF/lib/joseki.jar
  org.joseki.http.Servlet
    public void doGet(HttpServletRequest httpRequest, HttpServletResponse httpResponse)
            // httpResponse.setContentType("text/html; charset=utf-8");
            httpRequest.setCharacterEncoding("UTF-8");

Google Gadget – ピンポイント天気予報 障害情報

現在、ピンポイント天気予報にアクセス不能になっています。
過去の経験からすると本日23:00頃には復旧すると思われます。

原因: サーバのIP変更。
ガジェットを置いているサーバはDynamicDNSで運用しており、サーバのIP変更に伴うDNSの伝播遅延の影響を受けます。
DynamicDNSサービス自体のDNSの更新頻度は早いので
一般的にはそれほど問題にならないのですが、
Googleサーバのキャッシュ、またはGoogleサーバが参照しているDNSサーバやそこから
DynamicDNSサービスの間までのDNSサーバの更新頻度が遅いため、
Google内からのアクセス可能になるまで1日程度時間がかかるようです。

ネットのDNSの都合なら仕方ありませんが。もしGoogleサーバ内部の都合であれば何とかして欲しい。。速度出す為に直接IPでアクセス&キャッシュしてるとか)

追記(12:30):
アクセスできるようになりました。

前回より早い。
たまたまタイミングが良かったのか。前回の時に文句を言ったのが反映されたのかも。