アカウント名:
パスワード:
組織のプライベートネットワーク内の通信を覗くためという話ですが、たぶんプライベートネットワーク内ではなく、外部との通信内容を覗き見るために使われたのでしょう。あくまで、覗き見した場所がプライベートネットワーク内だったというだけで。そうでなくては、Google関連のドメインが不正に使われた理由が不明。
内部統制で社員がどんな動画を見てんだ、どんなファイルをクラウドにアップロードしてるんだ、というような検査をする場合にSSLを使われると内容がわかりません。
最近は内部統制はもちろん、標的型攻撃による情報盗難に対抗するため出口対策をとっているところも多いと思いますが、そこでもSSL通信は弊害となります。プロキシを導入したり、FirewallでHTTPSを開けていたりするところも多いと思いますが、標的型攻撃で送り込まれたマルウェアがSSLで外部に情報を流すことを防ぐことが難しくなります。
ゲートウェイ型のウィルスチェックでも、SSL通信でダウンロードされるマルウェアはチェックできません。そのため、Webレピュテーションなどが必要になりますが、いたちごっこ。
ここで、セキュリティ対策製品で、SSLの中間攻撃と同じ手法で通信をぶんどるソリューションがいくつか出ています。というか、そういう機能が無いと、もはや役には立たないでしょう。
でも、この場合は必ずしも中間攻撃するdstの証明書を偽装する必要はないわけですが、Googleをわざわざ不正に使ったのは内部の調査を秘密裏に行おうとしたのではないか、と推測できます。
単にhttp以外通さなきゃ良いんじゃないの?
サーバ証明書をでっち上げるわけですから、少なくとも証明書のSubject(CN)を本物の証明書と合わせておかないとブラウザでホスト名不一致の警告が出てしまいます。(SubjectAltName拡張の場合もあり)
Googleだけ狙い撃ちにしたわけじゃなく単にあらゆるドメイン宛の通信を検閲していて、Chromeが「Googleサイトの証明書なのにGoogleの認証局(Google Internet Authority)を使っていない、おかしいぞ!?」と検知しただけなのかなと。そのアラートが無断でGoogleにアップされるのはどうよ?という疑問はあるけど。
SSL通信をぶんどるために一々ルート証明書をブラウザに入れさせなきゃいけないとかとても面倒、スマホやタブレットじゃできないのもあるし…名前の通ったメーカーが根回しして、ちゃんとルートからたどれる中間認証局になれるファイアウォールなりをできるだけ安価に提供してくれるとありがたいのですが。
ちゃんとルートからたどれる中間認証局になれるファイアウォールなりを
誰がその中間認証局を署名するんだね?そんなルート認証局は信用性無しで、ブラウザには載らないと思う↓
SSL通信をぶんどるために一々ルート証明書をブラウザに入れさせなきゃいけないとかとても面倒
末端でやるのが無理だから、今でも通信を一度メーカーにリダイレクトして検査してもらうようなサービスがあるけど、SSLもそうするしかないかもしれないですね。ヴェリサイン社やジオトラスト社がどこかと組んでそういうサービス始めたらみなさんはどうします?
verisign site finder [wikipedia.org]の話題から10年経ちましたね。10年前に半年やって猛反発の末やめたのはCAの仕事を枉げることではなくレジストラの仕事を枉げることでしたけど。
で、そのルート証明書をインストールさせなくても乗っ取りできるように中間認証局自体が偽証明書を発行したというのが今回の事件で、各ブラウザはその証明書の無効化を流す必要があったということなのじゃないですか?
Googleで推し進めてるSPDYな通信を覗きたかったからじゃないの?httpsのポート使うから普通のやり方じゃ面倒だし
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
内部統制として不都合なSSL (スコア:0)
組織のプライベートネットワーク内の通信を覗くためという話ですが、
たぶんプライベートネットワーク内ではなく、外部との通信内容を覗き
見るために使われたのでしょう。
あくまで、覗き見した場所がプライベートネットワーク内だったという
だけで。
そうでなくては、Google関連のドメインが不正に使われた理由が不明。
内部統制で社員がどんな動画を見てんだ、どんなファイルをクラウドに
アップロードしてるんだ、というような検査をする場合にSSLを使われる
と内容がわかりません。
最近は内部統制はもちろん、標的型攻撃による情報盗難に対抗するため
出口対策をとっているところも多いと思いますが、そこでもSSL通信は
弊害となります。
プロキシを導入したり、FirewallでHTTPSを開けていたりするところも
多いと思いますが、標的型攻撃で送り込まれたマルウェアがSSLで外部に
情報を流すことを防ぐことが難しくなります。
ゲートウェイ型のウィルスチェックでも、SSL通信でダウンロードされる
マルウェアはチェックできません。
そのため、Webレピュテーションなどが必要になりますが、いたちごっこ。
ここで、セキュリティ対策製品で、SSLの中間攻撃と同じ手法で通信を
ぶんどるソリューションがいくつか出ています。
というか、そういう機能が無いと、もはや役には立たないでしょう。
でも、この場合は必ずしも中間攻撃するdstの証明書を偽装する必要は
ないわけですが、Googleをわざわざ不正に使ったのは内部の調査を
秘密裏に行おうとしたのではないか、と推測できます。
Re:内部統制として不都合なSSL (スコア:1)
単にhttp以外通さなきゃ良いんじゃないの?
Re: (スコア:0)
1. 社内の全てのコンピュータに、「中間者攻撃用証明書」をインストールしておく
2. プロキシサーバなり外向きのゲートウェイなりは、https通信を検出したら、中間者攻撃用証明書の元になった秘密鍵を使って、
リクエストのあった通信先の証明書をでっち上げ、その証明書で自分自身がクライアントとhttpsで通信を開始
3. ゲートウェイは本来の接続先に通常のhttpsで接続してデータをやりとり、クライアントに転送する
と、やれば、社外から見ると元通り。
社内的にも、ルータまでhttpsで保護されているので、社内のハブやらに何かを仕込んでデータを盗み出す事も出来ない。
少なくとも、https直結の場合と同じセキュリティは保てる。
唯一、ゲートウェイが乗っ取られると、全部の通信がだだ漏れだけど、
まあ、これは、通信データを総チェックしたいという要望からしてしょうがない。
Re:内部統制として不都合なSSL (スコア:1)
サーバ証明書をでっち上げるわけですから、少なくとも証明書のSubject(CN)を本物の証明書と合わせておかないとブラウザでホスト名不一致の警告が出てしまいます。(SubjectAltName拡張の場合もあり)
Googleだけ狙い撃ちにしたわけじゃなく単にあらゆるドメイン宛の通信を検閲していて、Chromeが「Googleサイトの証明書なのにGoogleの認証局(Google Internet Authority)を使っていない、おかしいぞ!?」と検知しただけなのかなと。
そのアラートが無断でGoogleにアップされるのはどうよ?という疑問はあるけど。
Re: (スコア:0)
SSL通信をぶんどるために一々ルート証明書をブラウザに入れさせなきゃいけないとかとても面倒、スマホやタブレットじゃできないのもあるし…
名前の通ったメーカーが根回しして、ちゃんとルートからたどれる中間認証局になれるファイアウォールなりをできるだけ安価に提供してくれるとありがたいのですが。
Re: (スコア:0)
Re: (スコア:0)
ちゃんとルートからたどれる中間認証局になれるファイアウォールなりを
誰がその中間認証局を署名するんだね?
そんなルート認証局は信用性無しで、ブラウザには載らないと思う
↓
SSL通信をぶんどるために一々ルート証明書をブラウザに入れさせなきゃいけないとかとても面倒
Re: (スコア:0)
末端でやるのが無理だから、今でも通信を一度メーカーにリダイレクトして検査してもらうようなサービスがあるけど、SSLもそうするしかないかもしれないですね。ヴェリサイン社やジオトラスト社がどこかと組んでそういうサービス始めたらみなさんはどうします?
Re:内部統制として不都合なSSL (スコア:1)
verisign site finder [wikipedia.org]の話題から10年経ちましたね。
10年前に半年やって猛反発の末やめたのはCAの仕事を枉げることではなくレジストラの仕事を枉げることでしたけど。
Re: (スコア:0)
その機械がハックされた場合の被害が買った人の家庭か会社内に止まるならアリでしょうけど、影響はインターネット全体に及びます。
買った人にだけ影響するようにするには、使いやすいインストーラとかで
PCやタブレットに専用の証明書を簡単にインストール出来る仕組みを用意する、ぐらいですかね。
Re: (スコア:0)
で、そのルート証明書をインストールさせなくても乗っ取りできるように中間認証局自体が偽証明書を発行したというのが今回の事件で、各ブラウザはその証明書の無効化を流す必要があったということなのじゃないですか?
もっと単純じゃないの? (スコア:0)
Googleで推し進めてるSPDYな通信を覗きたかったからじゃないの?
httpsのポート使うから普通のやり方じゃ面倒だし