Network

Internet Explorer で TLS 1.2 を使用してみる

ちゃっぴ (tyappi@wankuma.com) — Sun, 01 Aug 2010 11:50:00 GMT

Web browser の TLS cipher suites を比較してみる
 Windows の TLS chipher suites の順序を変更する方法

上記の続き。

Windows 7 以降の OS では TLS 1.2 が利用できるようになりました。

TLS v1.2 の概要

Internet Explorer の [インターネットオプション] の [詳細設定] - [セキュリティ] - [TLS 1.2 の使用] がその設定です。既定では無効になっています。

ただ、上記で [TLS 1.2 の使用] を有効化しても、それだけでは TLS 1.2 は利用されません。TLS 1.2 を利用するためには [システム暗号化: 暗号化、ハッシュ、署名のための FIPS 140 準拠暗号化アルゴリズムを使う] policy を有効化する必要があります。こちらも既定では無効です。

[グループポリシーエディター] で [Windows の設定] - [セキュリティの設定] - [ローカルポリシー] - [セキュリティオプション] で [システム暗号化: 暗号化、ハッシュ、署名のための FIPS 140 準拠暗号化アルゴリズムを使う] を有効化します。

有効化したら gpupdate.exe を利用し policy を即時適用します。

>gpupdate.exe /force
ポリシーを最新の情報に更新しています...

ユーザー ポリシーの更新が正常に完了しました。
コンピューター ポリシーの更新が正常に完了しました。

これで適用されました。IE の設定も含めて再起動は一切必要ありません。

以上の設定を施すと Client Hello で送信される Version が TLS 1.2 に cipher suites は下記のように変わります。

Internet Explorer 8 (TLS 1.2, TLS 1.1, TLS 1.0, SSL 3.0 有効）
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

FIPS 140 準拠 policy を有効化したことにより RC4 が使えなくなっていますね。この状況では SSL で接続できない Web site が出てくるかもしれないですね。また、FIPS 140 準拠 policy は SSL / TLS に限らず、Windows CNG (Crypto Next Generatin) API の動作に影響するため、適用にあたっては最新の注意が必要になるでしょう。

同じ API を利用している Chrome, Opera は TLS 1.2 を有効化する設定項目が見当たらないため、Version は常に TLS 1.0 を送信し、TLS 1.1 および TLS 1.2 で追加された cipher suites は利用できません。ただ、FIPS 140 準拠 policy の影響は受けるので RC4 が利用できなくなります。

Windows の TLS chipher suites の順序を変更する方法

ちゃっぴ (tyappi@wankuma.com) — Sat, 31 Jul 2010 17:56:00 GMT

Web browser の TLS cipher suites を比較してみるのつづき。

Internet Explorer で AES 256 bit を使いたいのに順番が低いため使えね～。とお怒りの方ももしかするといらっしゃるかも知れませんが、これは Windows Vista 以降であれば group policy で変更できます。

[ファイル名を指定して実行] で「gpedit.msc」と入力。

[コンピューターの構成] - [管理用テンプレート] - [SSL 構成設定] と node を展開し、[SSL 暗号の順位] を double click。

Policy を有効化し、"," comma で区切ったcipher suites list を入力する。途中 space を含めることができないので注意。

普通の group policy であれば、gpupdate.exe /force で反映がかかるのですが、試してみた感じでは Windows を再起動するまで設定が反映されませんでした。

なお、この group policy を変更すると Chrome, Safari の cipher suites も IE と全く同じになります。Chrome, Opera の TLS (SSL) は IE と同じ API 使っているのは間違いないですね。Firefox や Opera は影響を受けません。こちらは独自のものを利用している模様。

<参考>

Web browser の TLS cipher suites を比較してみる

ちゃっぴ (tyappi@wankuma.com) — Sat, 31 Jul 2010 17:49:00 GMT

TLS (SSL) は Client Hello で client が利用可能な cipher suites (公開鍵暗号、共通鍵暗号、hash algorithm) を提示し、Server Hello で実際に利用する cipher suite を決定します。

Client Hello で送信される cipher suites は Web browser によりまちまちです。各 Web browser の default 設定で送信される cipher suites の調査結果は下記です。Client OS は Windows 7 です。

Internet Explorer 8
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_RC4_128_MD5

Firefox 3.6.8
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_RC4_128_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_RC4_128_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_SEED_CBC_SHA
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA

Opera 10.60
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_DH_RSA_WITH_AES_256_CBC_SHA256
TLS_DH_DSS_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DH_RSA_WITH_AES_256_CBC_SHA
TLS_DH_DSS_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_DH_RSA_WITH_AES_128_CBC_SHA256
TLS_DH_DSS_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DH_RSA_WITH_AES_128_CBC_SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA

Chrome と Safari は Internet Explorer 8 と全く一緒です。

Internet Explorer は AES 128 bit を使いたがりますが、Firefox は AES 128 bit よりも RC4 128 bit を使いたがります。Firefox は CAMELLIA や SEED にも対応していますね。

Cipher suites は RFC で管理されているようなんですが、その documents が散らばっているので下記にまとめておきます。

Cipher suites 関連の RFC
RFC No.	Title
2246	The TLS Protocol Version 1.0.
4346	The Transport Layer Security (TLS) Protocol Version 1.1.
5246	The Transport Layer Security (TLS) Protocol Version 1.2.
2712	Addition of Kerberos Cipher Suites to Transport Layer Security (TLS).
3268	Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS).
4132	Addition of Camellia Cipher Suites to Transport Layer Security (TLS).
4162	Addition of SEED Cipher Suites to Transport Layer Security (TLS).
4279	Pre-Shared Key Ciphersuites for Transport Layer Security (TLS).
4492	Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS).
4785	Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS).
5288	AES Galois Counter Mode (GCM) Cipher Suites for TLS.
5289	TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM).
5469	DES and IDEA Cipher Suites for Transport Layer Security (TLS).
5487	Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode.
5489	ECDHE_PSK Cipher Suites for Transport Layer Security (TLS).
5932	Camellia Cipher Suites for TLS.

