雑記帳 - JasminInfo

Kaspersky Internet Security 2015 にSSL通信をスキャンさせない

アドウェアSuperfishが問題になって気にする人もいそうなので書いてみます。

元は、以下の不具合について調べてたときの副産物です。（今はFirefoxにもちゃんと証明書がインストールされるようです。）
セキュリティ証明書絡みの不具合 - Kaspersky Lab Forum

KIS2015インストール時のSSL通信

• IEの場合
  

  

• Firefoxの場合
  

  

このように、初期状態ではKasperskyのルート証明書になっていて*1、SSL通信がスキャン対象になっています。

SSL通信もしっかりスキャンしたい人はこれで良いですが、SSLはブラウザまでEnd-to-Endで暗号化して欲しいとか、本来の証明書が隠れるのが嫌とか、KISが本来の証明書をちゃんと検証しているのか心配、という人はSSL通信をスキャンさせないように設定変更できます。*2

SSL通信をスキャンさせない設定

• 設定→詳細→ネットワーク、と設定項目をたどると、「暗号化された接続をスキャンする」という設定があるのでチェックを外します。
  

  

• 上記設定だけだと、GoogleなどのSSL接続の検索サイトは、まだ危険サイト診断の対象のままです。そちらも解除するには、設定→プロテクション→ウェブ保護→詳細設定、と設定項目をたどると、「危険サイト診断を有効にする」という設定があるのでチェックを外します。
  

  

  • SSL通信スキャンとは関係ないですが、KISがブラウザに追加するアドオン*3を無効にしたい場合は、「製品のプラグインを全てのWebブラウザーで自動的に有効にする」のチェックを外す必要があります。
  • 危険サイト診断の内容ですが、「危険サイト診断の設定」をクリックして出てくる以下の設定画面からすると、一種のWebフィルタリングのようです。これらのコンテンツに不用意にアクセスしたくない/させたくないなら、有効にしておくのが良いかもしれません。
    

    

設定後

• IEの場合
  

  

• Firefoxの場合
  

  

本来の証明書が表示されるようになりました。

なお、この設定だけではKasperskyのルート証明書は削除されないので、どうしても気になる人は削除しておきましょう。

アクセス数制限と負荷対策

アクセス数制限

さくらインターネットのコントロールパネルを見ると、しばらく前からアクセス制限がかかっているようです。

アクセスログを見ても、上のグラフの通り、21日以降は「503 - Service Unavailable」がいくつか発生しています。

原因

ちょっと調べてみました*1が、この制限は、転送量ではなくて同時アクセス数によるようです。

ログを見ると503になっているのは画像が多くて、他はJavaScript/CSSファイル、若干のWikiページでした。（もっとも、これだけだと単にアクセスされるリソースの中で画像が一番多いからそうなっただけかもしれませんが。）アクセスされている画像を確認してみると、モンスター、家具ページなど画像が多いページから参照されている画像が多く、画像が多いページへのアクセスが要因になっている可能性があります。

対策

画像が多いページへの対策としては、表示されている範囲＋αの画像だけを読み込む遅延ロードを既に行っていますが、これはどちらかというと転送量対策で同時アクセス数はあまり気にしていませんでした。（ただ、快適さをできるだけ損なわないように＋αをかなり大きくしていたので、2/26頃に少し範囲を絞りました。）

そこで、現在使っている遅延読み込みプログラムを少し改造して、画像の同時読み込み数を最大2に制限してみることにしました。とりあえず、これで少し様子を見てみます。

JavaScript/CSSファイルも影響しているかもしれないので、画像のようにキャッシュを強く効かせる*2ようにしても良いかもしれません。

もうちょっと根本的な対策としては、画像を別のサーバーに置くことでしょうか。

制限の解除

リソース情報に記載されている「制限」について｜さくらインターネット公式サポートサイトによると、対応完了後にメールで連絡すると、制限を解除してくれるようです。

でも、制限されない程度に対策する必要があるなら制限はあってもなくても同じような・・・。

最近2ヶ月は、負荷状況はほとんど変化していなかった（どちらかというと減少傾向）ので、何がトリガーになって制限されたのかは聞いてみても良いかもしれません。（制限されたタイミングがたまたま2/21だっただけで、もともと制限されるようなアクセス数だったのかもしれないですが。）

追記

21日頃からサーバーのload averageが増えていたので、サーバー全体としての負荷が増えたのを契機に制限をかけることにしたのかもしれません。

