タグ「メール」が付けられているエントリー

宇宙からメリークリスマス

| 宇宙からメリークリスマス

24日は学校に人が少なかったです.これは授業期間が終わったからでしょうか?それともオレが採点祭を開催するから空気を読んだのでしょうか?ヴァァァーーーー.でしょうか?

さて,そんな12月24日に向けて,JAXAがきずなを経由して宇宙からクリスマスメールを送るミッションを展開していた.そして,そのメールが17時ちょっと前に届きました.ヘッダを見てみると,このあたりが宇宙っぽいでしょうか?

Received: from windssupport02 ([10.22.0.6])
	by dam02.s.tksc.jaxa.jp with ESMTP id nBO9IDSM009434
	for <yocchan 4403.biz>; Thu, 24 Dec 2009 18:22:58 +0900 (JST)
	(envelope-from KIZUNA jaxa.jp)

すごいぞ!すごいぞ!!ま.自分で自分に送ったんですけどね.ヴァァァーーーー.

200912250032追記:
なお,注意事項が微笑ましい.

※メール受信時に発生するパケット料金は「きずな」の距離とは関係ありません。

「きずな」を経由して宇宙からクリスマスメールを送ろう!|くらしに役立つ人工衛星を開発する宇宙利用ミッション本部

思うところがあって,Greasemonkeyスクリプトを書きました.参考にしたのはDeny Rakuten Newsです.

なんですかこれ?
Infoseekポイントのクリックで楽天スーパーポイントを手に入れられちゃうあれは,クリックすると勝手に楽天ショップのメルマガ登録されたりしますよね?だって,FAQに書いてあるし.

【キャンペーンやその他サービスの利用によるメルマガ配信】

各種キャンペーン(山分けキャンペーンなど)へのエントリーや、懸賞、楽天くじメール、「Infoseek メールdeポイント」掲載のスピードくじのご利用によりメルマガ配信対象となることがあります。

この場合、申し込んでいない楽天のメルマガや利用していない楽天ショップのメルマガが配信されます。

なぜ意図しないメルマガが配信されるのか? 配信されないようにするにはどうしたらいいのですか?

というわけで,メルマガ登録されること自体はいいんですが,このメルマガ配信停止が面倒くさくて泣けます.

091206_rakuten03.jpg

まずはここから楽天ショップメルマガの一覧を取得します.届いたメールのURLをクリックすると次のような画面になります.

091206_rakuten01.jpg

SSでは9件しかありませんが,ちょっと放っておくと数十件になっています.それをひとつひとつチェックボックスを外していかないといけません.これは壮絶に面倒くさいです.チェックボックスを外すだけの簡単なお仕事です.簡単なお仕事は機械にやってもらいましょう.そういうことです.

どうなりますか?

091206_rakuten02.jpg

こうなります.ページ内にあるチェックボックスをすべて外します.それだけです.難しいことは何もしていません.誤動作するかもしれないですけど,自分用なので,こんなもんで.

導入方法
Firefox3.5.5Greasemonkey0.8.20090920.2で動作を確認しています.以下のリンクをクリックすると導入できるんじゃないでしょうか.たぶん.

Deny Rakuten MailをGreasemonkey的に導入する

enjoy!

以前,GmailがReply to allを見捨てた話を書いて怒り狂ったのだが,どうやら復活したようだ.

090925_gmail_01.png

よろしい.

090925_gmail_02.png

Greasemonkeyとか拡張機能とかではなく,Labsで復活してます.わっしょーい!

もうかれこれ1ヶ月くらい前からの話になる.何やら,Labs関連の整理があったのか,本体のGmailが調整されたのかなんだか知らないが,色々と調子がおかしくなった.例えば,上部のreplyを押すと,何故かrichモードになってしまい,下部のreplyを押すとtextモードになるという不可解な動作があった.普通は,textメールにはtextメールで返信が良いでしょう.OEじゃあるまいし.今は直っているみたい.