Firewall profile

ちゃっぴ (tyappi@wankuma.com) — Sun, 25 Jul 2010 23:24:00 GMT

Windows Vista 以降の Windows Firewall では firewall を profile 毎に個別管理できるようになりました。

セキュリティが強化された Windows ファイアウォールファーストステップガイド

新しい network に接続したときに下記のような dialog が出てくるのでおなじみですよね。

自宅、もしくは企業内であれば必ず「パブリックネットワーク」を選択してください。また、「パブリックネットワーク」の firewall は絶対に緩めないでください。

実は昨日の勉強会で無線 LAN に接続している端末の firewall の状態を確認するため、ICMP と SMB で接続を試してみました。無線 LAN に接続されている host が 39 台あり、内 9 台は ICMP が通り、8 台は SMB で接続が可能でした。

まあ、勉強会の無線 LAN で攻撃される可能性はほぼ無いと思うので問題は無いと思いますが、気になるのは別の network に接続したときの firewall 設定です。

最近は EMOBILE や UQ WiMAX または公衆無線 LAN とかいろいろ利用している人が多いでしょう。このような network に接続している場合、直接 global IP address が割り当てられる) 場合が多いです。

>ipconfig.exe /all 
PPP アダプター EMOBILE:
 
   接続固有の DNS サフィックス . . . :
   説明. . . . . . . . . . . . . . . : EMOBILE
   物理アドレス. . . . . . . . . . . :
   DHCP 有効 . . . . . . . . . . . . : いいえ
   自動構成有効. . . . . . . . . . . : はい
   IPv4 アドレス . . . . . . . . . . : 114.48.188.112(優先)
   サブネット マスク . . . . . . . . : 255.255.255.255
   デフォルト ゲートウェイ . . . . . : 0.0.0.0
   DNS サーバー. . . . . . . . . . . : 60.254.193.158
                                       117.55.64.152
   プライマリ WINS サーバー. . . . . : 10.11.12.13
   セカンダリ WINS サーバー. . . . . : 10.11.12.14
   NetBIOS over TCP/IP . . . . . . . : 無効

