音楽保存サービス：ストレージ利用は著作権侵害 東京地裁−今日の話題：MSN毎日インタラクティブ
記事タイトルを見たとき、不特定のユーザがダウンロード可能なアップロードサービスかと思ったのですが、どうもそうではなく、記事を読む限り、自分でリッピングした音楽データを自分だけがダウンロードできる状態でアップロードできるサービスのようです。
これは暴挙もいいとこでしょう。自分だけがダウンロードできるということは、著作権で認められている私的使用のための複製にあたると思われますので、何を侵害しているのか全く理解できません。著作隣接権の公衆送信権と送信可能化権は、著作物を「公衆」に向けて送信する権利ですので、自分しかダウンロードできないサービスには適用しようがないように思います。
もしこれがダメなら、Google MailやYahoo!ブリーフケースは確実にアウトでしょう。東京地裁がこんな判例を出したというのはちょっと信じがたいので、何かの間違いだったと思いたいです。
今日は東京ビッグサイトへサボり情報収集しに行ってきました。主に情報セキュリティEXPOを見ていましたが、組込みシステム開発技術展やデータストレージEXPOなども一緒にやっていたので見てきました。
日立ソフトウェアのブースの抽選会でなぜか一等が当たってしまい電波時計をもらってきました。どうせならNintendoDSなどがよかったのですが。（←おまえはいったい何しに行ったんだ？）
組込みシステム開発技術展のIPAのブースに、あのソフトイーサ代表取締役会長の登大遊氏がおられました。名刺交換させていただきちょっとお話ししてきました。気さくで物腰が柔らかい感じの方で、PacketiXについて少し教えていただきました。展示会でこんな有名人に会えるとはラッキー。
APOPに脆弱性が見つかったようです。MD5ハッシュのコリジョンを利用してパスワードを解読できるというものです。脆弱性を突くためにはman-in-the-middle attackを行う必要があるのでそれほど簡単ではありませんが、プロトコルそのものの脆弱性なので直接の対策は難しそうです。
APOPを使用するとパスワードがクリアテキストでネットワークを流れることはありませんが、メール本文は相変わらずクリアテキストで流れるので通信の秘匿という意味では十分ではありません。私の会社のメールサーバはPOP3 over SSLに対応してあるのでもうAPOPはほとんど使っていません。世の中の流れとしても、多くのISPはPOP3 over SSL(TLS)に対応してきているのでそちらを使う方がよいでしょう。
APOP方式におけるセキュリティ上の弱点（脆弱性）の注意喚起について(IPA)
Bugtraq: APOP vulnerability
日本国内のNTPサーバといえば、ひと昔前は福岡大学のサーバ(clock.nc.fukuoka-u.ac.jp, stratum 1)が標準的に使われていましたが、徐々に負荷が上がり、福岡大学のサーバ管理者の方が2ちゃんねるで過負荷を訴えるという事態になりました。
当時の記事 - スラッシュドット ジャパン | 福岡大学NTPサーバの混雑解消にご協力を
それ以降は、インターネットマルチフィードのサーバ(ntp.jst.mfeed.ad.jp, strutum 2)が使われることが多くなってきました。個人ユーザはstratum 1のサーバには同期するべきではないというのが一般的になりました。
わりと最近、NICT 公開 NTP サービスというのが出てきましたが、これがなかなかすごいです。
[Q.2-1] stratum はいくつですか？ [A.2-1] stratum 1 です。なお、基準としている時計は「日本標準時」です。
[Q.1-6] 個人ユーザですが、stratum 1 にアクセスしても構いませんか？ [A.1-6] はい、どうぞ。
すごい。太っ腹。
上の/.Jの記事で、福岡大学のNTPサーバに対するアクセスは毎秒900リクエストに達していたそうですが、
[Q.2-3] 処理能力はどのくらいですか？ [A.2-3] 毎秒100万リクエスト以上 (1Gbps ワイヤレート) です。
何というスペック。福岡大学の1000倍以上です。
私の自宅サーバも ntp.nict.jp を見るようにしました。とはいえmfeedのほうがネットワーク的に近いらしくディレイは小さいようでした。なので一概にどちらがいいとは言い切れませんが、今後はNICTのNTPサーバが日本の標準になっていきそうな感じですね。
IISのユーザ認証機能には常々不満を感じていたのですが、「IISPassword」というソフトウェアを見つけました。
IISPassword
これを使うとIISでApacheの.htaccess, .htpasswd互換のBASIC認証ができるようになります。 インストール、設定ともに簡単でサービスの停止も一度IISを再起動するだけです。また、非商用・商用ともに無償で使用することができます。
IISにも「基本認証」という機能がありそのまんまBASIC認証なのですが、こちらはWindowsのアカウントを使って認証を行います。なのでWindowsのドメインアカウントかローカルアカウントを作っておく必要があります。
また、基本認証を行うとIISのプロセスの権限が認証を行ったユーザに変わります。Unixのseteuid(2)のような状態です。認証だけを行いたい場合はこれが邪魔になることも多いのではないでしょうか。
そして、まずいことになぜかAdministratorでの認証を無効にできません。他のユーザは無効にすることができます。つまり、基本認証を使う場合Administratorで認証を試行可能なプロンプトが必ず出てしまうことになります。もうアホかと。
IISPasswordを使うとWindowsのアカウントとは関係なく認証用のユーザを作ることができます。また、IISのプロセスの権限は匿名ユーザのままになります。おそらく多くの場合はこちらのほうが使い勝手がよいと思います。
ASP(Active Server Pages)を使いたがる方々がいるので仕方なくIISを使っているサイトがあるのですがやっぱり好きにはなれません。
DeleGateでクライアント認証付きSSLリバースプロキシサーバ、いわゆるSSL-VPNの一種を構築しようとしています。
クライアント認証にはSSLクライアント証明書を使います。クライアント証明書をまともに運用しようとするとCRL(証明書失効リスト)を使わないといけません。
DeleGateはCRLを読み込めるのですがかなりハマりやすい手順なのでメモしておきます。
OpenSSLで以下のファイルを作成します。作り方は検索すればすぐに見つかるのでここで書くこともないでしょう。これらのファイルを /var/spool/delegate-nobody/lib に置きます。
server-key.pem: サーバの秘密鍵 server-cert.pem: サーバ証明書 cacert.pem: CAのルート証明書 crl.pem: CRL
ここからがハマりポイントです。サーバの秘密鍵、サーバ証明書、CAのルート証明書はsslwayのオプションで指定できるのですがCRLのファイル名を指定する設定項目はありません。
CRLを読み込ませるには以下のようにハッシュ値をファイル名としたシンボリックリンクを作成しておきます。拡張子も忘れずに付けます。
ln -s cacert.pem `openssl x509 -in cacert.pem -hash -noout`.0 ln -s crl.pem `oepnssl crl -in crl.pem -hash -noout`.r0
DeleGateの設定例を書いておきます。DeleGateをSSLリバースプロキシとして、webserverに素のHTTPで接続する構成を考えます。
delegeted -P443 \ SERVER=https \ FCL='sslway -key server-key.pem -cert server-cert.pem \ -CApath /var/spool/delegate-nobody/lib -Vrfy -crl_check' \ MOUNT='/* http://webserver/*' \ PERMIT='http:{webserver:80}:*'
-Vrfyはクライアント証明書の提示・認証を強制するオプションで、-crl_checkはCRLを読み込むオプションです。-crl_checkはマニュアルのどこを見ても書いてありませんので注意。
以下愚痴
企業で自己署名証明書なんか使いたくないなあ。
ちょっとはセキュリティに金かけろよ。
