TATEISHI Katsuyuki
tatei****@oss*****
2009年 5月 14日 (木) 15:59:14 JST
立石です。 From: Shinya TAKEBAYASHI <omoik****@gmail*****> Subject: [Ultramonkey-l7-develop 351] Re: 次期リリースについて Date: Thu, 14 May 2009 14:34:01 +0900 >> のように途中で SSL セッション ID が変わっているようですので、 >> 「Ctrl-r押しっぱなし」というやりかたがまずいのかもしれません。 > > 逆向き（Apache → クライアント）のパケットも解析してみる必要があります． > > クライアントから「この ID 再利用できるか」と Apache に聞いたあとに > 使えなければ別の SSL セッション ID が払い出させるシーケンスになります． > > そのため，提示いただいたクライアント → Apache のみの内容だと， > > (1) ブラウザは SSLID を再利用しようとしているのか > SSL ネゴシエーションの際に，クライアントから SSLID を送信する > > (2) Apache が「使えない」と判断して新しい ID を払い出しているのか > Apache が，クライアントが提示したものと異なる SSLID を返す > > が分かりません． > > 時間が許すのであれば，調査願います． 情報ありがとうございます。 クライアント→ Apache の SSL session ID が切り替わっているあ たりの両方向のやりとり(SSLハンドシェイクのみ抜粋)は以下のような感じでした。 ================================================================================ root ＠ alpha# tshark -r uml7.pcap -T fields -e frame.number -e ip.src -e tcp.srcport -e ip.dst -e tcp.dstport -e ssl.handshake.session_id -R "ssl.handshake.type == 1 || ssl.handshake.type == 2"|grep -C 6 '3a:d9' |sed -re 's/^(.{60}).*/\1/' Running as user "root" and group "root". This could be dangerous. 661 192.168.122.3 443 192.168.122.1 55382 1f:4b:d2:23:ac:d5: 672 192.168.122.1 55383 192.168.122.3 443 1f:4b:d2:23:ac:d5: 674 192.168.122.3 443 192.168.122.1 55383 1f:4b:d2:23:ac:d5: 685 192.168.122.1 55384 192.168.122.3 443 1f:4b:d2:23:ac:d5: 687 192.168.122.3 443 192.168.122.1 55384 1f:4b:d2:23:ac:d5: 693 192.168.122.1 55385 192.168.122.3 443 695 192.168.122.3 443 192.168.122.1 55385 3a:d9:c0:2a:dc:4c: 707 192.168.122.1 55386 192.168.122.3 443 709 192.168.122.3 443 192.168.122.1 55386 2a:f2:72:9e:07:11: 724 192.168.122.1 55387 192.168.122.3 443 2a:f2:72:9e:07:11: 726 192.168.122.3 443 192.168.122.1 55387 2a:f2:72:9e:07:11: 737 192.168.122.1 55388 192.168.122.3 443 2a:f2:72:9e:07:11: 739 192.168.122.3 443 192.168.122.1 55388 2a:f2:72:9e:07:11: ================================================================================ なお、フォーマットはコマンドラインを見ていただくと想像がつく かと思いますが、左から順に <フレーム(パケット)番号> <送信元IPアドレス> <送信元TCPポート> <宛先IPアドレス> <宛先TCPポート> <SSL Session ID> となっています。(行頭から60桁で切り捨て。空白はタブなので↑で は80 桁くらいに見えます) 192.168.122.1 がクライアント(firefox)、192.168.122.3 が UltraMonkey-L7です。 SSL Session ID のネゴシエーションについてちゃんと理解してない ので予測なのですが・・・ ●まずフレームNo. 695 でサーバ→クライアントにそれまでと違う SSL Session ID(3a:...)を送付しています。 このとき直前の Client Hello (No.693)では Session ID はついて いません。ポート番号からフレームNo.693, 695は同一のTCPセッショ ンでのやりとりと思われます。 つまり提示していただいた (1)-(2) のような挙動に該当しそうに はなく、 ☆クライアントが Client Hello でSSL Session IDを提示しない →サーバからSSL Session IDを提示 という動きをしているように見えます。 ●次にフレームNo. 709 においてもサーバ→クライアントに新しい SSL Session ID(2a:...)が送付されていますが、こちらも直前のフ レームNo. 707 ではセッションIDがついておらず、 ☆クライアントが Client Hello でSSL Session IDを提示しない →サーバからSSL Session IDを提示 という動きをしているように見えます。 ●ちなみにNo. 724, 726 など他のやりとりをみると (1)の動きをし て、サーバがクライアントから提示された SSL Session ID を受け 入れているように見えます。 ということで、 Firefox が SSL Session ID を再利用しないことがあるため、その タイミングで振り先が変わった。 (UltraMonkey-L7 sslid モジュールの動作としては問題なし。) というのが今回の挙動の説明になりそうですが、いかがでしょうか？ ちなみに 695 で提示されたセッション ID が1回で終わっている理 由ですが、この TCP セッションは直後に Certificate Unknown で 終了しており、おそらく 1. 振り先が変わって証明書が変わり、かつオレオレ証明書なのでエ ラーになった 2. 私は気付かずCtrl-r押しっぱなしでリロード 3. SSL Session IDがついていないのでラウンドロビンにより振り先 が元に戻って新しいSSL Session 開始。ただし証明書は 1 以前に 受け入れ済み。 4. 新しい SSL Session ID でリクエストが繰り替えされる ということだと思います。 リアルサーバの証明書を揃えてやってみましたが、 ============================================================ [root ＠ charlie ~]# l7vsadm Layer-7 Virtual Server version 2.1.2-2 Prot LocalAddress:Port ProtoMod Scheduler -> RemoteAddress:Port Forward Weight ActiveConn InactConn TCP charlie.example.jp:https sslid rr -> 192.168.123.32:https Masq 1 0 2136 -> 192.168.123.33:https Masq 1 0 0 ============================================================ 今度は切り替わり自体発生しませんでした・・・orz -- TATEISHI Katsuyuki <tatei****@oss*****>
UltraMonkey-L7
Fork