どさにっき 3D 〜2011年11月下旬〜
by やまや
■
STARTTLS の穴
_
つづき。
_
メールの TLS 化についてここまで長々と書いた後で申し訳ないが、ちゃぶだいをひっくり返す。やっぱ、ダメだ。
_
自分のところがどんなに STARTTLS を頑張ったところで、バケツリレーの SMTP では end to end の暗号化が保証されるわけじゃないし、仮に経路上のすべてのサーバが TLS に対応していても、暗号化されるのはサーバ間の通信だけで、経由してるサーバの内部では平文でキューが処理されていて、秘匿されない部分は必ず存在する。
_
それから、HTTPS は「必ず」暗号化するけど、SMTP の STARTTLS は「可能なら」暗号化するという仕様になってるのが、実は大きな穴だったりする。サーバが TLS に対応していても、「TLS 非対応だよー」という嘘の応答を中間者攻撃で突っ込むことに成功すれば、平文でやりとりされることになって盗聴可能になってしまうから。中間者攻撃なんてそうそうあるわけじゃないけど、でもまったく存在しないことがわかってるなら暗号化する必要もないわけで、それを防御できないというのはぶっちゃけ欠陥プロトコルだ。port 465 の SMTPS だとこの穴はないんだけどね(HTTPS と同じで「可能なら」ではなく「必ず」なので。コケた後で素の SMTP にフォールバックするならやっぱり穴になる)。
_
Submission での STARTTLS は、メーラーの実装にもよるけど、STARTTLS で設定して TLS でつなげなかったらエラーになるようなものなら穴にはならない。「可能なら TLS を使う」のような設定があるメーラーは、「TLS 非対応だよー」という嘘応答を注入されると平文で送ってしまうので穴になる。
_
もちろん、パケットを書き換えずにだらーっと流して見てるだけのようなやる気のない中間者ならば十分に秘匿できるのでまったくメリットがないわけじゃないんだけど、でもやっぱり HTTPS なんかと比べるとありがたみが薄いんだな。普及しないのもしかたない。
■
S/MIME で電子署名/暗号化
_
ということで、サーバによる暗号化もないよりはマシだけど、これはほとんどアテにならない、というかアテにしてはいけない。やっぱりサーバに頼らずユーザが自分で暗号化することを考えなくちゃ、というところに戻ってきちゃう。敷居が高いんだけど。
_
せっかく個人向けの証明書があるので、TLS クライアント認証に使うだけではもったいない。S/MIME をやってみる。PGP は信頼の輪を自力でなんとかしないといけなくて、これがひじょーに手間のかかる作業だったりする。S/MIME は PKI がベースなので信頼の連鎖の形成がラクチン。信頼できるルート CA から発行された証明書による署名なら誰でも検証できるし、公開鍵がホンモノかどうかの確認が PGP よりはるかに楽なので、見ず知らずの相手でも安全に暗号化できる。
_
で、実際にやるのは S/MIME がサポートされてるメーラーなら難しくもなんともない(最近は iPhone でも使える)。StartSSL (じゃなくてもいいけど)で取得した証明書をメーラーに設定しておいて、メッセージ作成の際に暗号化なり署名なりをメニューから選択するだけだから。暗号化は相手の公開鍵を入手しないとできないけど、署名つきのメールに公開鍵は含まれてるので、暗号が必要なメールを送る前に相手にひと声かけて署名つきメールを送ってもらえば面識のない相手でも安全にやりとりできる。とってもカンタン。
_
難しいのは、S/MIME とはなんぞやを理解してもらうことと、証明書の取得に手間と費用がかかること。それから、S/MIME はその名のとおり MIME multipart なメッセージを作るんだけど、そのために最近企業内メールサーバででありがちな「情報漏曳対策のため添付ファイルを外に送るのにエラい人の承認が必要」とかいうシステムでひっかかる、という意外な落とし穴もあったりする。PGP は鍵を作るのに費用はかからないし、multipart じゃない送り方もできる(multipart な送り方もできる)のでこういう問題は起きない。PGP とはなんぞやを理解してもらうのが手間なのは変わらんけど。やっぱりこれが最大の難点だよなぁ。
_
結論。メールの暗号化が普及することはなさそうだ。どんなにがんばったところで、普及するよりメール自体が廃れていく方が先だ。
_
蛇足。Thunderbird 日本語版の S/MIME の動作がおかしい。日本語化しちゃいけないところが base64 でも qp でもエンコードされていない生の UTF-8 で日本語化されてる。そのくせ生のままでいいはずの iso-2022-jp のメール本文は qp でエンコードされてる。
From: YAMAGUCHI Takanori <y@maya.st>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: y@maya.st
Subject: s/mime test
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070702030300020407000305"
これは暗号で署名された MIME 形式のメッセージです。
--------------ms070702030300020407000305
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: quoted-printable
=1B$B$F$9$H!#=1B(B
--------------ms070702030300020407000305
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME 暗号署名
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCC
(以下略)
「これは暗号で署名された MIME 形式のメッセージです。」とか「S/MIME 暗号署名」とか、生の UTF-8 で載せたらいかんでしょ。どう考えても翻訳の問題なので、英語版を使ってれば発生しないとは思うけど。
■
FFFTP 1.98d
_
リリースノート
ホストとの接続にInternet Protocol Version 6（略称IPv6）が使用できるようになりました。デフォルトでは従来のIPv4で名前解決ができない場合にIPv6で接続を試みるようになります。
なぜ逆にする。現状ではまだ v4 の方が優勢なので気持ちはわからんでもないのだが、v6 -> v4 という一般的なフォールバックとあえて逆の順番にするほどのものとは思えない。せめて happy eyeballs (v4 と v6 を同時に接続試行し、先につながった方を使う)だろ。
■
無題
_
足利学校(日本最古の学校)
鑁阿寺の大銀杏と少年画伯
_
震災でぶっこわれた実家の修理+リフォームがほぼ完了したというので、見物に行ってきた。そのためだけに帰るのもアレなのでどっか寄り道してこうかと考えて、そういえば一度来たことがあるはずだけど、来たことがあるという記憶だけでどんなところだったかまったく覚えていない足利に。栃木の県央部の出身の自分からすると、足利はいちおう同じ県内だけど事実上群馬の植民地であるという認識で、まったく縁がないのだ。このへんを世界遺産に、とか運動をしてることを初めて知ったけど、建物のほとんどが平成に入ってから復元されたものというのでは無理でしょ。
_
で、実家の方は地震でやられたところの補修だけでは済まさずに徹底したリフォームをやったようで、なんか知らない人の家に来たような感じ。部屋の壁をぶち抜いたりして間取りがぜんぜん違ってるんだもん。壁は壊せても柱のいくつかは壊すと家が倒れるので、それを隠すように不自然なところに物入れができてたり、隠しようがなく部屋のはしっこに柱が屹立してたり、ビミョーな空間が一部にできてたけど、それを除けば新築同然の見た目。制約がある中でこんなに変えられるもんなんだね。びっくりだ。
_
もひとつびっくりしたこと。オール電化になっていた。設計したのは電気足りねぇ節電しよう東電くたばれ、という声が世間でいちばん大きかったころのはずなんだけど、それなのにガスを完全に捨てるとかずいぶんな決断だこと。うちのあたりは都市ガスがなくてプロパンのみで、ガス代のコストが高いせいもあったのかもしれないけど、それにしてもねぇ。
_
まあ、でも、最大の問題は、トイレの場所を間違えることだよな。間取り変えすぎ。
やまや