アカウント名:
パスワード:
どこにも「カスペルスキーのサーバーと通信」なんて書いてないでしょ
他にどこと通信するんだ、社員の方ですか
「カスペルスキーのドメイン（正確にはPC内のカスペルスキーアプリケーション）に対してHTTPリクエストを発信している」
これですね。カスペルスキーのアプリがローカルホストに立てているHTTPサーバーと通信している、と。JSが外部サーバーと通信しているわけではないようですね。（このアプリがさらに外部サーバーと通信しているかどうかは別問題）
私ならローカルホスト内での通信を、「サーバーと通信している」とは表現しないかな…。
> カスペルスキーのアプリがローカルホストに立てているHTTPサーバーと通信している、と。
ローカルホストと通信しているだけなら、その記事で書かれている対処法の「hostsを書き換えて、それらのドメインのアドレスを127.0.0.1にする」というので事が済むはずないと思うんだけど。
nslookupでie.kis.scr.kaspersky-labs.comgc.kis.scr.kaspersky-labs.comff.kis.scr.kaspersky-labs.comme.kis.scr.kaspersky-labs.comのそれぞれのアドレスを引くと、ちゃんと外部のIPアドレスが出てくるよ。
Kaspersky Internet Security 2016 のユーザーなので検証してみました。
無駄に長文になるので結論を先に書くと、スクリプトの取得元・通信先ともにローカルホストに Kaspersky が立てているHTTP（とHTTPS）サーバで正しいようです。
～ 以下は調査方法・根拠 ～
今、Google Chrome でスラドを見ていますが、HTMLのソースには下記の外部 Java Script が注入されています。
<script type="text/javascript" src="http://gc.kis.scr.kaspersky-labs.com/1B74BD89-2A22-4B93-B451-1C9E1052A0EC/main.js" charset="UTF-8"></script>
nslookupで ie.kis.scr.kaspersky-labs.com gc.kis.scr.kaspersky-labs.com ff.kis.scr.kaspersky-labs.com me.kis.scr.kaspersky-labs.com のそれぞれのアドレスを引くと、ちゃんと外部のIPアドレスが出てくるよ。
について、試してみましたが、
ie.kis.scr.kaspersky-labs.com (http://ie.kis.scr.kaspersky-labs.com/1B74BD89-2A22-4B93-B451-1C9E1052A0EC/main.js) = 185.85.13.154gc.kis.scr.kaspersky-labs.com (http://gc.kis.scr.kaspersky-labs.com/1B74BD89-2A22-4B93-B451-1C9E1052A0EC/main.js) = 127.245.107.154ff.kis.scr.kaspersky-labs.com (http://ff.kis.scr.kaspersky-labs.com/1B74BD89-2A22-4B93-B451-1C9E1052A0EC/main.js) = 127.245.107.154me.kis.scr.kaspersky-labs.com (http://me.kis.scr.kaspersky-labs.com/1B74BD89-2A22-4B93-B451-1C9E1052A0EC/main.js) = 185.85.13.154※今使ってる環境には Edge が入っていないので Edge は nslookup のみ検証
でした。
IE と Edge 用のスクリプトのIPアドレス（185.85.13.154）は、Kaspersky Lab ZAO（ロシア連邦モスクワ）に割り当てられているものです。
しかし、Kaspersky をインストールしていない環境からは http://ie.kis.scr.kaspersky-labs.com/1B74BD89-2A22-4B93-B451-1C9E1052A... [kaspersky-labs.com] にアクセスできません（なお、185.85.13.154 では HTTPD かプロキシが一応動いてるっぽいですが、極めてレスポンスが悪く、応答が無い場合が多く、応答がある場合でも長時間経過後 504 Gateway Timeout のレスポンスが返されます）。
上記のURLには、カスペルスキーがインストールされている環境からは、どんなブラウザでもアクセスでき、JavaScript コードの取得が可能です。しかし、LAN内のカスペルスキーがインストールされていない環境や、スマホ（LTE接続）からアクセスしてみましたが、JavaScriptコードは取得できませんでした。
また、Chrome 用と Firefox 用（127.245.107.154）は、ローカル・ループバック・アドレスなので、JavaScript の取得元がローカルであることは明らかです。
つまり、Kaspersky Internet Security 2016 に含まれるソフトウェア（ファイアウォールのようなもの）が 185.85.13.154 や 127.245.107.154 宛ての通信を受信して、それに応答しているということです。
また、JavaScript のプログラムが GET や POST で通信している先についても、http(s)://ie.kis.scr.kaspersky-labs.com/長い英数字/from や http(s)://ie.kis.scr.kaspersky-labs.com/【長い英数字】/【長い英数字】/to/ob.disconnect/?get&nocache=【ランダムっぽい英数字】 などで、ホスト名は JavaScript ソースの取得元と同一でした。
IE と Edge 用の JavaScript コードの取得元とJavaScriptによる通信先のIPアドレスについて、実際の通信先がローカルなのに、グローバルIPアドレスを使用しているというのは、非常にトリッキーに感じます。
この理由については、IE や Edge は、インターネットゾーンと、ローカルホストあるいはローカルイントラネットゾーンで、セキュリティ権限が異なる扱いをするため、それを回避して「インターネットゾーン」として扱わせるためかと思います。Firefox と Chrome についてはそういったことがないので、インターネット上のサーバに情報を送信しているという誤解を招かないため、ローカル・ループバック・アドレスにしたのではないでしょうか。
127.0.0.1 ではなく 127.245.107.154 にしたのも、余計な通信の中継を防ぐための配慮でしょう。
今のブラウザは、プラグイン（拡張）の権限が制限されたり、頻繁なアップデートで仕様変更されたりしまうため、カスペルスキーのような HTTP / HTTPS 通信を中継してチェックする動作（別の言い方をすると傍受・改竄）は、セキュリティソフトの動作として合理的・最善であると思います。
ブラウザのレンダリング前に、悪意のあるコードを検出あるいは排除するためには、ブラウザの動作に割り込むか（拡張など）、HTTP / HTTPS の通信を検閲するしかありません。ブラウザのアップデート・仕様変更が頻繁に行われる現状では、後者の方が不具合が少なく安定して動作するでしょう。
ローカルホストに Kaspersky が立てているHTTP（とHTTPS）サーバ（あるいは別プロトコル）は外部のサーバと接続しているんでしょうかね？
確かにそうですね。すると原文の「正確にはPC内のカスペルスキーアプリケーション」はどう解釈すべきなのか…
Kasperskyには、Proxomitronのような内部にローカルプロキシ動作をするアプリが組み込まれます。そのローカルプロキシがscriptタグを埋め込んだりするわけです。
件のhttpリクエストもこのローカルプロキシにブラウザ内の振る舞いを報告するだけでローカルプロキシはKasperskyのサイトにはアクセスしていないと思います。
「hostsを書き換えて、それらのドメインのアドレスを127.0.0.1にする」でことが済んでいるのは、scriptタグでjsファイル取得に失敗するからだとも「バイナリ覚書」説明されています。
> scriptタグでjsファイル取得に失敗するからだ外部サーバーからスクリプトを読み込んでくるのに失敗するからじゃないの？
プロクシは自前で名前解決をするので、そのプロクシが"ie.kis.scr.kaspersky-labs.com"等のアドレスをそこで読み替えているなら、Winodwsのhostsを書き換えても動作は変わらないはずだが。
#2958795 [security.srad.jp] ローカルホストと通信しているだけなら、その記事で書かれている対処法の 「hostsを書き換えて、それらのドメインのアドレスを127.0.0.1にする」 というので事が済むはずないと思うんだけど。
#2958831 [security.srad.jp] 外部サーバーからスクリプトを読み込んでくるのに失敗するからじゃないの？ プロクシは自前で名前解決をするので、そのプロクシが"ie.kis.scr.kaspersky-labs.com"等の アドレスをそこで読み替えているなら、Winodwsのhostsを書き換えても動作は変わらないはずだが。
については、カスペルスキーがローカルに HTTP や HTTPS のサーバを立てているのならば、hosts で通信先を 127.0.0.1 にしてもエラーになるはずが無いという主張かと思います。
それについても検証してみましたが、カスペルスキーがインストールされている環境では、 http://gc.kis.scr.kaspersky-labs.com/1B74BD89-2A22-4B93-B451-1C9E1052A... [kaspersky-labs.com] や http://127.245.107.154/1B74BD89-2A22-4B93-B451-1C9E1052A0EC/main.js [127.245.107.154] には接続可能でしたが、 http://127.0.0.1/1B74BD89-2A22-4B93-B451-1C9E1052A0EC/main.js [127.0.0.1] には接続できませんでした。
127.0.0.1～127.255.255.254 は、全てローカル・ループバック・アドレスですが、127.0.0.1 と 127.245.107.154 で違う結果になりました。
つまり、カスペルスキーは HTTP と HTTPS の通信をプロキシサーバのように中継しているわけですが、接続先（GET や POST をブラウザが投げる先）のIPアドレスが 185.85.13.154 や 127.245.107.154 の場合のみ、JavaScript のソースコードの配信や JavaScript プログラムによる通信への応答を行っているということになります。
なお、HTTPS の通信についてもカスペルスキーは、一度カスペルスキーが復号して、再度カスペルスキーの秘密鍵で暗号化する方法（ブラウザにカスペルスキーのルート証明書をインストール）で間に入り込んでいます。HTTPS の通信への割り込みについては、設定で無効化可能です。その場合、HTTPS のサイトにカスペルスキーのJavaScriptが混入することはありません。
これはだめでしょ…
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
元ネタ読みましたけど (スコア:0)
どこにも「カスペルスキーのサーバーと通信」なんて書いてないでしょ
私も元ネタ読みましたけど (スコア:-1)
どこにも「カスペルスキーのサーバーと通信」なんて書いてないでしょ
他にどこと通信するんだ、社員の方ですか
ローカルに立っているサーバーを「○○○のサーバー」と表現するか否か (スコア:1)
これですね。
カスペルスキーのアプリがローカルホストに立てているHTTPサーバーと通信している、と。
JSが外部サーバーと通信しているわけではないようですね。（このアプリがさらに外部サーバーと通信しているかどうかは別問題）
私ならローカルホスト内での通信を、「サーバーと通信している」とは表現しないかな…。
Re: (スコア:0)
> カスペルスキーのアプリがローカルホストに立てているHTTPサーバーと通信している、と。
ローカルホストと通信しているだけなら、その記事で書かれている対処法の
「hostsを書き換えて、それらのドメインのアドレスを127.0.0.1にする」
というので事が済むはずないと思うんだけど。
nslookupで
ie.kis.scr.kaspersky-labs.com
gc.kis.scr.kaspersky-labs.com
ff.kis.scr.kaspersky-labs.com
me.kis.scr.kaspersky-labs.com
のそれぞれのアドレスを引くと、ちゃんと外部のIPアドレスが出てくるよ。
【検証結果】 JSの取得元と通信先はローカルホスト上のHTTPサーバで正しい (スコア:5, 参考になる)
Kaspersky Internet Security 2016 のユーザーなので検証してみました。
無駄に長文になるので結論を先に書くと、スクリプトの取得元・通信先ともにローカルホストに Kaspersky が立てているHTTP（とHTTPS）サーバで正しいようです。
～ 以下は調査方法・根拠 ～
今、Google Chrome でスラドを見ていますが、HTMLのソースには下記の外部 Java Script が注入されています。
について、試してみましたが、
でした。
IE と Edge 用のスクリプトのIPアドレス（185.85.13.154）は、Kaspersky Lab ZAO（ロシア連邦モスクワ）に割り当てられているものです。
しかし、Kaspersky をインストールしていない環境からは http://ie.kis.scr.kaspersky-labs.com/1B74BD89-2A22-4B93-B451-1C9E1052A... [kaspersky-labs.com] にアクセスできません（なお、185.85.13.154 では HTTPD かプロキシが一応動いてるっぽいですが、極めてレスポンスが悪く、応答が無い場合が多く、応答がある場合でも長時間経過後 504 Gateway Timeout のレスポンスが返されます）。
上記のURLには、カスペルスキーがインストールされている環境からは、どんなブラウザでもアクセスでき、JavaScript コードの取得が可能です。しかし、LAN内のカスペルスキーがインストールされていない環境や、スマホ（LTE接続）からアクセスしてみましたが、JavaScriptコードは取得できませんでした。
また、Chrome 用と Firefox 用（127.245.107.154）は、ローカル・ループバック・アドレスなので、JavaScript の取得元がローカルであることは明らかです。
つまり、Kaspersky Internet Security 2016 に含まれるソフトウェア（ファイアウォールのようなもの）が 185.85.13.154 や 127.245.107.154 宛ての通信を受信して、それに応答しているということです。
また、JavaScript のプログラムが GET や POST で通信している先についても、http(s)://ie.kis.scr.kaspersky-labs.com/長い英数字/from や http(s)://ie.kis.scr.kaspersky-labs.com/【長い英数字】/【長い英数字】/to/ob.disconnect/?get&nocache=【ランダムっぽい英数字】 などで、ホスト名は JavaScript ソースの取得元と同一でした。
IE と Edge 用のIPアドレスがグローバルIPアドレスな理由 (スコア:2)
IE と Edge 用の JavaScript コードの取得元とJavaScriptによる通信先のIPアドレスについて、実際の通信先がローカルなのに、グローバルIPアドレスを使用しているというのは、非常にトリッキーに感じます。
この理由については、IE や Edge は、インターネットゾーンと、ローカルホストあるいはローカルイントラネットゾーンで、セキュリティ権限が異なる扱いをするため、それを回避して「インターネットゾーン」として扱わせるためかと思います。Firefox と Chrome についてはそういったことがないので、インターネット上のサーバに情報を送信しているという誤解を招かないため、ローカル・ループバック・アドレスにしたのではないでしょうか。
127.0.0.1 ではなく 127.245.107.154 にしたのも、余計な通信の中継を防ぐための配慮でしょう。
今のブラウザは、プラグイン（拡張）の権限が制限されたり、頻繁なアップデートで仕様変更されたりしまうため、カスペルスキーのような HTTP / HTTPS 通信を中継してチェックする動作（別の言い方をすると傍受・改竄）は、セキュリティソフトの動作として合理的・最善であると思います。
ブラウザのレンダリング前に、悪意のあるコードを検出あるいは排除するためには、ブラウザの動作に割り込むか（拡張など）、HTTP / HTTPS の通信を検閲するしかありません。ブラウザのアップデート・仕様変更が頻繁に行われる現状では、後者の方が不具合が少なく安定して動作するでしょう。
Re: (スコア:0)
ローカルホストに Kaspersky が立てているHTTP（とHTTPS）サーバ（あるいは別プロトコル）は外部のサーバと接続しているんでしょうかね？
Re:ローカルに立っているサーバーを「○○○のサーバー」と表現するか否か (スコア:1)
確かにそうですね。
すると原文の「正確にはPC内のカスペルスキーアプリケーション」はどう解釈すべきなのか…
Re: (スコア:0)
Kasperskyには、Proxomitronのような内部にローカルプロキシ動作をするアプリが
組み込まれます。
そのローカルプロキシがscriptタグを埋め込んだりするわけです。
件のhttpリクエストもこのローカルプロキシにブラウザ内の振る舞いを報告する
だけでローカルプロキシはKasperskyのサイトにはアクセスしていないと思います。
「hostsを書き換えて、それらのドメインのアドレスを127.0.0.1にする」
でことが済んでいるのは、scriptタグでjsファイル取得に失敗するからだとも
「バイナリ覚書」説明されています。
Re: (スコア:0)
> scriptタグでjsファイル取得に失敗するからだ
外部サーバーからスクリプトを読み込んでくるのに失敗するからじゃないの？
プロクシは自前で名前解決をするので、そのプロクシが"ie.kis.scr.kaspersky-labs.com"等の
アドレスをそこで読み替えているなら、Winodwsのhostsを書き換えても動作は変わらないはずだが。
【検証結果】 hosts で 127.0.0.1 にするとエラーになる理由 (スコア:3)
については、カスペルスキーがローカルに HTTP や HTTPS のサーバを立てているのならば、hosts で通信先を 127.0.0.1 にしてもエラーになるはずが無いという主張かと思います。
それについても検証してみましたが、カスペルスキーがインストールされている環境では、
http://gc.kis.scr.kaspersky-labs.com/1B74BD89-2A22-4B93-B451-1C9E1052A... [kaspersky-labs.com] や http://127.245.107.154/1B74BD89-2A22-4B93-B451-1C9E1052A0EC/main.js [127.245.107.154] には接続可能でしたが、
http://127.0.0.1/1B74BD89-2A22-4B93-B451-1C9E1052A0EC/main.js [127.0.0.1] には接続できませんでした。
127.0.0.1～127.255.255.254 は、全てローカル・ループバック・アドレスですが、127.0.0.1 と 127.245.107.154 で違う結果になりました。
つまり、カスペルスキーは HTTP と HTTPS の通信をプロキシサーバのように中継しているわけですが、接続先（GET や POST をブラウザが投げる先）のIPアドレスが 185.85.13.154 や 127.245.107.154 の場合のみ、JavaScript のソースコードの配信や JavaScript プログラムによる通信への応答を行っているということになります。
なお、HTTPS の通信についてもカスペルスキーは、一度カスペルスキーが復号して、再度カスペルスキーの秘密鍵で暗号化する方法（ブラウザにカスペルスキーのルート証明書をインストール）で間に入り込んでいます。HTTPS の通信への割り込みについては、設定で無効化可能です。その場合、HTTPS のサイトにカスペルスキーのJavaScriptが混入することはありません。
Re: (スコア:0)
これはだめでしょ…