パスワードを忘れた? アカウント作成
12584258 story
セキュリティ

Gmail、暗号化されていない経路で受信したメールに警告を表示へ 43

ストーリー by hylom
メールの中身を第三者が見ることができるという常識はいつか変わるのか 部門より
あるAnonymous Coward 曰く、

Gmailが暗号化されていない経路で受け取ったメールについて、警告を表示するように変更するという(TechCrunchGoogle Online Security Blog)。

GoogleのTransparency Reportによると、TLSを使った暗号化経路を使ったメールはGmailからの発信で81%、受信で57%という割合だそうだ。また、ドメイン毎ではdocomo.ne.jpとezweb.ne.jp、softbank.jp、softbank.ne.jpのすべてと、rakuten.co.jpとyahoo.co.jpのほぼすべては暗号化されていない。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • メールサーバ間でのTLS通信というのは勿論やらないよりはマシですが、NSAやスパイ組織などがメールを盗み見ようとした場合、メールサーバの管理者に圧力をかけたり、スパイを紛れ込ましたり、メールサーバにバックドアをしかけたりして、メールの内容を盗み見ようとするでしょうから、根本的な対策にはなりません。また、相手がメールサーバから平文のPOP3やIMAPなどでメールを受信していたら、その部分が脆弱なことには変わりないし、メールサーバの管理者がメールを盗み見ることが可能なのには変わりありません。

    従って、根本的な対策として PGP や S/MIME 対応をするべきです。しかし、フリーソフトのMUAでもPGPやS/MIME対応が数多くあるというのに、いつまでたっても Android 版 Gmail クライアントは、PGP にも S/MIME にも対応する気がないようです。

    きっと、メールの内容を読み取って、それに関連した広告を表示させて金儲けをしているGoogle のことですから、PGP や S/MIME といったまともな End-To-End 暗号化を普及させてしまったら大幅な収益源となることから(メールの内容に関連した広告とそうでない広告では、明らかにクリック率に違いが出ます)、普及させる気がないんでしょうね。

    2014年06月04日にメールを「End-To-End」で暗号化するGoogle公式拡張機能が開発中 [gigazine.net]だという話がありましたが、1年半近く経っているのに、未だに正式版がリリースされません(そもそも、「拡張」ではなく「標準」で Android 版 Gmail MUA などに実装すべき性質のものだと思いますが、メール内容に関連した広告を表示させたい Google には難しいのでしょう)。他社のメールサーバがメールサーバ間でのTLS通信に対応していないことに文句を言う前に、自社のクライアントアプリ(Android 版 Gmail アプリなど)を PGP や S/MIME に対応させていただきたいものです(S/MIME 署名にも対応していない現状では、フィッシング詐欺メールも見分けにくいという実害が出ていますね……)。

    • by Anonymous Coward on 2015年11月17日 15時01分 (#2918910)

      もし「PGPやりたくない」という本音がGoogleにあったとして、一億歩譲ってそれを認めたとしても、
      S/MIME署名にも対応しないことで「smime.p7sという謎のファイルが気持ち悪い」という風評被害を広めたことは許せないですな。
      ちなみにGMail以外のWebメールサービスがPGPやS/MIMEに対応しなかったのは怠慢以外の何者でもないのでこれも万死に値する。

      親コメント
      • by Anonymous Coward

        S/MIME と web メールは相性が悪いのですよ。

        web メールのサーバはユーザからしたら他人なので、秘密鍵を預けるわけにはいかず、
        つまり暗号化/復号はサーバ側ではなくブラウザ側でおこなわなければいけない。
        その一方で、S/MIME の名のとおり特殊な MIME フォーマットが必要とされるので、
        サーバ側は暗号文を適切なフォーマットに整形しなければならない。
        このへんの実装が超絶めんどくさいですね。

        PGP は MIME を使わず、すべての処理をブラウザ側に丸投げできるので、だいぶラク。
        画面に表示されてるものをコピペして手元で gpg コマンドにつっこんでやれば、
        (めんどくさい

        • by Anonymous Coward

          公開鍵は預けても大丈夫なので、署名の検証はWebメールでも可能でしょう。
          署名したメールを送ってくるのは銀行など公共性の高い企業だろうから、Googleがそういう企業の公開鍵を収集してGmailで署名の検証をすれば、「smime.p7sという謎のファイルが気持ち悪い」という風評被害も減るし、フィッシング被害も減ると思うんだけどなぁ。
          あと、署名用と暗号化用に別々の鍵ペアを作って [wikipedia.org]署名用の秘密鍵を預けずに復号も行えるようにするという案もあるようです。

          • by Anonymous Coward

            そのファイルが見えないメーラーも気持ち悪いです

            • by Anonymous Coward

              S/MIME対応してたらそのファイルが見えなくなる代わりに検証結果が何処かしらに表示される。
              これで気持ち悪いなら常時ヘッダ込みでメール表示しないメーラは気持ち悪い位いってくれないと。

    • by Anonymous Coward

      PGPやS/MIMEで本文を暗号化したとしても、送り先メールアドレスは暗号化されないはずなので、メールサーバ間でのTLS通信が無いと、選択的サービス妨害が出来てしまうはず。
      仮にPGPやS/MIMEを使うとしても、メールサーバ間でのTLS通信は必要だと思いますよ。

    • by Anonymous Coward

      各OSデフォルトのメールアプリも、S/MIMEには対応してるけど、PGP/GPGには対応してない場合が多いと思う。
      たしかにS/MIMEが第三者の証明や公開鍵の正当性も検証しやすいからいいんだけど、基本的に有料だから普及しにくい。

      その点、鍵の検証は各自で判断しないといけないけど、狭い範囲でやるだけなら無料で実現できるGPGでいいと思うんだよね。
      フィンガープリントをウェブ上で公開してれば鍵の検証もしやすいだろうし。
      でも、最初から対応してるアプリは少ない。そこを改善してくれるだけで少しずつでも普及していくと思う。

      facebookがユーザーにメール送るとき、ユーザーが事前にGPG公開鍵を登録させておくと暗号化メールを送ってくれるようになったし、そういう流れが広まるとこれまたいいんだが。
      ただfacebookからのメール通知はそんな重要なもんでもないし、メッセンジャーの方のEnd-To-Endな暗号化やってくれよ、と。

    • by Anonymous Coward

      私も早くe2eを完成させてほしいと願う一人ではありますが、
      暗号とセキュリティの専門家はメールを見限っていますな。
      I have recently come to the conclusion that e-mail is fundamentally unsecurable. The things we want out of e-mail, and an e-mail system, are not readily compatible with encryption. [schneier.com]
      (最近ではメールが本質的にセキュア化不可能だという結論に到達した。人がメールに望むものは、そもそも暗号と相容れない)

  • by Anonymous Coward on 2015年11月17日 14時26分 (#2918877)

    Googleは偽の安心感を与えて何がしたいんだろう?

    • DMやMLとかでエラー出まくりにならなったらめっちゃ鬱陶しそう。

      #日常Gmailで受け取ってるメールの90%以上はDM

      親コメント
    • by Anonymous Coward

      ヘッダ偽装の問題の方は、DKIMやSPFで対処されており、既にかなり普及しています。

      http://news.mynavi.jp/news/2015/11/14/066/ [mynavi.jp]
      >一方の認証側では、Gmailにやってくるインバウンドメッセージのうち94%が、DKIMやSPFといったメールのドメイン認証メカニズムを持っていたという。

      • by Anonymous Coward

        SPFがそんなに普及しているというのは、ちょっと信じられないんだけど。
        試しに最近受け取った会社のメールドメインを引いても、SPFレコードない場合が多いよ。
        そりゃあプロバイダのメールドメインなら、ほとんど全てがSPFレコード設定してるだろうけど。

        • by Anonymous Coward

          5年前の総務省の統計見ると8割で対応済みなんですが・・・
          http://www.soumu.go.jp/menu_news/s-news/02kiban08_02000047.html [soumu.go.jp]

          標的型も散々騒がれたのに5年もたって
          まだ、対処していないなら取引先としてどうなのか考えちゃいますね?

          中央省庁や大手企業、ISPは対処済み。自治体レベルでも概ね対処済みですね

      • by Anonymous Coward

        乗っ取られたアカウントからやってくるスパムメールにもきっちり署名が入っているのはどうしたもんだろう?これも暗号化された経路だから、警告は出ないんだろうな。

  • by Anonymous Coward on 2015年11月17日 15時12分 (#2918916)

    タイトルは半分釣り。
    さて、手元のメールサーバがPostfixなら「smtp_tls_security_level = may」を設定すればとりあえずはOKになるようだが、
    これはデフォルトの「平文SMTPしか使わない」から「相手がオレオレだろうと暗号化できるなら暗号化する」への変更となる。
    これに意義があると思うかどうかはまたひと議論あるんだろうな、と。

    ちなみに上記オプションはこれ以上厳しいのだと「平文SMTPを使うという選択肢がなくなる」わけで、
    まだ暗号化SMTPに対応してないスラドみたいなメールサーバがあちこちにある現状ではメールが送れなくなるケースも出てくる…
    今回のGMailの宣言でこの状況がどう変わるか…

  • by Anonymous Coward on 2015年11月17日 16時35分 (#2918982)

    郵便で例えると
    届いた葉書に
    「誰かが覗き見ていますよ By あなたのGoogleはーと」
    って追記してくれる親切設計ってことか

    余計なお世話だよ!

    • by Anonymous Coward
      「これは親展で送られてないよ」とかいう感じじゃね
      「だれかに見られたくないなら封書を使いましょう」とか。

      まあ言わずもがなだと思うけど、世の中にそういう仕組みがあると知らない人も結構いるからね。
    • by Anonymous Coward

      道中が平文なので、経路ハイジャックでメール改ざんされる可能性もあるような…

      • by Anonymous Coward

        そんなの葉書でも一緒でしょ。

        emailが葉書より安全なものだと思ってるようなアホでない限りは
        何の問題もないと思いますが。

        • by Anonymous Coward

          そのアホが多いから問題なんでしょ。じゃなきゃ電子署名はもっと普及してるはず。経路ハイジャックは年々増えてるらしいので、葉書よりも大分危険。

    • by Anonymous Coward

      まさにそれ。
      そんなに気にするなら真っ先にGmailの利用を止めるだろうにね

    • by Anonymous Coward

      ちがいます。

  • by Anonymous Coward on 2015年11月17日 23時15分 (#2919194)

    と思ったら、こんな仕組み [rakuten.co.jp]があるそうで、楽天市場に出展しているショップからユーザーに送信する独自ドメインのメールを、なんちゃら@shop.rakuten.co.jpというアドレスに変換してユーザーに送り、ユーザーがなんちゃら@shop.rakuten.co.jpにメールを送ると、ユーザーのメールアドレスをなんちゃら@dm.fw.rakuten.co.jpというアドレスに変換してショップに送るという仕組みだそうで、

    「楽天あんしんメルアドサービス」

    と呼んでいるそうな。

    つまり、ユーザーとショップの間でやり取りされるメールのほとんどが、TLSを使った暗号化経路で送られていない、ということである。

typodupeerror

アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家

読み込み中...