Firefox2とIE7でSSL Handshakeが違う

 article  Comments Off on Firefox2とIE7でSSL Handshakeが違う
Nov 262006
 

最近になって一部のSSLサイトにFirefoxで接続できない状況に出くわすようになりました。
IE7だと接続できたりするので、ちょっとパケットキャプチャして比べてみると最初のSSL Handshakeが異なっているようです。

Firefox2は「SSLv2 Record LayerでVersion:SSL 3.0」、
IE7は「SSLv3 Record LayerでVersion:TLS 1.0」
となってます。実はどう表現したらいいのかわからないんですが… 🙁

Firefoxで接続できないからといって「サイトがSSLv2になっている」とか「IE7はおかしい」といったことでは必ずしもないようです。

しかしIE7やFirefox2でSSLv2がデフォルト無効になったのは有名な話でしたが、実装は違うものですね。

SSL Handshake on Firefox 2

SSL Handshake on Internet Explorer 7

Nov 112006
 

入れっぱなしだったSnortとBASEをきちんとセットアップしました。

MySQL database, user作成

% echo "CREATE DATABASE snort"|mysql -u root -p
% echo "GRANT ALL PRIVILEGES on snort.* to snort@localhost IDENTIFIED BY PASSWORD('hogehoge')"|mysql -u root -p

snortだけならユーザ権限はもっと少なくてよいのですが、BASEのセットアップ時にテーブルをCREATEする権限が必要になってくるため、全権限を付与しています。

Debianパッケージ設定実行

dpkg-rconfigureを実行して、作成したdatabseとuserをSnortとBASEに設定してあげます。

# dpkg-reconfigure snort-mysql
# dpkg-reconfigure acidbase

結果、MySQL接続情報が以下の設定ファイルに反映されます。

  • /etc/snort/snort.conf
  • /etc/acidbase/database.php

これでsnortのアラートがMySQLデータベースに記録されるようになり、BASEもそれを使うようになります。

BASEの追加設定

http://localhost/acidbase/にアクセスすると、テーブルをCREATEするボタンがあるので、そちらを押下すれば終了です(このためsnortユーザにALL PRIVILEGESを与えてます)。
初期状態ではlocalhost以外からのアクセスは許可されないので、必要に応じて/etc/acidbase/apache.confのdeny,allow定義を変更します。

除外ルールの設定

debianでは、ユーザが追加するためのルールファイルが/etc/snort/rules/local.rulesとして用意されています。
うちの場合、/etc/snort/rules/misc.rulesにある”MISC UPnP malformed advertisement”をルータが出して検知されてしまうので($HOME_NETはanyにしています)、以下のようにして除外しました。

# cd /etc/snort/rules
# grep 'MISC UPnP malformed advertisement' \
> |sed 's#^alert #pass #' \
> |sed 's#$EXTERNAL_NET#192.168.0.1/32#' >>local.rules

ルールの先頭alertをpassに変更すれば、無視されるようになります(192.168.0.1はルータのIPアドレスです)。

ただし、この方法はルールセットのテスト順を”Pass->Alert->Log”に設定した場合のみ有効です(snortを-oオプションで起動)。
“Alert->Pass->Log”にしている場合は、alertが定義されているルールファイルを直接編集して無効にする必要があります。

BASEでグラフ表示するために – 2006-11-13追記

BASEでのグラフ表示時に「Image/Color.phpがない」とエラーになりました。

Warning: main(Image/Color.php): failed to open stream: No such file or directory in /usr/share/php/Image/Canvas/Color.php on line 33

Debianパッケージは見つけられなかったので、pearでインストールして解決。

# pear install Image_Color
Jul 282006
 

出先から自宅にsshしてメールを読むためにポートフォワード専用ユーザを作りました。
~/.ssh/authorized_keysに以下を記述して、いろいろ制限しています。

no-agent-forwarding,no-X11-forwarding,no-pty,permitopen="localhost:143",permitopen="localhost:80",command="/bin/sleep 8h"

tty端末アクセスを許さず、フォワード可能なポートも制限しています(ポートフォワード自体を禁止したい場合はno-port-forwardingでおこなえます)。

さらに、公開鍵をscpで書き換えられたら意味がないので、sleepコマンドを強制的に実行して実質何もできない状態にしました。

こちらの公開鍵に記述できる内容は、sshd(8)マニュアルのAUTHORIZED_KEYS FILE FORMATに書かれています。

Jun 042006
 

自宅内のサーバ間はホストベース認証にしてみました。
正直、ここに書いてあることを読むより

を見ていただいたほうがよっぽどわかりやすく、かつ有益だと思います。

環境

  • サーバ(接続先) : server.example.jp
  • クライアント(接続元) : client.example.jp

上記ホストは/etc/hostsもしくはDNSに登録済みで正引き逆引きともに名前解決可能であることとします。

サーバでの準備