で.もう1つがreply to allの機能.正確にいえば,これはGmailの機能ではなく,Labsの機能だったのだ.どのような機能かって,toやccに色々と入っている場合,それらに対して全てに返信するという機能です.簡易メーリングリスト的に,複数人のメアドがずらずらとccに付いているメールが回ってくることもあるでしょう.何の気なしに返信すると,送り主にしか返信されず,ccに入っていた人には返信されません.これ,去年のCSS2008直前に実際に起きた出来事.オレ,体験済(ぇ.それが,今はこの有様.

090712_gmail01.png

replyがデフォで,reply to allをデフォにすることはできなくなりました.これはLabsからその機能が無くなったからです.Labsは実験的な機能を試す場所ですので,新しい機能が増えたり減ったりは当然のことだと思います.ということはつまり,Googleにとって,この機能は不要であると判断したといえるのではないか.だって,Gmailからbetaの文字が外れて,Labsからも外されたのに,実装されてないなんて!!

なんということか!私はショックのあまり,夏風邪を召してしまったぞ!そんなことだから,androidは3gsに負けているのだよ.きっと,そうだ.いや,絶対そうだ.

まとめ:
Gmailの返信機能は送るべき相手が複数人いそうだと感じても,送り主にしか返信できないreplyがデフォで,設定変更できません.注意深く返信してください.グリモンかなんかで対応できないかなぁ・・・.

あー.そういえば,auの携帯(W53CA)もデフォは返信で,全員へ返信はアグレッシブに選択しないといけないんだよなぁ・・・.こっちの方が時代の流れなのかな?

なので、メールアドレスは現時点では楽天市場に店舗を出店しているショップにはわからないようになっているはずであり、もしもショップが楽天市場ユーザーのメールアドレスを何らかの方法で知ることができるのであれば、もうそれだけで十分に大問題なわけです。

楽天市場から個人情報がスパム業者に流出か、実名の記載された迷惑メールが楽天でしか使っていないメールアドレスに届き始める - GIGAZINE

なるほどね.これはザルでした.店舗が使うのはどうなっているのか分かりませんが,専用のソフトみたいなのでメールを送れば,注文者のメールアドレスは分からなくても送れるようになっているようです.楽天のショップから届いたメールを一部伏せて載せますね.

Delivered-To: @gmail.com
Received: by 10.220.85.210 with SMTP id p18cs316855vcl;
        Wed, 13 May 2009 08:50:13 -0700 (PDT)
Received: by 10.150.153.2 with SMTP id a2mr1396018ybe.169.1242229812796;
        Wed, 13 May 2009 08:50:12 -0700 (PDT)
Return-Path: <@nifty.com>
Received: from mxtr06c.rakuten.co.jp (mxtr06c.rakuten.co.jp [202.72.52.243])
        by mx.google.com with ESMTP id 26si326091gxk.21.2009.05.13.08.50.12;
        Wed, 13 May 2009 08:50:12 -0700 (PDT)
Received-SPF: softfail (google.com: domain of transitioning @nifty.com does not designate 202.72.52.243 as permitted sender) client-ip=202.72.52.243;
Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning @nifty.com does not designate 202.72.52.243 as permitted sender) smtp.mail=@nifty.com
Received: from armsrb108c.ap.rakuten.co.jp (armsrb108c.ap.rakuten.co.jp [172.28.246.131])
	by mxtr06c.rakuten.co.jp (Rakuten MGw 1.3.6) with ESMTP id 71FC0F42C9;
	Thu, 14 May 2009 00:50:11 +0900 (JST)
Received: from armsrb108c (localhost [127.0.0.1])
	by armsrb108c.ap.rakuten.co.jp (8.13.1/8.13.1) with ESMTP id n4DFoBc0019064;
	Thu, 14 May 2009 00:50:11 +0900
Date: Thu, 14 May 2009 00:50:11 +0900 (JST)
From:  <@nifty.com>
To: @gmail.com
Cc: @nifty.com
Message-ID: <136026988.43371242229811384.JavaMail.javamailuser@localhost>
Subject: 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit

な.CCが付けられちゃったら,すぐに分かっちゃうじゃないですかー.だめじゃーん!

NHK のITホワイトボックスという番組の第3回「メールは盗み見られないのか?」が今晩23時30分より放送予定の模様です。

杜撰な研究者の日記: NHK: ITホワイトボックス第3回「メールは盗み見られないのか?」

気付くのが遅れて,10分遅れで視聴中.「解読」っていう言葉の使い方に違和感ありありです.

最後まで見たけど,よく分からなかった.難しすぎる.冒頭の10分を見れなかったので,どういう話をしていたのかわからないんですが,メールは暗号化しないと丸見えって話だったんだろうか.S/MIMEかPGPしようって話だろうか?それ,どうやるんだろう?視聴者のターゲット層がわからないけど,YahooやMSNやGmailなどのWebメールを使うことが多い人達は,S/MIMEやPGPをどうやって使うんだろう?WebメールでPGPって面倒くさそう.

関連:
メールのセキュリティ?凄いね。帰っていいよ。 - 4403 is written
杜撰な研究者の日記: ITホワイトボックス第3回「メールは盗み見られないのか?」を見ました
杜撰な研究者の日記: RSA合成数の素因数が見つかった件のその後

