TLS renegotiation attack 対応

http://kamiyn.spaces.live.com/blog/cns!5BB0A706A97A84BA!6672.entry の続き。

freebsd-update が毎日更新しろ、と言ってきている。本当に次の更新の時に気づかない、あるいは次の更新の時にまとめて更新してしまってSSL接続ができないような状況になるのもまずい。ということでもう少しまじめに調査した。

http://www.gossamer-threads.com/lists/apache/dev/376279 より

we recommend that you ensure that
you limit your configuratin to a single ‘SSLClient require’
or ‘SSLClient none’ at VirtualHost/Sever level and remove
all other (re)negotiation changes.

VirtualHost単位で管理することを推奨している。別のところの記事も見て判明したのは、今まで自分がやっていた設定だと、以下のような状況によりSSL接続に失敗していた。

  • ホスト単位の設定としては、クライアント証明書は要求していない (optional)。そのためSSLの最初のネゴシエーションではクライアント証明書を要求していない
  • その後、特定のLocationについてクライアント証明書要求が書いてあるので、renegotiation が走る。しかし新しいlibsslはそれを禁止してしまった

サーバーが要求するrenegotiationであれば許可する設定もできるようにするのがよいのではないか、という提案も入っているが、いずれにせよVirtualHost単位で管理するようにするのが妥当であろう。

そういえばそろそろIE6サポートがなくなりつつあるので、名前ベースでのSSLサイト集約はできるようになってきたのかな? 今回の話で言えば、クライアント証明書を要求するようなサイトは社内サービスなのでport443ではなく別ポートに割り当て、というのもアリだとは思うが。

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

%d人のブロガーが「いいね」をつけました。