アカウント名:
パスワード:
TLSの暗号化そのものも「セッション鍵」という「ネゴシエートされたキー」を使って暗号化しますし、類似技術であるSIP+SRTPもINVITEリクエスト(もしくはそれに対する200 OKレスポンス)でSRTPの鍵をやりとりします(RFC-4568, INVITEそのものはTLSで暗号化します)。
どこらへんが「エンドツーエンド暗号化の要件には当てはまらない」んでしょうか？
参加者とZoomのサーバの間の暗号化（Zoomはこれをエンドツーエンド暗号化と呼んでる）はされてても参加者と参加者の間が全部通しで暗号化（The Interceptはこれをエンドツーエンド暗号化と呼んでる）されてるわけじゃない。好きな方の定義を選んで。
あと、SIP+SRTPでThe Interceptの言うエンドツーエンド暗号化された会議をやろうとするとメッシュ状に暗号化したセッションを張らなきゃいけないので大規模なのは大変。
なるほどサーバーとユーザーの間しか暗号化出来ていないってタレコミに書かなきゃ何を言いたいのか分からんよね
分からなかった時点でなぜソースを読まずに脊髄反射で書き込むのかが分からない。
分かりませんでした！
それにしても注目アプリだからこそこうやって解析されちゃうし、これからどんどん良くなるんでしょうね。
それはない。
いやわかんなかったな。TLSはE2E暗号化だし何言ってんだコイツと思ったわ
全参加者でメッシュで通信なんか少し数増えたら現実的じゃないし想像してなかった富豪度が足りんなぁ
> 全参加者でメッシュで通信なんか少し数増えたら現実的じゃないし想像してなかった
会議用セッション鍵を開催者が生成し、個別参加者と 1:n で公開鍵暗号使った鍵交換すれば、全参加者でセッション鍵を共通しつつ、E2E暗号化が実現できるから、全然実現可能だと思う。
鍵の問題じゃなくて通信量の問題。
そうだよね。ってか公開鍵暗号でセッション鍵交換って普通だよね。SSHもそのパターンだし。
ただブラウザ上で動画情報を暗号化とかできんのかな？復号とか帯域制御とかはHTTP Live Streamingみたいなのでお手軽にできるけど。
通信自体は今までと方式を変えずに、今まで通りにできるでしょ。暗号化ストリーム通信を中継するだけだし。
サーバで参加者のビデオをとりまとめて再圧縮してると通信量は減りそうだけど、劇的な高価はない割に、計算量は馬鹿にならなそうだし。
通信トポロジの話は（今回関係ないと思うけど）むしろハブアンドスポークだと中央のサーバのところがボトルネックになるので、工夫すればP2Pのほうが早いとかって話なかったっけ？
zoom使ったことないでしょ？
使ったことあるんなら、
> 暗号化ストリーム通信を中継するだけだし。
で済まないことがわかるはず。
何千台とはいわんからせめて数台つないで、それぞれで資料共有したり、ミュートしたり、喋ったり、帯域を変化させたりしながら通信量の変化を見ると、細い回線でも快適に会議ができるようにサーバ側が細かな制御をしてるのがわかるはず。
通信量に真っ先に気が行くのは老人なんですかね10人の会議なら10倍、100人なら倍ですよちょっとなぁ
証明書の管理機構を追加する必要があったりはしそうだからそのまんまではちょっと……そも、クラウドレコーディング機能があるって話だからサーバに対して秘匿する意義が薄い。暗号化したままレコーディングとかだと証明書のユーザ側での明示的な管理が必要になるかな。
TLSはクライアント-サーバ間のE2Eだけど、ビデオ会議のようなクライアント間の通信でE2Eといえばサーバでも復号できないものを指すのが普通。なぜならこの場合のサーバは「エンド」ではなく中継者だから。
まあ、この話を読む人がどういう前提を持っているか、それだけの話。あなたの「普通」は、ほかの人にとっての「普通」とは限らない。
知識などの前提が違えば、読み解き方も異なってくる。だから単に不足している前提を補えば良いだけなのに、余計な一言を書くから印象が悪くなる。
で、ZOOMはP2Pではなく間に入るサーバをZOOM社が提供しているんでしょうか。この前提があれば、E2Eの定義には確かにはまらないですね。ただそれが実用上セキュアかどうかは、また別の話かと。
P2Pではない限り、「クライアント-サーバ間のE2E」をE2Eと主張するのは詐欺に近く、普通は「通信路暗号化」といいますな。
今のご時世、通信路暗号化すらしないのは論外に近いので、ようするにZoomは暗号化に関しては特筆するようなことはしていません、という認識でよいかと。
正直なるほどと思った。クライアントサーバーのイメージに浸かり過ぎているのかな。
だから (#3790483)にとっての「普通」が、多くの企業にとっては許容できないリスクであるという話でしょ。中継するサーバなんて信用できないとするのが鉄則なんだから。
君にとっての「鉄則」はそうなんだろうね。
一人暮らしの在宅勤務中だけど、ショルダーハッキングされたい。
ハイエンドパソコンとローエンドパソコンの間をミドルエンドパソコンと言う人ならZoomをE2Eと呼ぶことは許すけど、Lineがサーバーが韓国だから信頼しないって人がZoomを実用上「セキュアかどうかは、また別の話かと。」とかその立場をとること絶対認めないからな。
Zoomの場合、有料版の大きな機能として「クラウドレコーディング」（会議の内容をZoomが提供するクラウド上のスペースに録画する）があるんで、最初からZoomサーバー自身がクライアントとしても動作しないといけないってのもあるなあ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
エンドツーエンド暗号化の要件には当てはまらない？ (スコア:0)
TLSの暗号化そのものも「セッション鍵」という「ネゴシエートされたキー」を使って暗号化しますし、類似技術であるSIP+SRTPもINVITEリクエスト(もしくはそれに対する200 OKレスポンス)でSRTPの鍵をやりとりします(RFC-4568, INVITEそのものはTLSで暗号化します)。
どこらへんが「エンドツーエンド暗号化の要件には当てはまらない」んでしょうか？
Re:エンドツーエンド暗号化の要件には当てはまらない？ (スコア:4, 参考になる)
参加者とZoomのサーバの間の暗号化（Zoomはこれをエンドツーエンド暗号化と呼んでる）はされてても参加者と参加者の間が全部通しで暗号化（The Interceptはこれをエンドツーエンド暗号化と呼んでる）されてるわけじゃない。好きな方の定義を選んで。
あと、SIP+SRTPでThe Interceptの言うエンドツーエンド暗号化された会議をやろうとするとメッシュ状に暗号化したセッションを張らなきゃいけないので大規模なのは大変。
Re: (スコア:0)
なるほど
サーバーとユーザーの間しか暗号化出来ていないってタレコミに書かなきゃ何を言いたいのか分からんよね
Re: (スコア:0)
分からなかった時点でなぜソースを読まずに脊髄反射で書き込むのかが分からない。
知らん (スコア:1)
分かりませんでした！
それにしても注目アプリだからこそこうやって解析されちゃうし、
これからどんどん良くなるんでしょうね。
Re: (スコア:0)
それはない。
Re: (スコア:0)
いやわかんなかったな。
TLSはE2E暗号化だし
何言ってんだコイツと思ったわ
全参加者でメッシュで通信なんか少し数増えたら現実的じゃないし想像してなかった
富豪度が足りんなぁ
Re:エンドツーエンド暗号化の要件には当てはまらない？ (スコア:1)
> 全参加者でメッシュで通信なんか少し数増えたら現実的じゃないし想像してなかった
会議用セッション鍵を開催者が生成し、個別参加者と 1:n で公開鍵暗号使った
鍵交換すれば、全参加者でセッション鍵を共通しつつ、E2E暗号化が実現できるから、
全然実現可能だと思う。
Re: (スコア:0)
鍵の問題じゃなくて通信量の問題。
Re: (スコア:0)
そうだよね。
ってか公開鍵暗号でセッション鍵交換って普通だよね。
SSHもそのパターンだし。
ただブラウザ上で動画情報を暗号化とかできんのかな？
復号とか帯域制御とかはHTTP Live Streamingみたいなのでお手軽にできるけど。
Re:エンドツーエンド暗号化の要件には当てはまらない？ (スコア:1)
通信自体は今までと方式を変えずに、今まで通りにできるでしょ。
暗号化ストリーム通信を中継するだけだし。
サーバで参加者のビデオをとりまとめて再圧縮してると通信量は減りそうだけど、
劇的な高価はない割に、計算量は馬鹿にならなそうだし。
通信トポロジの話は（今回関係ないと思うけど）むしろハブアンドスポークだと中央のサーバのところが
ボトルネックになるので、工夫すればP2Pのほうが早いとかって話なかったっけ？
Re: (スコア:0)
zoom使ったことないでしょ？
使ったことあるんなら、
> 暗号化ストリーム通信を中継するだけだし。
で済まないことがわかるはず。
何千台とはいわんからせめて数台つないで、それぞれで資料共有したり、ミュートしたり、喋ったり、帯域を変化させたりしながら通信量の変化を見ると、細い回線でも快適に会議ができるようにサーバ側が細かな制御をしてるのがわかるはず。
Re:エンドツーエンド暗号化の要件には当てはまらない？ (スコア:2)
通信量に真っ先に気が行くのは老人なんですかね
10人の会議なら10倍、100人なら倍ですよ
ちょっとなぁ
Re: (スコア:0)
証明書の管理機構を追加する必要があったりはしそうだからそのまんまではちょっと……
そも、クラウドレコーディング機能があるって話だからサーバに対して秘匿する意義が薄い。
暗号化したままレコーディングとかだと証明書のユーザ側での明示的な管理が必要になるかな。
Re: (スコア:0)
TLSはクライアント-サーバ間のE2Eだけど、ビデオ会議のようなクライアント間の通信でE2Eといえばサーバでも復号できないものを指すのが普通。
なぜならこの場合のサーバは「エンド」ではなく中継者だから。
Re: (スコア:0)
まあ、この話を読む人がどういう前提を持っているか、それだけの話。
あなたの「普通」は、ほかの人にとっての「普通」とは限らない。
知識などの前提が違えば、読み解き方も異なってくる。
だから単に不足している前提を補えば良いだけなのに、余計な一言を書くから印象が悪くなる。
で、ZOOMはP2Pではなく間に入るサーバをZOOM社が提供しているんでしょうか。
この前提があれば、E2Eの定義には確かにはまらないですね。ただそれが実用上セキュアかどうかは、また別の話かと。
Re: (スコア:0)
P2Pではない限り、「クライアント-サーバ間のE2E」をE2Eと主張するのは詐欺に近く、普通は「通信路暗号化」といいますな。
今のご時世、通信路暗号化すらしないのは論外に近いので、ようするにZoomは暗号化に関しては特筆するようなことはしていません、という認識でよいかと。
Re: (スコア:0)
正直なるほどと思った。クライアントサーバーのイメージに浸かり過ぎているのかな。
Re: (スコア:0)
だから (#3790483)にとっての「普通」が、多くの企業にとっては許容できないリスクであるという話でしょ。
中継するサーバなんて信用できないとするのが鉄則なんだから。
Re: (スコア:0)
君にとっての「鉄則」はそうなんだろうね。
Re: (スコア:0)
一人暮らしの在宅勤務中だけど、ショルダーハッキングされたい。
Re: (スコア:0)
ハイエンドパソコンとローエンドパソコンの間をミドルエンドパソコンと言う人ならZoomをE2Eと呼ぶことは許すけど、
Lineがサーバーが韓国だから信頼しないって人がZoomを実用上「セキュアかどうかは、また別の話かと。」とかその立場をとること絶対認めないからな。
Re: (スコア:0)
Zoomの場合、有料版の大きな機能として
「クラウドレコーディング」（会議の内容をZoomが提供するクラウド上のスペースに録画する）があるんで、
最初からZoomサーバー自身がクライアントとしても動作しないといけないってのもあるなあ。