アカウント名:
パスワード:
詳しい解説お願いします。
めんどくさいのでいろいろ省略するけど、
httpsの通信は、以下のような流れで保護されている。
https通信←(1) サーバの秘密鍵・公開鍵ペアで暗号化されている←(2) ドメイン名と公開鍵の組み合わせが正しいことはCAが発行する電子証明書で保証されている←(3) CAの電子証明書はOSにプリインストールされたCA公開鍵で検証可能
広告を差し替えたりする技術は、中間者攻撃と呼ばれるもので、
クライアント<=暗号通信路a=>中間者<=暗号通信路b=>サーバ
こういう仕組み。暗号通信路bの方は、単なるhttps通信なので特になにもしなくても普通に通る。暗号通信路aの方は、普通にやると、上記の(1)~(3)のどれかが通らない。
なぜなら、中間者は、(1)の秘密鍵を知ることが出来ないので、暗号通信路bで使えるのは、何か適当にでっち上げた偽の秘密鍵・公開鍵ペアに限られる。
ところが、そのようにして作った公開鍵に対しては、(2)の電子証明書を用意できない。CAに、自分が管理していないドメインの証明書の発行を依頼しても蹴られるし。
しょうがないので、(2)の電子証明書も中間者がCA秘密鍵・公開鍵をでっち上げて署名をする。これは、(3)の段階で、そんなCAは居ない、としてブラウザが蹴る。
そんなこんなで、中間者攻撃を防げる、という仕組みにしてあるのがhttps。
謎のルート証明書をインストールするというのは、(3)がザルになるという事。
中間者攻撃を防ごうとした結果、https通信のウィルスチェックをしたいとか、広告を差し替えたいというような、サーバとブラウザの間のどこかに「何か素晴らしく好ましい機能」を持たせようとしても出来ないことになる。それでは困ると言うユーザの要望に基づいて、敢えて、「そのためのルート証明書を入れて(3)をザルに」というのがこの話の根っこ。(※そんなつもりは無いのに勝手に入っていた、という事例に対する皮肉)
中間者が用意した独自のルート証明書をOSに入れて(3)の壁さえ突破すれば、あらゆるhttps通信に対して、その場で必要な証明書をでっちあげて、ブラウザのチェックをスルーさせることが出来る。「中間者」が色んな意味で信頼出来る範囲において、セキュリティ上の問題は増えない。
ただ、信頼出来ないクソ「中間者」が居る、というのが今回の問題。具体的には、(3)用にインストールされた「中間者の証明書」を第三者が悪用できる状態。
なぜ悪用できるかというと、上記の(2)や(3)を実行するため、つまり、「中間者の証明書で署名された文書」を作るための、中間者の秘密鍵がモロバレだったから。
モロバレにしない方法はいくつかあって、
イ) 各PCにインストール後、そのPC専用の秘密鍵、公開鍵を作る。 PC内のデータが盗み取られない限り、秘密鍵は安全ロ) 同じ秘密鍵・暗号鍵を多数のPCで使い回す場合は、秘密鍵が流出しない対策を行う。 例えば、社内プロクシに「中間者」機能を持たせ、そのサーバへの本来の用途以外でのアクセスは禁じるなど。 そのCA証明書を、全社のPCにインストールする。
とか。個人用PCに入れるなら、イ、企業など向けの、社内外の通信のウィルスチェックを行うシステムなんかは、ロのやり方で実装されてたりと、いろいろ。ロの場合は、社内の全PCに共通の秘密鍵、暗号鍵を使っても、秘密鍵にアクセス出来る人が居ないので大丈夫。(社内アドミンはアクセス出来るので、もちろん、その人らは変なことをしないという大前提がまた必要)
Lenovoの件は、イの仕組みなのに、全世界共通の秘密鍵・公開鍵だったというのが実施者の頭が沸いてた部分。自分のPCで動いてるsuperfishとやらを解析すると、いとも簡単に秘密鍵が出てきた。それを使うと、superfishが入ってる全PCに対して中間者攻撃が出来てしまうので、Lenovoユーザにとって、httpsの暗号化が無意味になってしまう。
と言うのが、今回のお祭りの概要。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
鍵管理 (スコア:2)
iida
Re: (スコア:0)
詳しい解説お願いします。
Re:鍵管理 (スコア:4, 参考になる)
めんどくさいのでいろいろ省略するけど、
httpsの通信は、以下のような流れで保護されている。
https通信←(1) サーバの秘密鍵・公開鍵ペアで暗号化されている
←(2) ドメイン名と公開鍵の組み合わせが正しいことはCAが発行する電子証明書で保証されている
←(3) CAの電子証明書はOSにプリインストールされたCA公開鍵で検証可能
広告を差し替えたりする技術は、中間者攻撃と呼ばれるもので、
クライアント<=暗号通信路a=>中間者<=暗号通信路b=>サーバ
こういう仕組み。暗号通信路bの方は、単なるhttps通信なので特になにもしなくても普通に通る。
暗号通信路aの方は、普通にやると、上記の(1)~(3)のどれかが通らない。
なぜなら、中間者は、(1)の秘密鍵を知ることが出来ないので、暗号通信路bで使えるのは、
何か適当にでっち上げた偽の秘密鍵・公開鍵ペアに限られる。
ところが、そのようにして作った公開鍵に対しては、(2)の電子証明書を用意できない。
CAに、自分が管理していないドメインの証明書の発行を依頼しても蹴られるし。
しょうがないので、(2)の電子証明書も中間者がCA秘密鍵・公開鍵をでっち上げて署名をする。
これは、(3)の段階で、そんなCAは居ない、としてブラウザが蹴る。
そんなこんなで、中間者攻撃を防げる、という仕組みにしてあるのがhttps。
謎のルート証明書をインストールするというのは、(3)がザルになるという事。
中間者攻撃を防ごうとした結果、https通信のウィルスチェックをしたいとか、広告を差し替えたいというような、
サーバとブラウザの間のどこかに「何か素晴らしく好ましい機能」を持たせようとしても出来ないことになる。
それでは困ると言うユーザの要望に基づいて、敢えて、「そのためのルート証明書を入れて(3)をザルに」というのがこの話の根っこ。
(※そんなつもりは無いのに勝手に入っていた、という事例に対する皮肉)
中間者が用意した独自のルート証明書をOSに入れて(3)の壁さえ突破すれば、あらゆるhttps通信に対して、
その場で必要な証明書をでっちあげて、ブラウザのチェックをスルーさせることが出来る。
「中間者」が色んな意味で信頼出来る範囲において、セキュリティ上の問題は増えない。
ただ、信頼出来ないクソ「中間者」が居る、というのが今回の問題。
具体的には、(3)用にインストールされた「中間者の証明書」を第三者が悪用できる状態。
なぜ悪用できるかというと、上記の(2)や(3)を実行するため、
つまり、「中間者の証明書で署名された文書」を作るための、中間者の秘密鍵がモロバレだったから。
モロバレにしない方法はいくつかあって、
イ) 各PCにインストール後、そのPC専用の秘密鍵、公開鍵を作る。
PC内のデータが盗み取られない限り、秘密鍵は安全
ロ) 同じ秘密鍵・暗号鍵を多数のPCで使い回す場合は、秘密鍵が流出しない対策を行う。
例えば、社内プロクシに「中間者」機能を持たせ、そのサーバへの本来の用途以外でのアクセスは禁じるなど。
そのCA証明書を、全社のPCにインストールする。
とか。個人用PCに入れるなら、イ、
企業など向けの、社内外の通信のウィルスチェックを行うシステムなんかは、ロのやり方で実装されてたりと、いろいろ。
ロの場合は、社内の全PCに共通の秘密鍵、暗号鍵を使っても、秘密鍵にアクセス出来る人が居ないので大丈夫。
(社内アドミンはアクセス出来るので、もちろん、その人らは変なことをしないという大前提がまた必要)
Lenovoの件は、イの仕組みなのに、全世界共通の秘密鍵・公開鍵だったというのが実施者の頭が沸いてた部分。
自分のPCで動いてるsuperfishとやらを解析すると、いとも簡単に秘密鍵が出てきた。
それを使うと、superfishが入ってる全PCに対して中間者攻撃が出来てしまうので、
Lenovoユーザにとって、httpsの暗号化が無意味になってしまう。
と言うのが、今回のお祭りの概要。