/etc/ssh/sshd_configの設定変更

Protocol 2のみ使用することにしてますので以下の設定を加えます。Protocol 1も使う場合は別の設定が必要ですが、今更使うことは推奨されませんので割愛します。

ホストベース認証を有効にします。
HostbasedAuthentication yes

~/.ssh/known_hostsを信用しません。/etc/ssh/ssh_known_hostsに公開鍵を追加したホストのみホストベース認証を許可します。
IgnoreUserKnownHosts yes

~/.rhostsや~/.shostsを信用しません。/etc/hosts.equivなどのシステムファイルに記述されたホストのみ接続を許可します。
IgnoreRhosts yes

ただしrootユーザの場合は/etc/hosts.equivを見にいってくれません。rootでもホストベース認証したい場合、こちらはnoのままにしておいて~/.rhostsや~/.shostsを有効にする必要があります(auth-rhosts.cで判定しているっぽい)。

クライアントの公開鍵を登録

接続元となるホストからホスト公開鍵をもってきて、/etc/ssh/ssh_known_hostsに登録します。

# ssh-keyscan -t rsa client.example.jp >> /etc/ssh/ssh_known_hosts

IgnoreUserKnownHosts yesにより、ホストベース認証時はユーザの~/.ssh/known_hostsは無視されますので、こちらへの公開鍵登録が必須となります。

接続許可ホスト限定

/etc/ssh/shosts.equivに許可ホストのエントリを追加します(rootの場合は~/.shosts)。

# echo client.example.jp >> /etc/ssh/shosts.equiv

IgnoreRhosts yesにより、ユーザの~/.rhostsや~/.shostsは無視されますので、こちらや/etc/hosts.equiv等へのエントリ追加が必須となります。

クライアントでの準備

この状態で一端接続してみます。

$ ssh -o HostbasedAuthentication=yes server.example.jp
ssh-keysign not enabled in /etc/ssh/ssh_config
ssh_keysign: no reply
key_sign failed
Enter passphrase for key '/home/foobar/.ssh/id_dsa':

という具合に接続元ホストの/etc/ssh/ssh_configを変更が必要といわれます。またHostbasedAuthentication=yesをいちいち指定するのも面倒ですので、これらの設定を/etc/ssh/ssh_configに追加します。

Host *
  HostbasedAuthentication yes
  EnableSSHKeysign yes

■2009-04-04追記
ssh-keyscanで取り込んだ公開鍵が実際の公開鍵(/etc/ssh/ssh_host_rsa_key.pub等)と異なっていて接続できない場合あり。
原因は追求していないが公開鍵ファイルを直接登録して凌いだ。

May 042006
 

SMTP認証のPLAINとLOGINって何が違うのだろうか、と思って調べてたときのリンク集です。

PLAIN認証は1ステップ(httpのBASIC認証に似てます)でRFCあり、LOGIN認証は2ステップでRFCなし。
なぜにLOGIN認証があるのか謎ですが、とりあえず両方利用できる環境であればPLAINを使うようにしようと思いました。

なお、PLAIN認証やLOGIN認証を「最低限の暗号化はされている」と説明する人もいるようですが、HTTPのBASIC認証と同じようにBASE64エンコードされているだけですので、デコードすれば簡単にばれます。SSLやTLS下での利用が推奨されておりますのでご注意を。

Apr 272006
 

Apacheドキュメントの名前ベースのバーチャルホストにもあるように、名前ベース(NameVirtualHost)では複数のSSLサイトを提供することができません(ポートを変えられれば名前ベースではなくなるので、ポート80のhttpサイトとポート443のhttpsサイトを提供可)。

名前ベースのバーチャルホストは SSL プロトコルの特徴により、 SSL セキュアサーバには使えません。

こちら各所のコミュニティでも時折でてくるFAQですが、それを解決しようとするRFCがあったようです。Apache ユーザーズメーリングリストへの投稿で知りました(こちらのスレッド)。

実装にはブラウザ側の対応も必要なので、Apacheで積極的に実装しようという動きにはならないように思います。MicrosoftがIISとIEに実装するような動きに出れば変わるかも知れませんが。
もしくはIPv6化が進んで、名前ベースのバーチャルホストが不要にならないかな。

Apr 072006
 

smpatch updateしたら

122856-01 SunOS 5.10: sendmail patch

が含まれてました。2006-04-06に出たパッチのようです。
以前「Solarisのsendmailパッチ」で書いたときのISRとは番号が違うのですが、
Security Vulnerability in sendmail(1M) Versions Prior to 8.13.6
を見ると正式版のようです(以前のIDRの記述は消えてます)。

早速適用してみたのですが

Failed to install patch 122856-01.

patchadd utility failed. Reason code :0
Checking installed patches...Verifying sufficient filesystem capacity (dry run method)...Patch 122856-01 failed to install due to a failure produced by pkgadd.See /var/sadm/patch/122856-01/log for detailsPatchadd is terminating. Transition old-style patching.
ALERT: Failed to install patch 122856-01.