ECO-Wiki (acronia)のfavicon

今置いてあるfaviconは、ECO-Wiki(gamedb)のをとりあえずそのまま使っていますが、

• ECO-Wiki(gamedb)が復活したので同じだとちょっと紛らわしい
• 高解像度のfaviconも準備しておきたい

などの理由で新しいfaviconを置きたいと思っています。

そこで、とりあえずプルル・アルマのSSから作ってみたのですが、どうも16×16の画像が微妙な感じ・・・。まあこの大きさだと、どこかで妥協は必要だと思いますが。

• 案1:

  

  -

  

  ※16x16はこっちが良さそう？
• 案2:

  

  -

  

  -

  

• 案3:

  

  -

  

  -

  

  ※高解像度用(16x16は参考)

あとは、題材はこのままプルル・アルマにするのかという問題もありますね。（結構作るのに時間かかったので、私としてはもうこのままでいいかな、という気分になっちゃってますが＾＾；）

pukiwiki bodycache patch 2重include対応

以前、#includeを含んだページで更新時にキャッシュが再生成されるような改良を行いましたが、この改良では上図のように#includeや#pcommentが2重に使われていると、キャッシュが正しく再生成されないことが分かりました。

このような場合、一番深いページを更新したときに、最上位のページのキャッシュが再生成されずに残ってしまいます。これは、キャッシュを再生成するページを探すときに、#includeや#pcommentを更新されたページから1段しかたどっていないために発生する現象です。

そこで、更新時に2段までページをたどってキャッシュを再生成するように変更しました。これで、2重include/pcommentまでなら正しくキャッシュが再生成されるようになります。

ただし、3重include/pcommentには未対応です。対応は難しくありませんが、たどる段数を増やすとその分負荷も増えるので、2重までの対応としています。

見出しタイトル化のバグ

タイトルプラグイン(PukiWiki)導入に合わせて、最初に出現したレベル1見出しをタイトル扱いにする改造を行いましたが、バグがあったようです。（季節イベントページをみていて気づきました。）

• 発生条件: includeプラグインが使われており、includeで参照しているページにレベル1見出しが含まれている
• 現象: レベル1見出しが含まれる最後のincludeがタイトルとして使われてしまう。
• 原因: includeを使うとconvert_htmlが複数回呼ばれることを考慮していなかった。その結果、後で呼び出されたconvert_htmlにより見出しから抽出したタイトルが上書きされていた。
• 修正前: Heading->Heading() 内の改造箇所

  if( $this->level === 1 && !isset( $root->title ) ){
      $root->title = preg_replace('|\s*\[.*|', '', $text);
      $root->title = preg_replace('|^\*\s*|', '', $root->title);
  }
  

• 修正後: Heading->Heading() 内の改造箇所

  //初回呼び出し時は $root->id は 1
  if( $this->level === 1 && !isset( $root->title ) && $root->id === 1 ){
      $root->title = preg_replace('|\s*\[.*|', '', $text);
      $root->title = preg_replace('|^\*\s*|', '', $root->title);
  }
  

また、includeプラグインの参照先ページにtitleプラグインが含まれている場合も、同様にincludeしたページのタイトルが優先されてしまうと思われます。ただ、このような使い方はたぶんしないと思うので、こちらの問題はそのままにしておこうかと思います。

続・PukiWiki bodycache patch副作用：id重複

PukiWiki bodycache patch副作用：id重複で適用した修正ですが、不十分だったようです＾＾；

原因は、やはりconvert_htmlが複数回呼ばれることを考慮していなかったことで、

function convert_html($lines)
{
	//省略
	static $contents_id = 0;
	global $bodycache_status;
	if ( $bodycache_status === 'cached' ) { //bodycacheから取得済み
		++$contents_id;
	}
	//省略
	$body = & new Body(++$contents_id);
	//省略
}

この修正では、includeによる2回目のconvert_html出力と、メニューバーの$contents_idが共に2になってid重複してしまいます。

ものすごく場当たり的ですが、以下のように再修正しました。

	if ( $bodycache_status === 'cached' ) { //bodycacheから取得済み
		$contents_id += 90 ; //これだけ足せばきっと重複しない・・・(^_^;)
	}

いっそ、メニューバーでは見出しの自動id生成をやめた方が良い気もしてきましたが、メニューバーだけ自動id生成をやめる方が修正は面倒そうです。（もしかしたら、本文も自動id要らないかも？）