Let's Encrypt、ほかのユーザーのメールアドレスを記載したメールをユーザーに送信 20
ストーリー by hylom
うっかり 部門より
うっかり 部門より
headless 曰く、
Let's Encryptが11日、ほかのユーザーの電子メールアドレスを記載した電子メールをユーザーに送信していたことを発表、謝罪した（Let's Encryptの報告、Register）。
この電子メールは、電子メールアドレスを登録しているすべてのアクティブサブスクライバーに対し、サブスクライバー契約書の内容変更を知らせる内容で、自動送信システムにより送信された。しかし、プログラムのバグにより、前に送信した送信先が次々と本文に付加されていったのだという。問題に気付いたLet's Encryptは全体のおよそ1.9%にあたる7,618通を送信したところでシステムを停止させたが、0～7,618件（件数は原文ママ）の電子メールアドレスが記載された電子メールが送信されてしまったとのこと。
Let's Encryptでは原因を調査し、再発防止に努めるとしており、調査結果を後日発表するとのこと。また、該当する電子メールを受信したユーザーに対しては、リストを公開しないように求めている。
Let's Encrypt に対してEメールアドレスを登録しない方法 (スコア:2)
Let's Encrypt のメール配信業務は The Rocket Science Group, LLC [rocketsciencegroup.com] の Mandrill [mandrillapp.com] に一部業務委託されているようですが、今回のミスがどっちの責任で生じたのかは報告書に書かれていなかったのでよくわかりませんでした。
最終報告書 [letsencrypt.org] によると、今後は加入者の電子メールアドレスへのアクセスを持っているソフトウェアは、直接証明書の発行や管理を行わない場合であっても、コアCAソフトウェアとみなして厳重なテストを行うそうですから、このような事態は再発しないだろうと思います。
それでもメールアドレスの漏えいが不安な場合には コマンドラインオプションに --register-unsafely-without-email を付ける [letsencrypt.jp] ことで、Let's Encrypt 認証局にメールアドレスを提供せずに証明書を取得できるようです。ただし、非推奨なオプションなようです。
コマンド解説 - Let's Encrypt 総合ポータル [letsencrypt.jp] より引用:
0～7,618件（件数は原文ママ） (スコア:1)
＞ 0～7,618件（件数は原文ママ）
Let's Encryptの続報ページでは0〜7,617件に訂正されてますね。
https://community.letsencrypt.org/t/email-address-disclosures-june-11-... [letsencrypt.org]
Re: (スコア:0)
いつも誤字を指摘されているストーリーだけど、よくこんな細かいところに気づいた。
Let's debug (スコア:0)
1回動かしたらわかるだろうが
Re: (スコア:0)
１回めの動作では分からないでしょ。
以前に使用したアドレスまで本文に追加してしまうってバグだから、最低２回は動かさないと。
で、本文に無関係な送付先のアドレスが追加されていることをチェックしなきゃいけなかった。だから気づかなくて当然。
何十回か動作すれば本文が異常に大きくなっているからそこで気づいたかもしれないが、自分だったら自信ないなあ。
そもそも送信先が正しく変更されることしかチェックしないだろうし、何十回も動作確認したりはしない。
このバグは本文に宛先のアドレスを転記する処理で、転記元のバッファを動作毎にクリアすべきなのにしてなかったとか、そのレベルだと思われます。なので動作確認のテストで発見することは期待できないでしょう。
決まった本文を送るだけなら本文に影響するような処理は作らない（から今回の問題は起きない）し、宛先に応じて本文を加工するならそのロジックを検証するテストが個別に必要。今回はそれができてなかったという事ではないでしょうか。
Re: (スコア:0)
1回テストするにも、ツールの性質上複数アドレスは用意してテストするでしょ
事象も誤解して長々書いてるけど、この人色んな意味で大丈夫？
Re: (スコア:0)
個人的には、「1回動かしたらわかるだろうが」の一言で斬って捨てるやつの方が不安だなあ
Re: (スコア:0)
ユニットテストで一括送信部分のテストが抜けていたのなら、1つのアドレスにしか送らないということもありうる。そして今回はそうだったと。
こういうセキュリティに関わる部分はテストすることを明確にすべきですね。全体のカバレッジを見るのではなくて。
Re: (スコア:0)
ユニットテストはプログラムの作りに依存するので、
一括送信時の動作という観点でのテストは(ユニットテストでは)実施出来ない可能性もあります。
その場合でも複数アドレスの入力受け取り、分割して返すメソッドなど別の個所でNGになるはずですが、
処理をきっちり分割出来ていなかったりとユニットテストに向かないコーディングをしてれば、
いくらでもすり抜ける可能性はありますね。
その場合、ユニットテスト自体の意味がほとんどなくなりますが、
元々ユニットテストはある程度のプログラミングスキルが無いとまともなテストは出来ないものです。
（どちらかと言えば、テストとは言うもののプログラミングの一部）
その場合でもちゃんとテストしてれば、
他のテストフェーズで今回のケースは検出出来たはず。
お詫びはもちろん (スコア:0)
T ポイント 500 円分でしょ？
Re:お詫びはもちろん (スコア:1)
みんな同額？
1番目のやつと
7617番目のやつだと
被害の程度は違うんだよねぇ
Re: (スコア:0)
１番めの人は7618人に公開されちゃったわけなので、7618倍貰えるとか。
＃500×7618≒380万円貰えるなら嬉しいかも。
んんん～？ (スコア:0)
うちにはまだ誤送信もお詫びメールも来てないな
誤送信届いてなくても
流出被害者の可能性があるのに
被害対象か否か確認方法ないのはつらいな
# そして確認サイトとして第三者がウマウマ
Re: (スコア:0)
「前に送信した送信先が次々と本文に付加されていった」
ので、誤送信が届いていないなら流出もないです。
あなたには被害がないので、彼らはあなたに詫びる必要もないのです。
と私は読み進めたが、どうなったら親コメの思考になるのかご教授いただきたい次第
Re: (スコア:0)
最初の送信者でない確証をどうやって得るんだろう
Re: (スコア:0)
最初の投稿者でなくても納得のいく説明ができれば誰でもいいです。
Re: (スコア:0)
「2016/06/11(UTC)に送信を始めた」「1.9%処理したところで停止した」と言っているのだから、ここ一週間でLet's Encryptからメールを受け取っていないのであれば最初の1人(もちろんそれ以降も)にはなってないんじゃないかな。
Let's Encrypt (スコア:0)
せめて平文じゃなくて暗号化して送っていたならば。
Re: (スコア:0)
Let's Encryptさんが、S/MIMEの署名も無料でやってくれるようになったら最高や〜
Let's Export (スコア:0)
安全、セキュアを最大にして唯一のプロダクトとする会社が
一番してはいけないミスをしたケース。
この直球感、そして脱力感すごい。
史上希にみる速度で信用がdrop table。
単体テストすらしてないのかと。