200904242136追記:
第3回の放送中に出てきたNには問題があったようで,公式にその不適切さを認め,再放送では適切なNを紹介するそうです.報道番組とかだと「先週の放送で不適切な表現がありました.謹んでお詫びいたします」とか言って終わっちゃいそうなところですが,再放送に合わせて作り直してくる辺り,職人気質っぽいです.関係ないけど,民放で再放送って,少なくなりましたよね.

ホッテントリメーカで77usersです.ちょっとメールのセキュリティについて,軽く説明してみようかと思います.ちなみに,spamメールについては一切触れる予定はありませんので,あしからず.

パスワードを守るAPOP
メールを受信するためのプロトコルとして,POP3があります.POP3とはPost Office Protocol version 3の略でして,メールサーバからメールを取り出すためのプロトコルです.メールを取り出すプロトコルですので,誰でも彼でも使えてしまっては,自分宛のメールを他人に読まれてしまいます.そのため,メールを取り出す際の認証が必要になる.しかしながら,POP3は認証時のパスワード暗号化を提供しません.これはつまり,パスワードが平文で流れることを意味します.HTTPでいうところの,Basic認証に相当します.そのため,通信路上で盗聴が行われるとパスワードはばれてしまいます.これは結構イヤな感じです.イヤな感じですが,HTTPではBasic認証が未だに用いられていることを考えれば,大した差はないといえば無いような気がしますが・・・.

さて,そんなパスワードが平文で流れてしますPOP3の認証を安全にするプロトコルがAPOPです.APOPについては杜撰な研究者さんが書かれているので,まま引用.

APOP とはAuthenticated POP のことで、POP のようにパスワードを生でやりとりするのではなく、APOPサーバから送られたチャレンジ(乱数)に対し、ユーザはチャレンジとパスワードの連接のハッ シュ値をサーバに送り返すことで、安全なパスワード認証を実現しています(ただしメイル本文は平文のままです)。

杜撰な研究者の日記: APOP

ここで説明されているとおりです.つまり,HTTPでいうところのDigest認証に相当します. APOPによって,パスワードが平文で流れることがなくなることはお分かり頂けると思います.これで安心!ではないんです.昔はこれで安全だったんですが,APOPに用いられているハッシュ関数であるMD5の危殆化によってパスワードが復元されるという攻撃を受けてしまいます.このAPOP上におけるMD5コリジョン攻撃はLeurentやSasakiらによって,ほぼ同時期に行われているという話も,杜撰な研究者さんが詳しくされているので,繰り返しません.この問題に対して,2007年の話になりますが,IPAは以下のような注意喚起を行っています.

独立行政法人 情報処理推進機構(略称:IPA、理事長:藤原武平太)は、メールの受信に利用される認証方式の一つであるAPOP(エーポップ)方式におけるセキュリティ上の弱点(脆弱性)に関する注意喚起を2007年4月19日に公表しました。

(中略)

プロトコル(通信手順)上の問題であり、現時点で根本的な対策方法はありません。

回避方法は「『POP over SSL』や『ウェブメール』など、SSLによる暗号化通信を利用する」ことです。回避方法が取れない場合「メールのパスワードを他のシステムのパスワードと同一にしない」ことで悪用された際の被害を軽減できます。

情報処理推進機構:情報セキュリティ:脆弱性関連情報取扱い:APOP方式におけるセキュリティ上の弱点(脆弱性)の注意喚起について

ということで,APOPはパスワードを通信路上に平文で流すことなく認証が可能なプロトコルですが,ハッシュ関数の危殆化によって,その安全性に問題が発生したのでした.

通信路ごと暗号化してしまえPOP over SSL
そこで,次の話です.IPAでも回避方法としてあげている,over SSLです.これは簡単で,POPをSSL化してしまえ,えいや!というものです.これをPOP over SSLといいます.POPSと呼ばれることもありますが,一般的かどうか・・・.これはHTTPでいうところのHTTPSに相当します.これは最早,SSLで通信路が暗号化されますので,パスワードが平文で流れる云々もなにも,メール本文すらも暗号化されて通信路を流れます.当然,SSLの安全性に依存します.POP3やAPOPに比べて,POP over SSLが如何に安全になるかは,@ITの表がわかりやすいと思います.これで,通信路上での盗聴の問題は解決しました.

とは問屋が卸さない.やはり同様にして,MD5コリジョン攻撃の問題がやってきました.先日書いた,MD5なSSL証明書の問題です.SSL証明書の問題は残りますが,これは別に,POP over SSLに特化した話ではなく,SSL全般の話なので,詳しくは触れません.そういうことがあるという話だけ.

