アカウント名:
パスワード:
既にLenovoがやらかしている(Superfish)ように、PC内に独自のルート証明書を入れさせて、独自のプロキシサービス経由で接続するようにすれば、プロキシサービス側で暗号化されているはずの通信を傍受できてしまいます。
また、PC側の権限さえ取れてしまえば、全くユーザ側に気付かせずに通信を検閲することもできます。(BIOSやファームウェアのレベルで混入させれば、ますます気付かないでしょう)
これらの検閲方法についても対抗策の登場が望まれます。
> 既にLenovoがやらかしている(Superfish)ように、PC内に独自のルート証明書を入れさせて、> 独自のプロキシサービス経由で接続するようにすれば、プロキシサービス側で暗号化されているはずの> 通信を傍受できてしまいます。
まあそうなんだけど、これかなり計算力がいるんですよね。SSLセッションををサーバ・クライアント両面で実行しているわけで。
CPUに内包されてる AES-NI で結構イケてるのかな？と思ってました。※ sshの話ではありますが、おぉっと思うくらい負荷が低減されて驚いた。
AES-NIが搭載されているくらい最近のCPUなのに、SSH位でそんなにCPU使用率が上がるかなあ?ファイル転送でもしてたの?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
HTTPS化だけで安心してはいけない (スコア:1)
既にLenovoがやらかしている(Superfish)ように、PC内に独自のルート証明書を入れさせて、
独自のプロキシサービス経由で接続するようにすれば、プロキシサービス側で暗号化されているはずの
通信を傍受できてしまいます。
また、PC側の権限さえ取れてしまえば、全くユーザ側に気付かせずに通信を検閲することもできます。
(BIOSやファームウェアのレベルで混入させれば、ますます気付かないでしょう)
これらの検閲方法についても対抗策の登場が望まれます。
Re: (スコア:1)
> 既にLenovoがやらかしている(Superfish)ように、PC内に独自のルート証明書を入れさせて、
> 独自のプロキシサービス経由で接続するようにすれば、プロキシサービス側で暗号化されているはずの
> 通信を傍受できてしまいます。
まあそうなんだけど、これかなり計算力がいるんですよね。SSLセッションををサーバ・クライアント両面で実行しているわけで。
Re:HTTPS化だけで安心してはいけない (スコア:1)
# エンジンのセットアップコストが高くて遅くて使えないというオチ
# つーか某社の暗号化エンジンがコレで
Re: (スコア:0)
CPUに内包されてる AES-NI で結構イケてるのかな？と思ってました。
※ sshの話ではありますが、おぉっと思うくらい負荷が低減されて驚いた。
Re: (スコア:0)
AES-NIが搭載されているくらい最近のCPUなのに、SSH位でそんなにCPU使用率が上がるかなあ?
ファイル転送でもしてたの?