となり適用できません。ログには

This appears to be an attempt to install the same architecture and
version of a package which is already installed.  This installation
will attempt to overwrite this package.

PaTcH_MsG 23 Patch number 122856-01 cannot be applied until all restricted patch
es are backed out.
Dryrun complete.
No changes were made to the system.

This appears to be an attempt to install the same architecture and
version of a package which is already installed.  This installation
will attempt to overwrite this package.

PaTcH_MsG 23 Patch number 122856-01 cannot be applied until all restricted patch
es are backed out.
Dryrun complete.
No changes were made to the system.

へぇ、こんな風になるんだ、と思いつつ、以前のIDR122825-02をpatchrmしてから再びsmpatch updateしたところ無事適用されました 😀

# /etc/init.d/cswfetchamail stop
# svcadm disable -t sendmail
# patchrm IDR122825-02
# smpatch update
Apr 022006
 

Security Vulnerability in sendmail(1M) Versions Prior to 8.13.6
のRelief/Workaround記載のとおり、正式リリース前のパッチであるISRが提供されていたようです。

smpatchでチェックしてただけなので全然パッチは出ていないと思ってました。
まさかこんな形でリリースされることがあるとは。

MTAはEximに移行したとはいえ、適用してみたいのでやってみました。
とはいってもsendmailバイナリの一部は、既にEximによって置き換えられてますので、そちらを戻す必要があります。

Exim削除

まずはメール関連のデーモン止めてEximを削除します。

# /etc/init.d/cswfetchmail stop
# /etc/init.d/cswexim stop
# cp -p /opt/csw/etc/exim/exim.conf .
# pkgrm CSWexim

sendmailパッチ適用

# unzip IDR122825-02.zip
# patchadd IDR122825-02

sendmailバージョン確認

# /usr/sbin/sendmail -d0.1 -bv
Version 8.13.6+Sun
 Compiled with: DNSMAP LDAPMAP LOG MAP_REGEX MATCHGECOS MILTER MIME7TO8
                MIME8TO7 NAMED_BIND NDBM NETINET NETINET6 NETUNIX NEWDB NIS
                NISPLUS PIPELINING SCANF STARTTLS TCPWRAPPERS USERDB
                USE_LDAP_INIT XDEBUG

============ SYSTEM IDENTITY (after readcf) ============
      (short domain name) $w = mail
  (canonical domain name) $j = mail.example.jp
         (subdomain name) $m = example.jp
              (node name) $k = mail.example.jp
========================================================

Recipient names must be specified

晴れてバージョンが8.13.6+Sunになりました。

Mar 292006
 

SSLクライアント証明書あれこれ」でのCourier-IMAPのように、クライアント証明書を要求するメールサーバにWanderlustから接続する方法です。
WanderlustはEmacs上で動作するMUAですが、SSL関係はopensslコマンドを呼び出して処理するようになってます。
接続はopenssl s_clientコマンドになりますので、そちらの引数にクライアント証明書の指定をすればよいことになります。

;; IMAP over SSL
(require 'ssl)
(setq ssl-certificate-directory (expand-file-name "~/.ssl/certs"))
(setq ssl-program-arguments
      (append ssl-program-arguments
              '("-cert" my-ssl-client-certfile
                "-key"  my-ssl-client-keyfile)))
(setq my-ssl-client-certfile (expand-file-name "~/.ssl/ssl.crt"))
(setq my-ssl-client-keyfile  (expand-file-name "~/.ssl/ssl.key"))

この例ですと、IMAPに限らずSMTPなどのSSL接続に対しても効いてしまうことになりますので、本来であれば接続タイプを別に用意する、特定のサイトに接続する場合のみに効くようにする、などの対処をするのがベストかと思いますが、私にはそこまでできません orz

~/.ssl/certs/ディレクトリには認証局の証明書を格納してc_rehashしておきます。
また秘密鍵(~/.ssl/ssl.key)のパスフレーズ入力要求には対応できていないので、予めopenssl rsaコマンドを使って、パスフレーズを解除しておく必要があります。

Mar 262006
 

Red Hat 9で運用しているサーバがあります。
いまどきmajordomoでメーリングリストを運営していたりするのですが、先ごろ発表されたsendmailの脆弱性対応でパッケージをアップデートしたら、majordomoが動かなくなってしまいました。
sendmailはFedoraLegacyプロジェクト提供のパッケージで、sendmail-8.12.8-9.90からsendmail-8.12.11-4.24.1.legacyへの更新になります。

原因は/usr/lib/sendmailがなくなったことでした。/usr/lib/sendmail.sendmailにシンボリックリンクして対応完了。

ところでSunからのパッチ提供はいつ頃になるでしょう 😕