「LINEのトークが盗聴されているって本当？」の解説からLINEのセキュリティ機能の抜けの検証について

噂の元になっているツイートがこちらです。

今日、友達のIP抜こうと思ってLINEでURL踏ませようとしたら…友達に踏ませる前に何故かLINE鯖からのアクセスが(・_・;)やっぱりLINEはトークから何まで盗聴しているみたいです汗 画像はアクセスされたIPとWHOIS結果です pic.twitter.com/zZ7U5aRmKo

— あっぽー (@appo_jtc) 2016, 1月 1

ツイートの意味解説

このツイートが何のことを言っているのか、少し難しいかも知れないので、簡単に必要な部分だけ解説をしておきます。

アクセス元を記録できるURL

世の中には色々なサービスがあり、どこからのアクセスがあったのか（=IPアドレス）を記録してくれるURLを発行してくれるサービスがあります（特別に記録できるサービス、というわけではなく、どんなサーバーでも通常記録しているアクセス元情報を、一般に表示してくれるだけ）。

友だちに送ったURLなのに、LINEからアクセスが…

今回のTweet主は、そのURLをLINEで友だちに送信して、友だちにURLを踏ませて（=アクセスさせて）、友だちのIPアドレスを知ろうとしたところ、友だちより先に、LINE社のサーバーからアクセスがあったということをツイートしています。

盗聴？

このアクセスを見て、「LINE社が盗聴している」と主張しているのがツイートです。

しかし、このLINE社からのアクセスについて、重要な事実の認識が抜けています。

盗聴かどうかの判断は、次の事実を知った上で行うべきです。

LINEの新機能が原因

例のアクセスは、iPhone版LINE5.8.0より搭載された新機能が原因です。

その新機能とは、URLをトークで送ったときに表示される、URLのサムネイル表示機能です。

次の画像のように、トークのすぐ下に、そのURLの中身が表示されます。

LINE社が代理でアクセス

このようなURLのサムネイル画像を取得する場合に、サービス側が代理にアクセスするのは定番です（以前紹介したGunosyの例やFacebookでも）。

つまり、ツイートで指摘されていたアクセスは、サムネイルを表示するために必要なデータを取得するアクセスだった、というわけです。

ツイートに添付された画像にある「ブラウザ：facebookexternalhit/1.1」という表示も、その機能の挙動と一致します。

したがって、これだけをもって、「盗聴」と呼んでしまうのは、非常に誤解を生むことになり、適切とは言えないと思われます。

「盗聴」と言ってしまったら、その中身をサーバ側で読んでいるような印象を受けますが、あくまでこれは機能の一環で、LINEのサーバが代理取得をしているだけです。

今回のツイートは、おそらく「盗聴しているから、URLにアクセスがあった」という、盗聴の結果を指摘しているので、このような裏側の仕組みを持ってすれば、Tweet主の勘違いだった、と言えると思います。

LINEのサーバーにデータがあるんでしょ？じゃぁ盗聴じゃないの？

しかし、また別の人は、ここまで把握した上で「盗聴」と言いたくなる人もいるかも知れません。

ただ、やはり「データがLINEの会社にある」＝「LINEが盗聴」、というわけではありません。

その、LINEの会社にあるデータを、「利用規約の範囲外」で誰かが読み出した場合に、初めて盗聴、と言えることでしょう。

別にデータが運営にあることそのものが問題になるわけではないはずです（もちろん、気持ち悪いとかそういう反応があるのは自然だと思うけれど）。

と、ここまでは「盗聴ではない」という、LINE寄りな立場で話してきました。

では、ここまで把握した上で「盗聴だ」とまではいかないものの、より否定的な立場ではどう考えられるかを述べておきます。

最初に気になったのが、「Letter Sealing」機能です（利用規約を読んでみようの会は、こちらが重たくなったので保留）。

Letter Sealing機能とは、デフォルトでは「オフ」ですが、トークの送信側と受信側の両者がオンにした場合、それぞれの端末上で暗号か復号化が行われ、LINEの運営側も中身を知ることができないというLINEの機能です。

盗聴できないようにする機能

先ほど、「LINEの会社にデータがある」=「LINEが盗聴」ではない、ということを言いました。

ただよくよく考えれば、LINEの会社にデータがなければ、そもそも盗聴もできない、という発想が「Letter Sealing」です。

Letter Sealing は、LINEの会社を通過するデータが常に暗号化された状態であることを保証して、暗号化されたデータしかLINEの会社には存在しない、という状態を保証しています。

利用目的

このように、Letter Sealingは、LINE社に絶対に知られてくない秘密の会話をするための機能として提供されています。

以下は、LINEの技術ブログの引用です。

Letter Sealingでは、メッセージの暗号化などの管理主体がサーバからメッセージ送信者(sender)に変わったという点です。これにより、かつてサーバ上で行っていた復号、および再暗号化が不要、また技術的に不可能になりました。これにより、他ユーザーはもちろん、LINEサーバの管理者でさえ、メッセージの内容を解読（復号）することはできなくなりました。 （引用元）

一番下に、小さくて色の薄い文字で、次の注意点が書かれています。

※注２: 現時点では、Letter Sealingはテキストメッセージと位置情報に対してのみ適用されます。 （引用元）

画像やスタンプなどは対象外のようですが、テキストメッセージは当然対象内で、そこに含まれている「URL」も、当然テキストメッセージの一部であり、ユーザーは、先ほどの引用文にあるように、「LINEサーバの管理者でさえ、メッセージの内容を読めない」ということを期待して、Letter Sealingを利用していることでしょう。