ちなみに,IPAの回避方法でも述べられていますが,案外Webメールは安全です.通信路がSSLで暗号化されている的な意味で.GmailならHTTPSで接続されると思います.注意しないとHTTPで通信してたりするけど.素のPOP3やAPOPを使うくらいなら,HTTPSなWebメールの方がいいかもしれません.HotmailとYahooメールはSSLにならないなぁ・・・.優しくないなぁ・・・.

こうしてメールのセキュリティは確保されました?
これで,クライアント-サーバ間の通信路の安全性は守れられました.パスワードも安全そうです.良かった良かった.で終わらないから,このエントリを書いているんです.では,どこがダメなのでしょうか?クライアント-サーバ間が安全になったにも関わらず・・・.

そうです.サーバ-サーバ間の通信が安全ではありません.もっと言えば,サーバが安全ではないかもしれません.そうです.APOPでパスワードの安全性は確保されますが,メール本文の暗号化はされません.POP over SSLは通信路上において,メール本文も暗号化されていますが,メールサーバ上では暗号化されていません.これは何を意味するかと言えば,サーバ-サーバ間の通信においては,メール本文が平文で流れていること,そして中継に利用されたメールサーバはメール本文を平文で見ているという点です.厳密には,普通のテキストが流れているわけではなく,BASE64などのエンコードがかかった状態で流れていますが,符号化は暗号化ではないので,平文と考えて問題がありません.

つまり,メール本文は暗号化しない限り,平文で流れます.メール本文は暗号化しない限り,平文で流れます.重要なことなので,2回書きました.

メールを暗号化するPGPとS/MIME
メール本文を暗号化しない限り,安全にならないのであれば,暗号化すれば良いんだ.簡単なことです.そのソリューションを提供するのが,PGPS/MIMEです.PGPはPretty Good Privacyの略で,公開鍵暗号方式を用いていますが,Web of Trustと呼ばれる仕組みによって,信頼を得る方式になっています.対して,S/MIMEはSecure/MIMEの略で,公開鍵基盤(PKI)アプリケーションです.この2つの方式の大きな差は,公開鍵の信頼性をどのように保証(確認)するかという違いです.この2方式の差も,今回書きたいこととは直接関係がないので,詳解は避けます.

結論だけ言いますと,PGPやS/MIMEを利用することで,メールを暗号化することができます.それだけではなく,ディジタル署名を付けることもできます.これによって,盗聴の脅威を防ぐだけではなく,メール本文の改ざんを防ぐこともできますし,送信者の否認を防止することができます.こうして,メールは安全になりました.

はて?あなたは今までに1度でも,PGPやS/MIMEによって暗号化されたメールを受け取ったことがありますか?無いのではないでしょうか.ボクは学生時代に「試して見たがり衝動」で,PGP暗号化/署名を試しています.S/MIMEも第四種オレオレで良ければ,院生時代に試しています.でも,それだけです.「試してみた」レベルです.何故,このようなセキュリティソリューションが利用されないのでしょうか?300字以内で答えなさい(配点:70).

ちなみに,電子メールに署名を付ける人は少なからずいます.これはメール送信者のセキュリティ意識の高さを示していると言えるでしょう.しかしながら,何故かそのような人においても,暗号化されたメールは送ってきません.何故なのでしょうか?200字以内で答えなさい(配点:30).

ちなみに,MUFGのメールにはS/MIMEの署名がついていますGmail S/MIMEというFx用のアドオンを導入すると,簡易的ながらGmail上で署名を検証できます.

090222_smime01.png

まとめ:
POP3ではパスワードが平文で流れます.APOPはそれを防ぎますが,安全ではなくなりました.POP over SSLはクライアント-サーバ間の通信をSSLによって暗号化するので,安全です.しかしながら,クライアント-サーバ間以外の通信に保証がないので,暗号化されていないメールは中継中に盗聴可能です.そのため,PGPやS/MIMEでメールを暗号化すると良いです.

何が書きたかったかっていうと,2点です.内部ではPOP3でメールが運用されています.外部からはVPN接続しないとダメなので,このネットワーク構成は安全です.っていうのは,安全ではありません.敵は外からのみ来るのではなく,内部にも存在し得ます.逆内弁慶はセキュリティ上,安全ではありません.

もう1点はGmailを否応なしに毛嫌いする人です.Googleは個人情報を集めまくっている.きっとメールも覗かれているに違いない.その証拠にメールの内容に合った広告が出るじゃないか!という主張.これ自体はその通りでしょうが,だったら平文でメールを流さないで下さいといいたい.Gmailを使わないとしても,中継サーバがメールの中身を見ていないとは限らない.Gmailだからというのはリスクの差を生みません.

プロフィール

e-m@il @ddress