>ipconfig.exe /all
イーサネット アダプター WIMAX0:

  接続固有の DNS サフィックス . . . : uqc.ne.jp
  説明. . . . . . . . . . . . . . . : Intel(R) Centrino(R) WiMAX 6250
  物理アドレス. . . . . . . . . . . : **-**-**-**-**-**
  DHCP 有効 . . . . . . . . . . . . : はい
  自動構成有効. . . . . . . . . . . : はい
  IPv4 アドレス . . . . . . . . . . : 119.107.210.237(優先)
  サブネット マスク . . . . . . . . : 255.255.255.255
  リース取得. . . . . . . . . . . . : 2010年7月25日 22:46:06
  リースの有効期限. . . . . . . . . : 2010年7月26日 22:46:06
  デフォルト ゲートウェイ . . . . . : 119.107.200.135
  DHCP サーバー . . . . . . . . . . : 119.107.200.135
  DNS サーバー. . . . . . . . . . . : 119.107.200.151
                                      119.107.200.23
  NetBIOS over TCP/IP . . . . . . . : 有効

Subnet mask は 255.255.255.255 になっていますが、global IP が割り当てられていて途中で filtering されていないため、listen しているすべての port が攻撃にさらされていますね。

以前 EMOBILE の network で脆弱性を突く network packet を検知できるような firewall を入れてしばらく monitor してみましたが、ほんとアホのように攻撃がきていました。脆弱性が存在したら間違いなくいちころです。めちゃくちゃ危険ですよ！

とはいえ、自宅や企業内で利用する場合には firewall に許可構成を入れないと問題がある場合も多いでしょう。ですから mobile PC では profiling機能を持つ firewall を導入することは必須です。

すでに書きましたが Windows Vista 以降の OS では標準で profile 機能を持つ firewall を持っています。Windows XP 以前にはありません。Third pary 製の fireawall に関してはここ数年調査していませんが、こちらも profiling 機能を持っていないのであれば、mobile PC でそれのみに頼るのは大問題ですね。

思い当たる方はぜひこの機会に firewall の構成を確認してください。非常に危険ですよ！

EMOBILE への接続を高速化する方法

ちゃっぴ (tyappi@wankuma.com) — Sun, 25 Jul 2010 19:20:00 GMT

最近は UQ WiMAX を試用していますが、以前から EMOBILE を外出先の main 回線を利用しています。EMOBILE への接続は通常は EMOBILE から提供されている utility を利用している人が多いと思いますが、私は利用していません。というのは、別の接続 utility を使っていたり、OS 標準の機能の方が使いやすいからです。

ただ、EMOBILE から提供されている utility を利用しない場合、大きな問題があります。接続設定によって接続完了までの時間が大幅に変わってくるという問題です。

Windows Vista 以降の OS では既定で IPv6 が有効化されています。IPv6 が有効な状態では下記 dialog で数十秒から～ 1 分程度余計な時間がかかります。

これを解消するには IPv6 を無効化すればよいです。なお、以降の設定手順および画面はすべて Windows 7 です。

必要無いので上記画面では IPv6 だけではなく「Microsoft ネットワーク用クライアント」も無効化しています。

IPv6 を無効化する弊害としては当然ですが、IPv6 が利用できなくなります。EMOBILE からの公式情報はありませんが、EMOBILE は IPv6 の IP address は取得できないものの、Tunnel adapter 6TO4 adapter を通じて IPv6 を扱えます。

>ipconfig.exe /all
PPP アダプター EMOBILE:

   接続固有の DNS サフィックス . . . :
   説明. . . . . . . . . . . . . . . : EMOBILE
   物理アドレス. . . . . . . . . . . :
   DHCP 有効 . . . . . . . . . . . . : いいえ
   自動構成有効. . . . . . . . . . . : はい
   IPv4 アドレス . . . . . . . . . . : 114.48.188.112(優先)
   サブネット マスク . . . . . . . . : 255.255.255.255
   デフォルト ゲートウェイ . . . . . : 0.0.0.0
   DNS サーバー. . . . . . . . . . . : 60.254.193.158
                                       117.55.64.152
   プライマリ WINS サーバー. . . . . : 10.11.12.13
   セカンダリ WINS サーバー. . . . . : 10.11.12.14
   NetBIOS over TCP/IP . . . . . . . : 無効

