アカウント名:
パスワード:
サービス側で余計なことをされないようにURLからhを抜いてttps://のようにすれば
# 昔からあるやつ
ttps://www.google.co.jp/のような文字列を貼ると、大抵はドメイン名を見て判断して ttps:// www.google.co.jp/ のように正しく?解釈されます。プロトコル部をhts://みたいに替えるとか、全部ダメになりました。
ついでにwebブラウザーの補完機能でも修正される
LINEの場合、メッセージをエンドツーエンドで暗号化しているが、リンクはサーバーへ送られる。また、送受信者のIPアドレスをリンク先に送信していたという。LINEは報告を受けてIPアドレスの送信をやめたが、サーバーへのリンク送信は許容範囲内だと回答したそうだ。
エンドツーエンドで暗号化されたメッセージ内からどのようにリンクを取得しているのでしょうか。IPアドレスはメッセージが暗号化されていようと取得可能な情報なので納得できる部分もありますが、リンクはそういった方法での取得ができそうにないように思えるので不思議に思います。
ストーリーの参照先の記事に書いてあるじゃないの、よく読みなよ。
>Well, it appears that when the LINE app opens an encrypted message and finds a link, it sends that link to a LINE server to generate the preview.
受信側LINEアプリがメッセージ内にリンクがあるのを見つけたら、LINEサーバーにそのリンクを送ってプレビューを作成してもらう
との事。
ありがとうございます。要するにE2Eで暗号化してるけど、対向のEの先でメッセージの中身を読み取ってるってことですね。
読み取るばかりかLINEのサーバにそれを送ることでプレビューを実装しているMITMを防いでもManはEdgeにいる、と
端末から送信する時点でメッセージ本文からリンク部分だけを抽出して、本文とは別にURLのみをサーバへ送信するようにすれば可能な気はする。それはそれで「部外者に知られたくないURLでもLINEが勝手に取得していることになる」とも言えるけど。
だよねぇ。どういう理由で許容範囲内なのかさっぱりわからん。
URL送る際にプレビューも送信時に作って送ればちょっとはマシかもね。
下手に端折ったプレビューだと同一性保持権に引っかかる
# プレビュー機能自体が脆弱性の温床になりがちだしいらんよなぁ
受信側生成・サーバ生成それぞれに非公開があるが、サーバ生成の非公開は1つだけなので、どちらかのアプリは受信側生成ですな。
Skypeって、プレビュー機能なくない?少なくとも普段使ってるfor businessにはない。Teamsはサーバ側で生成してる気がするな。イントラサイトは生成されないし。
Microsoft は Skype のメッセージを閲覧している [security.srad.jp]
end-to-end暗号化をしてないサービスなら、どっちもサービス提供業者に筒抜けじゃないの? なんでLINEだけYesになるんだ?
かつてのメールソフト(主にOutlook)のプレビュー問題を知らない世代がアプリ作ってたりするのかねぇ
親コメの内容とずれてるけど、読んでないのかな?それにプラスモデする人はより酷い。
ここでのYes/Noはリンク先サイトがURLをクリックする前に知ることができるかどうかであって、サービスを提供しているサーバに対してではない。
Leaking Encrypted Links は、そもそもend-to-end暗号化をしているサービスだけのための項目だから、「end-to-end暗号化をしてないサービスなら」という考えがそもそも間違い。情報が漏れないための暗号化のはずが、漏れてるやん、ていう話だから。
「サービスを提供しているサーバに対してではない」と別コメにあるけど、Leaking Encrypted Links に関しては、サービス提供側に漏れるのも問題。サービス提供側にも漏らさないためのend-to-end暗号化でもあるので。
2ちゃんは時代を先取りしすぎだった
あれもリファラーをリンク先のサーバーにleakしないためという理由がかなり大きかった
日本語と英語のサイトでも同じじゃないか
非公開のURLとかでしょ。ワンタイムの認証用URLを送ると、サーバーが勝手にアクセスする可能性が有ると。
http: // を付けるだけでDNS経由で内容が漏洩するとか有るかもね。
「URLにアクセスすると登録を完了します」みたいなものも、誰かに送るだけで勝手に踏まれてるとか、気持ち悪いな。
クライアント側でプレビューを生成する場合、アクティブな時間と、場合によりセキュリティ侵害と、IPアドレスの取得が可能なのよね。プレビュー自体が害悪な気がする。
アクセスしちゃってる(&それによる通信ログにURLが残ること)自体がリークだから、両立にはなってないと思う
受け手側じゃなくて送り手側で画像生成して暗号化して送ればええんちゃうんか。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
いいこと思いついた (スコア:2, おもしろおかしい)
サービス側で余計なことをされないようにURLからhを抜いてttps://のようにすれば
# 昔からあるやつ
Re: (スコア:0)
ttps://www.google.co.jp/
のような文字列を貼ると、大抵はドメイン名を見て判断して
ttps://www.google.co.jp/のように正しく?解釈されます。
プロトコル部をhts://みたいに替えるとか、全部ダメになりました。
Re: (スコア:0)
ついでにwebブラウザーの補完機能でも修正される
どういうこと? (スコア:1)
LINEの場合、メッセージをエンドツーエンドで暗号化しているが、リンクはサーバーへ送られる。また、送受信者のIPアドレスをリンク先に送信していたという。LINEは報告を受けてIPアドレスの送信をやめたが、サーバーへのリンク送信は許容範囲内だと回答したそうだ。
エンドツーエンドで暗号化されたメッセージ内からどのようにリンクを取得しているのでしょうか。
IPアドレスはメッセージが暗号化されていようと取得可能な情報なので納得できる部分もありますが、
リンクはそういった方法での取得ができそうにないように思えるので不思議に思います。
Re:どういうこと? (スコア:3)
ストーリーの参照先の記事に書いてあるじゃないの、よく読みなよ。
>Well, it appears that when the LINE app opens an encrypted message and finds a link, it sends that link to a LINE server to generate the preview.
受信側LINEアプリがメッセージ内にリンクがあるのを見つけたら、LINEサーバーにそのリンクを送ってプレビューを作成してもらう
との事。
Re: (スコア:0)
ありがとうございます。
要するにE2Eで暗号化してるけど、対向のEの先でメッセージの中身を読み取ってるってことですね。
Re: (スコア:0)
読み取るばかりかLINEのサーバにそれを送ることでプレビューを実装している
MITMを防いでもManはEdgeにいる、と
Re:どういうこと? (スコア:2, 興味深い)
端末から送信する時点でメッセージ本文からリンク部分だけを抽出して、本文とは別にURLのみをサーバへ送信するようにすれば可能な気はする。
それはそれで「部外者に知られたくないURLでもLINEが勝手に取得していることになる」とも言えるけど。
Re: (スコア:0)
だよねぇ。どういう理由で許容範囲内なのかさっぱりわからん。
Re: (スコア:0)
URL送る際にプレビューも送信時に作って送ればちょっとはマシかもね。
リンクプレビュー自体がアウトなケースも (スコア:0, すばらしい洞察)
下手に端折ったプレビューだと
同一性保持権に引っかかる
# プレビュー機能自体が脆弱性の温床になりがちだしいらんよなぁ
TeamsとSkypeはどこだ (スコア:0)
受信側生成・サーバ生成それぞれに非公開があるが、サーバ生成の非公開は1つだけなので、どちらかのアプリは受信側生成ですな。
Re:TeamsとSkypeはどこだ (スコア:1)
Skypeって、プレビュー機能なくない?
少なくとも普段使ってるfor businessにはない。
Teamsはサーバ側で生成してる気がするな。イントラサイトは生成されないし。
Re: (スコア:0)
Microsoft は Skype のメッセージを閲覧している [security.srad.jp]
IP ExposureとLeaking Encrypted LinksがLINEのみYesになってる (スコア:0)
end-to-end暗号化をしてないサービスなら、どっちもサービス提供業者に筒抜けじゃないの? なんでLINEだけYesになるんだ?
Re:IP ExposureとLeaking Encrypted LinksがLINEのみYesにな (スコア:1)
かつてのメールソフト(主にOutlook)のプレビュー問題を知らない世代がアプリ作ってたりするのかねぇ
Re: (スコア:0)
親コメの内容とずれてるけど、読んでないのかな?
それにプラスモデする人はより酷い。
Re: (スコア:0)
ここでのYes/Noはリンク先サイトがURLをクリックする前に知ることができるかどうかであって、サービスを提供しているサーバに対してではない。
Re: (スコア:0)
Leaking Encrypted Links は、そもそもend-to-end暗号化をしているサービスだけのための項目だから、「end-to-end暗号化をしてないサービスなら」という考えがそもそも間違い。
情報が漏れないための暗号化のはずが、漏れてるやん、ていう話だから。
「サービスを提供しているサーバに対してではない」と別コメにあるけど、Leaking Encrypted Links に関しては、サービス提供側に漏れるのも問題。サービス提供側にも漏らさないためのend-to-end暗号化でもあるので。
ttpで書き込め! (スコア:0)
2ちゃんは時代を先取りしすぎだった
Re: (スコア:0)
あれもリファラーをリンク先のサーバーにleakしないためという理由がかなり大きかった
Re: (スコア:0)
日本語と英語のサイトでも同じじゃないか
Re:非公開情報ってなんぞ (スコア:1)
非公開のURLとかでしょ。
ワンタイムの認証用URLを送ると、サーバーが勝手にアクセスする可能性が有ると。
http: // を付けるだけでDNS経由で内容が漏洩するとか有るかもね。
Re: (スコア:0)
「URLにアクセスすると登録を完了します」みたいなものも、誰かに送るだけで勝手に踏まれてるとか、気持ち悪いな。
Re:非公開情報ってなんぞ (スコア:1)
クライアント側でプレビューを生成する場合、アクティブな時間と、場合によりセキュリティ侵害と、IPアドレスの取得が可能なのよね。
プレビュー自体が害悪な気がする。
Re: (スコア:0)
アクセスしちゃってる(&それによる通信ログにURLが残ること)自体がリークだから、両立にはなってないと思う
Re: (スコア:0)
受け手側じゃなくて送り手側で画像生成して暗号化して送ればええんちゃうんか。