SIM フリーどさにっき 〜2014年2月中旬〜

by やまや
<< = >>

2014年2月14日(金)

■ NTP amp のヤバいところ

_ DNS amp の方がお手軽かと思ってて 軽視してたNTP amp なんだけど、 やっぱり甘く見すぎてたなぁ。反省。正直ここまでひどくなるとは思わなんだ。穴があればそれを狙うヤツはかならずいるということか。

_ NTP amp って、やってることは DNS amp とたいして変わらんのだけど、NTP の方がよりタチが悪いという側面もある。

_ 以下、自宅ネットワークの時間合わせに使ってる NTP サーバ上で ntpdc -c monlist を実行したときのパケットキャプチャ。 

22:25:17.456614 IP 127.0.0.1.49748 > 127.0.0.1.123: NTPv2, Reserved, length 192
22:25:17.456758 IP 127.0.0.1.123 > 127.0.0.1.49748: NTPv2, Reserved, length 440
22:25:17.456787 IP 127.0.0.1.123 > 127.0.0.1.49748: NTPv2, Reserved, length 440
22:25:17.456811 IP 127.0.0.1.123 > 127.0.0.1.49748: NTPv2, Reserved, length 440
22:25:17.456829 IP 127.0.0.1.123 > 127.0.0.1.49748: NTPv2, Reserved, length 80
問い合わせの192バイトのパケット1発に対して、応答として 440x3+80 = 1400 バイトのパケットを返してる。この場合は増幅率7倍ちょっとなんだけど、それだけじゃなくて応答パケットが4つになっているということにも注目。

_ DNS の場合は EDNS0 を使うと応答サイズは(多くの場合)4096バイトに拡張される。拡張したところで MTU (1500バイトとか1492とか1454とか)を越えるパケットは分割する必要があるけど、これは DNS 自体ではおこなわず、下のレイヤにおまかせしてる。結果として、DNS の応答は EDNS0 をめいいっぱいに使った場合でもせいぜい3パケットか4パケット程度で収まる。

_ が、NTP は EDNS0 のような方法では拡張しなかった。「パケットがまだ後に続くよー」というフラグ(と、シーケンス番号)によって、下のレイヤではなく NTP のプロトコル自体でパケット分割をおこなうようにした。IPv4 の最小 MTU は576バイトなので、それを通過できるようにこれより小さい単位で NTP サーバ自身がパケットを分割する。手元のソースでは 

/*
 * A response packet.  The length here is variable, this is a
 * maximally sized one.  Note that this implementation doesn't
 * authenticate responses.
 */
#define RESP_HEADER_SIZE        (8)
#define RESP_DATA_SIZE          (500)
てな感じ。上のパケットキャプチャの例では応答1400バイトなので、MTU 1500 の環境では通常は1パケットで返せるサイズなんだけど、NTP はそういうプロトコルではないので MTU とか無関係に4分割してしまう。

_ ちうことで、NTP は1パケットあたりのサイズが小さくなる分、amp に使われると同じトラフィックでも処理すべきパケットの数が DNS amp の何倍にもなっちゃうんですよ。場合によっては、帯域にまだ余裕があっても、ルータやスイッチがパケットをさばききれなくなる可能性がある。NTP amp はトラフィック増幅もヤバいけど、それに輪をかけてパケット数の増幅もヤバいということで。

2014年2月19日(水)

■ yahoo.com の SSL

_ 米 yahoo.comです。日本の yahoo.co.jp の話じゃないです。念のため。

_ なんかね、v6 でアクセスしたときの SSL の証明書がね、妙なのね。ちゃんと正しく検証できてはいるんだけど、でもなんでわざわざそんな証明書を使うのさ？という妙なものを使ってる。

_ 具体的にはこんな感じ。 

        Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert High Assurance CA-3
        Validity
            Not Before: Feb 11 00:00:00 2014 GMT
            Not After : Feb 28 12:00:00 2014 GMT
        Subject: C=US, ST=CA, L=Sunnyvale, O=Yahoo! Inc., CN=*.news.yahoo.com

_ 有効期間が 2/11 から 2/28 までのたった半月ちょいしかない。ちゃんと正規の認証局から発行されてるのは確かみたいなんだけど、digicert ってそんな短期間の証明書を発行してるの？ そんなメニューなさげっぽいんだけど、わざわざ特注して作ってもらってる？ 頻繁に証明書を入れ替える必要があってえらいめんどくさそう。それから、www.yahoo.com にアクセスしてるのに、common name が *.news.yahoo.com になってる。いちおう SubjectAltName に DNS:*.yahoo.com が含まれている(その他 flickr.com なども)のでちゃんと対応しているブラウザなら問題ないけど、対応してない環境も Windows XP とか Android 2.x とか今さらそんなもん使うなってものばかりとはいえ根強く残ってはいるよねぇ。まあ、そういう環境で v6 でアクセスすることなんかまずないか。

_ ちなみに、今月はじめにアクセスしたときは有効期間が 1/28 - 2/14 だったので、賞味期限の短い証明書をちゃんと半月ごとに入れ替えるめんどくさい運用をちゃんとこなしていることは間違いなさそう。ただし、そのときの CN は *.mail.yahoo.com で、今のものと違っていた(SubjectAltName にちゃんと対応していれば問題ないのは同じ)。このへんどういうポリシーで運用してるのかよくわからん。

_ 有効期間が短いのは、万が一秘密鍵が漏洩しちゃったりしたとしても、revoke する手間をかけることなく短期間に失効する、というのがメリットかなーと考えてみたりもしたけど、v4 でアクセスすると v6 で使っているのとは別の有効期間5年(2010/4/1 - 2015/6/3)の証明書が見えるので、そういうわけでもなさそう。ちうか、v4 と v6 で異なる証明書を使ってる理由もよくわからん。もう何がなんだか。

<< = >>
やまや