Tunnel adapter 6TO4 Adapter:

   接続固有の DNS サフィックス . . . :
   説明. . . . . . . . . . . . . . . : Microsoft 6to4 Adapter
   物理アドレス. . . . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP 有効 . . . . . . . . . . . . : いいえ
   自動構成有効. . . . . . . . . . . : はい
   IPv6 アドレス . . . . . . . . . . . : 2002:7230:bc70::7230:bc70(優先)
   デフォルト ゲートウェイ . . . . . : 2002:c058:6301::c058:6301
   DNS サーバー. . . . . . . . . . . : 60.254.193.158
                                       117.55.64.152
   NetBIOS over TCP/IP . . . . . . . : 無効

IPv6 が有効化された状況では http://www.kddi.com へ IPv6 address を直指定 (http://[2001:268:fd02::1]/) してみましたが、問題なく接続できます。Network inteface から IPv6 を無効化すると接続できないことを確認しました。

参考イーモバイル(emobile)はIPv6対応しているデュアルスタック構成のようだ。

ただ、IPv6 の利用がまだ一般的で無いことと、EMOBILE から直接 IPv6 address を払い出させるわけではないので、IPv6 を無効化しても問題ないでしょう。接続完了までに数十秒を超える時間がかかることの方が問題だと思いますので。

接続完了までの時間への影響は IPv6 が有効であるかが最も大きいですが、その他にもいろいろ接続設定項目ありますので最適と思われる設定を示します。

[オプション] tab で下記の check をはずす。

名前、パスワード、証明書の入力を求める
Windows ログオンドメインを含める
電話番号の入力を求める

[セキュリティ] tab で下記 check をはずす。

暗号化されていないパスワード (PAP)
Microsoft CHAP Virsion 2 (MS-CHAP v2)

これで接続完了が遅いことに対するいらいらが解消できるでしょう。

なお、最近利用している UQ WiMAX は IPv6 を全く support していないようです。

UQ WiMAX Certificationプログラム - Q IPv6には対応していますか？

EMOBILE での場合と同様に http://[2001:268:fd02::1]/ への接続を試行してみましたが、こちらは接続できませんでした。

UQ WiMAX の場合、IPv6 が有効になっていても EMOBILE のように接続完了までの時間が大幅に伸びることはありませんが、無駄な処理を行うことになるので EMOBILE 同様 IPv6 を無効化しておくことをお勧めします。

UQ WiMAX の速度

ちゃっぴ (tyappi@wankuma.com) — Sun, 25 Jul 2010 17:24:00 GMT

「UQ WiMAX を試してみる」で UQ WiMAX に接続できるようになったので、どのくらい速度が出るか試してみました。とりあえず、自宅で試したんですが、そのときの信号強度は 48 ~ 52 % でした。

下りは 3 ～ 5 Mbps で上りは 1 ～ 2.5 kbps でした。UQ WiMAX の回線速度公称値は下り最大 40 Mbps、上り最大 10 Mbps なのでものすごく低い値ですね。(*)WiMAX は信号強度が下がると大幅に速度が低下するという話もあるので、後日信号強度が高い地点で再検証してみます。

以前から EMOBILE から利用しているのですが、自宅での速度は下記です。

速度測定結果 4 (EMOBILE)

利用している modem は D21HW なのでこちらの公称値は下り 7.2 Mbps、上り 1.4 Mbps です。下りは大幅に減退しているものの上りの速度は優秀ですね。

ということで、USTREAM 等で live 配信をする場合、信号強度が低いのであれば上りが安定している EMOBILE を利用したほうがよさそうですね。Web browsing を行ったりするのであれば、UQ WiMAX を利用したほうがよさそうです。

そんな感じでいろいろ試してみる予定です。

[追記]

私が利用している WiMAX adapter インテル® Centrino® Advanced-N + WiMAX 6250 での公称値は下り最大 20 Mbps 上り最大 6 Mbps です。UQ WiMAX の公称値よりも低いです。

UQ WiMAX を試してみる

ちゃっぴ (tyappi@wankuma.com) — Sun, 25 Jul 2010 16:40:00 GMT

先日 Thinkpad X201s (5129-CTO) を購入しました。

Wireless network adaptor に「インテルR CentrinoR Advanced-N + WiMAX 6250」を選択したので、とりあえず使ってみようということで、自宅で UQ WiMAX を利用してみました。