これを前提にすると、やはり検証したくなります。

そこで、以前の実験同様に、適当に作ったURLをトークで送信し、そのURLにLINE社のサーバーからアクセスが来ていないかを、Letter Sealingを有効にしたユーザー同士のLINEトークで実験してみることにしました。

サーバーのアクセスログを確認してみると、Letter Sealing　が有効なトークに投稿したURLに対して、次のアクセスログが記録されていました。

203.104.145.59 - - [02/Jan/2016:14:36:36 +0900] "GET /123456 HTTP/1.1" 404 26431 "-" "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)"

アクセス元IPアドレスを調べると、LINE社からのアクセスであることが分かりました。

つまり、トークの内容がLINEの管理者にすら読み取られない、として提供されているはずの「Letter Sealing」が有効のトークにおいても、トーク内に含まれるURLの情報が、LINE社に送信されていたという解釈ができる、というわけです（※ユーザーのLINEアプリから、URLがLINE社サーバに送られているからこそ、LINE社のサーバがウェブサイトに代理アクセスできる）。

これが「スタンプ」であれば、LINE社のサーバーからスタンプ画像をダウンロードする必要があるため、完全に防ぐことはほぼほぼ不可能です。しかしそもそも「スタンプ」はLetter Sealingの対象外（と、ヘルプにはないけれど小さい文字で技術ブログに書かれている）なので、今回問題にはなりません。

ここで気にしておきたいのは、「トーク本文はLetter Sealingの保護の対象」でありなおかつ、「LINE社のURL取得は、必要不可欠ではなく、防ぐことが可能な機能」であるという点です。最悪、直接取得にすればいいのですから（サーバ側としては迷惑）。

もちろん、Letter Sealingという特別な機能が無ければ大したことない、となりがちですが、Letter Sealingというセキュリティ機能を提供しているのですから、このような情報の抜けは問題となります。

さらにここで確認ですが、もちろん、URLを踏んだ結果アクセスログが「そのURLのページを持つサーバー」に残る、というのは当然です。しかし、アクセスを受けた側も、それが誰と誰とのトークからのアクセスだ、なんてことは分かりません。今回は、それを知りうる「LINE」のサーバーに、わざわざLetter Sealingによるセキュリティ保護を有効にしたユーザー同士のトークなのに、知られてしまうというのが問題といえるのです。

これがはたまた「重大であるかどうか」は、普段からのLINEに対する考え方や、ユーザーの利用スタイルに大きく寄るところと思います。

しかしやはり、Letter Sealing機能を、送信者と受信者以外には対話内容を判読できないように設計された通信方式です、としている以上、LINE社として、そのままなのは問題のように感じます。

技術的に「そこはLetter Sealingの対象外だ」と言いたくなるかもしれません。いや、確かに「Letter Sealing」そのものの問題ではありません。しかし、現実的に「Letter Sealingが提供する機能」としては、やはり抜けがあり、不完全であると考えられます。

Letter Sealingとは、トークルームのメッセージにエンドツーエンド暗号化を適用した機能です。 
※エンドツーエンド暗号化(End to End Encryption)とは、サーバー上でもメッセージの内容が暗号化された状態で保存されており、送信者と受信者以外には対話内容を判読できないように設計された通信方式です。  （引用元）

というより、こんな抜けがあるのであれば、Letter Sealing機能って何なんだよ、という意見もあるはずです。

どれだけ高度なセキュリティ対策を施していても、結局の所、他の弱いところに抜けがあれば…、という話の一例と見ることもできます（今回の場合、URLのみ、と限定的ではある点に注意）。

もう一つ注意点を挙げておくとすれば、この情報をLINE社が悪用しているかどうか、というのは全く話が別、という点です。

しかし、それでもLetter Sealingが保証しているとユーザーが考えるであろう機能に漏れがある、という解釈が可能であるという点は、悪用の有無とは無関係です。

悪用されているかどうかではなく、悪用がそもそも可能な状態かどうか、という点が重要、という認識こそがセキュリティという意味ではとても重要です。

Letter Sealingのような機能は「悪用しようと思っても悪用できない仕組み」であり、これが重要ポイントなのですから。

※もちろん、LINE社としても、完全に悪用不可能であると示すことは不可能です。しかし、外側から見て悪用可能な状態が見えてしまうのは、「明らかに悪用可能である」と思われても*仕方ない、という状態であることを示しています（*Letter Sealing以外の方法で、悪用できない外部的な仕組みが存在する可能性を残しておきたい。が、今回はちょっと…）。

誤解含みな「盗聴」話から、Letter Sealing 有効状態での挙動確認話になりました。

Letter Sealing 時は、URLのサムネイル表示をオフにする、というアップデート来るかなぁ。来ないかなぁ。極端な話、それだけなのだけど。

Letter Sealing自体のそもそものセキュリティについての参考に：

昨年， EFF が安全なメッセージング・アプリの条件を示した。

Secure Messaging Scorecard | Electronic Frontier Foundation
ASCII.jp：実は危険だらけのメッセージアプリ
条件は7つ。

Encrypted in transit?
Encrypted so the provider can’t read it?
Can you verify contacts’ identities?
Are past comms secure if your keys are stolen?
Is the code open to independent review?
Is security design properly documented?
Has there been any recent code audit?
この条件に照らせば Letter Sealing は最初の2つはクリアしたけど5，残りは「もっと頑張りましょう」な状態。 せめて条件4までは全て対応していただきたいところだ。 （引用元）

↑読むときは脚注にも注意。