15 日は無償で利用できるということなんですが、WiMAX adaptor を rental するのではなく、持っている WiMaX adaptor を利用して試す方法がわかりにくい。

15日間WiMAXお試し利用 Try WiMAX for PC

上記に書いてある通りなんですが、申し込むにはまずは UQ WiMAX に接続する必要があります。

私の端末は HDD を入れ替えて OS も入れ替えているので WiMAX の接続 utility なんてものはありません。なので、手動で WiMAX に接続することが必要です。Thinkpad には Access Connections という network connections manager が存在するのでそれを利用して UQ WiMAX に接続しました。

Access Connections を利用する場合、場所によっては UQ WiMAX が検知できないため、検知できない場合には [ワイドスキャン] を実施してください。UQ WiMAX が見つかればそれを click すれば接続できます。

その後、Web browser を立ち上げると UQ WiMAX の Web page が表示されるので、そこで [Try WiMAX for PC はこちら (15日間WiMAXお試し利用)] を click して登録してください。

これで、UQ WiMAX を 15 日間利用できるようになりました。

接続状況とかいろいろ試してみようと思っているので、おいおい blog に書いていくつもりです。

dynaTrace AJAX Edition

ちゃっぴ (tyappi@wankuma.com) — Sun, 13 Jun 2010 12:57:00 GMT

Internet Explorer で HTTPS の network trace を採る tool を探していたら見つけた。

dynaTrace AJAX Edition

こんな感じで HTTPS の network trace ばっちり取れています。

他にも timeline とったりといろいろ機能は豊富なようなのでおいおい使いこなしていこうかと。

ところで、dynaTrace AJAX Edition は Java で動作しているようで、install した時に installed directory に JRE が一緒に install されます。現在の最新 version 1.6.0.322 では最新ではない JRE 6 Upadate 19 が install されます。JRE 6 Upadate 19 には JRE 6 Upadate 20 で修正された脆弱性が含まれているため、install が終わったら JRE を必ず最新のものに置き換えておきましょう。

こうゆうものを検知してくれる Secunia PSI マジで便利だわ。

Windows での network trace あれこれ

ちゃっぴ (tyappi@wankuma.com) — Sat, 08 May 2010 13:45:00 GMT

最近だと application で network を使わないことの方が少数でしょう。で、network を利用する application を開発する場合、application に問題がある場合もあれば、環境に問題がある場合もあり原因追究に難航する場合が多くあります。

まあ、そんな時原始的な方法ですけど network trace を取得するのが最も近道であることが多いです。

この手の分析を行う application で有名なのは Wireshark (Ethereal の開発者が開発) ですね。私も昔 Ethereal を使っていましたし、今でも Wireshark はしばしば利用します。UNIX 系では tcpdump で取得した結果を Wireshark に噛まして分析なんてのもよくやりますね。あ、ちなみに Wireshark は脆弱性が修正された 1.2.8 が最近 release されていますので、利用している方は忘れずに update を。

Microsoft 製のものはないのか？というと、もちろんあります。

Microsoft Network Monitor 3.3

以前は Windows Server の component として存在していましたが、現在は OS とは別の application として配布されています。こちらの利用方法については、最近 Ask the Network & AD Support Team で取り上げられています。

Network Monitor 3 を使用したパケットの採取

でも、OS とは別なので本番環境に導入するには敷居が。。。という場合も多いでしょう。Windows 7, Windows Server 2008 R2 を利用している場合には netsh command に trace context が搭載されました。Windows 7, Windows Server 2008 R2 を利用していれば何も導入せず network trace を取れるのは非常に魅力ですね。使い方に関しては下記に解説があります。

The Cable Guy: Windows 7 のネットワーク診断とトレース

それ以前の OS を利用している場合。。。Network switch に mirror port 仕掛けて作業用端末に飛ばし、そこで capture とか。あとは software 導入を説得するとか。

.NET Framework で System.Net namespace を使って開発している場合、実は標準で log 出力機能が備わっています。

方法 : ネットワークトレースを構成する

Configuration file に設定を記述するだけで、network trace を取得することができます。TraceSource を利用しているため、出力先はお好きな TraceListener を利用して選べばいいし。

トレースリスナー

System.Net namespace と書きましたが、.NET Framework で network を利用する classes の多くは内部で System.Net namespace 配下の classes を利用していることが多いので適用範囲はかなり広いです。

これ、結構使えるので憶えておくとよいかと。

E-mail address (RFC 5321) の正規表現

ちゃっぴ (tyappi@wankuma.com) — Wed, 22 Apr 2009 22:42:00 GMT

これは何でょう？の回答。

一発目で答えが出てしまいましたが、答えは E-mail address ですね。E-mail address の形式は RFC 5321 で定義されています。

RFC 5321 Simple Mail Transfer Protocol 4.1.2. Command Argument Syntax より

   Domain         = sub-domain *("." sub-domain)

   sub-domain     = Let-dig [Ldh-str]

   Let-dig        = ALPHA / DIGIT

   Ldh-str        = *( ALPHA / DIGIT / "-" ) Let-dig

   address-literal  = "[" ( IPv4-address-literal /
                    IPv6-address-literal /
                    General-address-literal ) "]"
                    ; See Section 4.1.3

   Mailbox        = Local-part "@" ( Domain / address-literal )

   Local-part     = Dot-string / Quoted-string
                  ; MAY be case-sensitive


   Dot-string     = Atom *("."  Atom)

   Atom           = 1*atext

   Quoted-string  = DQUOTE *QcontentSMTP DQUOTE

   QcontentSMTP   = qtextSMTP / quoted-pairSMTP

   quoted-pairSMTP  = %d92 %d32-126
                    ; i.e., backslash followed by any ASCII
                    ; graphic (including itself) or SPace

   qtextSMTP      = %d32-33 / %d35-91 / %d93-126
                  ; i.e., within a quoted string, any
                  ; ASCII graphic or space is permitted
                  ; without blackslash-quoting except
                  ; double-quote and the backslash itself.

RFC 5322 Internet Message Format 3.2.3. Atom より

   atext           =   ALPHA / DIGIT /    ; Printable US-ASCII
                       "!" / "#" /        ;  characters not including
                       "$" / "%" /        ;  specials.  Used for atoms.
                       "&" / "'" /
                       "*" / "+" /
                       "-" / "/" /
                       "=" / "?" /
                       "^" / "_" /
                       "`" / "{" /
                       "|" / "}" /
                       "~"

   atom            =   [CFWS] 1*atext [CFWS]

RFC の定義自体が正規表現を意識して書かれているような気がするので、正規表現にしてしまえ！
ということで、下記を記述。

// Local-part
var atom = "[A-Za-z0-9!#\\$%&'\\*\\+\\-/=\\?\\^_`\\{\\|}~]+";
var dotString = atom + "(?:\\." + atom + ")*";
var qtextSMTP = "[\\x20-\\x21\\x23-\\x5B\\x5D-\\x7E]";
var quotedPairSMTP = "\\\\[\\ox20-\\x7E]";
var quotedString = "\\\"(?:" + qtextSMTP + "|" + quotedPairSMTP + ")+\\\"";
var localPart = "(" + dotString + "|" + quotedString + ")";

// Domain
var letDig = "[A-Za-z0-9]";
var ldhStr = "[A-Za-z0-9\\-]*" + letDig + "+";
var subdomain = letDig + "(?:" + ldhStr + ")*";
var domain = "(" + subdomain + "(?:\\." + subdomain + ")*)";
      
var mailbox = localPart + "@" + domain;

で、出来上がったのが下記になります。

^([A-Za-z0-9!#\$%&'\*\+\-/=\?\^_`\{\|}~]+(?:\.[A-Za-z0-9!#\$%&'\*\+\-/=\?\^_`\{\|}~]+)*|\"(?:[\x20-\x21\x23-\x5B\x5D-\x7E]|\\[\ox20-\x7E])+\")@([A-Za-z0-9](?:[A-Za-z0-9\-]*[A-Za-z0-9]+)*(?:\.[A-Za-z0-9](?:[A-Za-z0-9\-]*[A-Za-z0-9]+)*)*)$

めんどくさいので address-literal には対応していませんが、RFC 5321 に準拠していない E-mail address を弾くのに使えるでしょう。

Bug があったらおせ～てください。