自堕落な技術者の日記

SSL Pulseサイト(https://www.trustworthyinternet.org/ssl-pulse/)は、 ssllabsでも有名なQualys社が運営しているサイトで、 Webサイト調査のAlexa社による 世界のアクセストップ20万サイトを対象にSSL関係の統計情報を毎月公開しています。 3月に引き続き5月のSSL PulseでのSSL/TLSの状況推移をグラフ化してみましょう。 隔月で見ていけたらと思っています（＾＾；

脆弱性対応の推移

SSL/TLSプロトコルの推移

POODLEの影響でSSLv3の無効化が順調に下がっており、サポートするサイトは40%までに減りました。

SSLサーバー証明書の鍵長、署名アルゴリズムの推移

Google ChromeやWindows製品のSHA1証明書のアラート対応を受けて、SHA1とSHA2証明書の比率が逆転しました。今月のグラフで最も特徴的な事かと思います。

新しい技術のサポートの推移

OCSP stapling対応率は順調に伸びていますが。大したことはありません。

鍵交換の最低鍵長

鍵交換の情報が3月から取れるようになり、ようやく傾向がつかめるようになってきています。

DH鍵交換の最低鍵長

DH鍵交換に対応するサイトはわずかながら増えていますが、2048bitだけでなく、安全でないとされる1024bitも増えていること、またそれ以上に安全でない512bitが使われていることは非常に問題です。このような傾向からも、DH鍵交換の鍵長を増やすよう設定するよりも、DH鍵交換は使わず、ECDH系の鍵交換を使うのが良いように思います。

先日ブログに書いたTLSの実装と導入上の推奨をまとめたRFC 7525の4.4節にもDH鍵交換の課題が整理されており、RFC 7525では「使うな」とは言っていませんが、これを読むとDH系の鍵交換は使うべきではないように思います。

ECDH鍵交換の最低鍵長

ECDH系の鍵交換を使えるサイトと、使えないサイトの比率が逆転し、ECDH系の鍵交換への対応が半数を超えてきました。ECDH系鍵交換を使えない比率の減り方がDHに比べて顕著です。

おわりに

なんか今週末はブログラッシュっすね。メッセージ入りSSLサーバー証明書の件が書けなかったなぁ。今日はこの辺で。

関連記事

• SSL Pulseの統計情報で見るSSL/TLS (2015年5月版) (2015.05.11)
• (小ネタ)来月にはSHA2証明書の枚数がSHA1を追い越しそうな件 (2015.04.11)
• SSL Pulseの統計情報で見るSSL/TLS (2015年3月版) (2015.03.17)
• SSL Pulseの統計情報で見るSSL/TLS (2015年1月版) (2015.01.25)
• Internet Week 2014パネルで話しそびれたネタ: 統計情報でみるSSL/TLS (2014.11.22)

先日のブログ「Windowsルート証明書の更新プログラム(2014.09)と戯言など」で、

オフラインでルート証明書をアップデートする公式アップデーター http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/rootsupd.exe からルート証明書が「抜ける」んじゃね？と某木村大先生からご指摘いただきました。

実際に試してみたので、ちょっと書いてみたいと思います。

ルート証明書アップデーターからSSTの取り出し

Windows 7以降のオフライン環境で、信頼するルート認証機関のリストをアップデートするのにアップデーター http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/rootsupd.exeがあるというので、早速ダウンロードしてみます。wgetでヘッダ見てみると最終更新は"Wed, 12 Nov 2014 17:33:07 GMT"になっているので、最新のアップデートには対応してそうかな？とも思ったんですが、後に最新のルート更新には対応してなかったことがわかりますorz

これはCAB形式自己解凍アーカイブみたいになっているので、exe2cab(Vectorのは64bitでは動作せず)を使って中身のcabファイルを取り出します。

cabファイルの中はこんな感じ。

ADVPACK.DLL
authroots.sst - ルートのスモールセット？
delroots.sst - 削除するルート
roots.sst - 最小限の2つのルート
rootsupd.inf -
updroots.exe - ルートを更新するプログラム
updroots.sst - 追加される多くのルート

cabファイルのタイムスタンプ見てみたら、2013年4月になっているので、どうも直近の2014年9月の更新に対応したアップデートファイルでは無さそうな雰囲気です。

SSTファイルからのルート証明書の取り出し

*.sstファイルはMicrosoft Serialized Certificate Filesというフォーマットらしく、前にも力技で証明書取り出すスクリプトを書いた記憶があるんですがorz、ちょっと調べてみたらPowerShellのExport-CertificateやImport-Certificateで操作できそうな雰囲気。サンプルにはSSTに証明書を追加する例なんかも紹介されていました。ところが、どうもSSTから証明書を取り出す方法がよくわからずに結局断念。

もうちょっと調べてみるとSSTの中の個々の証明書エントリはSerializedCertificateEntryという構造になっているらしく、SSTのヘッダ情報のあとはこの並びになっているので、Perlでちゃちゃっと抜き出すスクリプトを書きました。

id - 4byte 0x00000020
encodingType - 4byte 0x00000001 (= ASN.1 encoding)
length - 4byte 続く証明書データの長さ
certificate - 可変長 証明書生データ

取り出せた証明書の数はこんな感じ、2014年9月のルートの更新では411だそうですから、かなり少なめ。古い情報っぽくてちょっと萎え気味。

SSTファイル	ルート証明書数
authroots.sst	77
roots.sst	6
updroots.sst	275
計	358

で、ぽちぽちルート証明書を開いてみる

とまぁ、ルート証明書の取り出しはできたので、これをそれぞれ開いてみると 「インターネットオプション＞コンテンツ＞証明書＞信頼されたルート認証機関」に 未表示のものだったら、表示されるようになります。

Windows 8.1 Proの最新パッチ済の環境で、358のうち、有効期限切れになっているものや、すでにMicrosoftが登録削除しているものもあるようで、最終的には271個のルート認証機関がちゃんと表示されるようになりました。これの作業前は確か27だったので、大躍進という感じではあります。

(TURKTRUSTが表示されていることに他意はありません（＾＾；

おわりに

いや〜〜、隠し球っぽくて気持ち悪かったのが、表示されて随分すっきりしますね〜〜。ただ、

やっと271は表示されたが411まではまだ遠い

私はビックリマンチョコ世代ではないですが、仮面ライダースナックとか集めましたね〜〜。ソシャゲーのコンプガチャみたいんなもんなんですかね〜〜。最後までちゃんと表示させたくなりますよね〜〜〜。 411まではまだ道のりは遠い感じですねぇ。やっぱり、Certificate Transparencyのデータに手をつけないといかんかなぁ、、、と思っているところです。

今日は、この辺で、、、

関連記事

• Windows信頼するルート認証機関コンプへの道(第一回) (2015.05.10)
• Windowsルート証明書の更新プログラム(2014.09)と戯言など (2015.05.03)
• Windowsルート証明書の更新プログラム(2010.08)
• Windowsルート証明書の更新プログラム(2010.05)
• Windowsルート証明書の更新プログラム(2009.11)
• Windowsルート証明書の更新プログラム(2009.09)の続き
• Windowsルート証明書の更新プログラム(2009.09)
• Windowsルート証明書の更新プログラム(2009.02)
• Windows95の信頼するルート認証機関(2008.11.28)

随分昔の話になりますが、 2014年9月に現時点で最新のWindowsルート証明書プログラムのリストが公開されており、今日は久々にこれを見ていこうと思います。

数年前、Windowsルート証明書の更新プログラムで登録されているルート認証機関にどんな変更があったのか、調査をしてブログで公開していた時期がありました。その時はWindows XPの時代で、登録されているルート認証機関はすべて表示されるようになっていたので、ルート証明書を全部取り出すプログラムを書いて、前回との差分を比較していただけだったので、比較的簡単に調査ができたわけです。

ところが、Windows 7以降、Windowsのルート証明書は、最初からすべて登録されるわけではなくなってしまいました。ちゃんと調べたわけではないので、わからないのですが、確かOSインストール直後は15〜25ぐらいの主要なルート認証機関しか登録、ならびに表示されておらず、表示されていないルート認証局のサイトにアクセスした場合に、動的に登録されたルート証明書が追加されるような仕組みに変更になりました。

Windows 7以降のルート認証局リストの仕組みの問題点

Windows 7より導入されたルート認証局リストの配布方式は、個人的に「スッキリしない」というか「嫌だなぁ」と思っています。理由はこんなところです。

• ルート認証局のリストはPDFの文書として公開されているが、維持組織、国、認証局名、鍵アルゴリズム、鍵長、ルート証明書ハッシュ値(拇印)しか公開されておらず、識別名や証明書の内容はわからないままである。中には、初期状態で表示されない RSA 1000bitのルート証明書が残っていたりする。
• 初期状態では20程度の認証局しか表示されておらず、利用者がどの認証局を信頼していることになっているのか、これを知る方法が上のリストのみで十分でない。
• 例えば、ある小国の認証局を全世界の人が信頼する必要があるとは思えない。不正発行などの事故を起こした場合に、信頼していないほうが良かったという事もあるだろう。そのような時に、自分が信頼している認証局がどこであるのかを把握できないのは問題だ。
• Windows 7以降のシステムが認めたルート認証局は削除したとしても、再度アクセスする際に復活してしまう。ユーザは余計な認証局を利用停止や無効化することができない。
• つまる所、最初からルート認証局リストが明示されず、後出しジャンケンのようにルート認証局が接続時に追加されるのは如何なものだろうか。

もちろんモバイル向けに初期配布のルート認証局は小さくしたいというのも、わかる気はしますが、どうせ400程度ですから、大したデータ量でもないので、最初から登録してあったほうが潔いと思います。

2014年9月版 Windowsルート証明書の更新

2014年9月のWindowsルート証明書の更新では、411のルート証明書が登録されています。

国別で見てみると、52ヶ国のルート証明書が登録されており、内訳は多い順に以下のようになっています。やっぱり、米国、スペインは多いですね。意外に少ないなぁと思うのが英国、オーストラリアです。

次にルート証明書の公開鍵アルゴリズムと鍵長についても見てみましょう。

RSA 2048bitがやはり多いですが、 RSA 4096bit、楕円曲線暗号のECC NIST P-384曲線もかなり増えています。 Comodo、 DigiCert、 Entrust、 GlobalSign、 Symantec、 Trend Microが楕円のルート証明書を持っています。そういえば、 Microsoftから発行されているリストには SHA1かSHA2かの情報って無いんですよね。残念だなぁ。やっぱり、ルート証明書そのものをダウンロードできるようにしてほしいなぁ。 Appleも、最初はルート証明書の詳しい情報を出していたんですが、最近はMicrosoftに習って、詳しい情報出すの止めちゃったんですよね〜〜。寂しい話です。

ルート証明書数の推移

Windows系、Android、Mac OS X、iOSでデフォルトのルート証明書の数がどう増えていったのかグラフにしてみました。Apple製品は公式サイトの情報から取得しています。Androidについては拙作のRoot CA Viewer Liteか過去の他作業を元に調べています。

iOSはiOS3以降、メジャーバージョン毎にルート証明書リストが公開されているのですが、Mac OS Xについては新しいMavericksとYosemiteしか情報がありませんでした。 Apple iOSについては、ルートの数が乱高下していて、なんか掲載ポリシーが定まってない感じなんですかね？ 本当はMozillaやJavaについても調べてみたかったんですが、これは今後の課題ということで、、、(^^;

Windowsルート証明書のリストを調べる地道な作業 (泣)

以前は、自前のツールを使えば簡単にルート証明書を抽出できたので、今回のような情報を比較的簡単に調査することができたんですが、 Windows 7以降、そうした事もできなくなってしまいました。で、今回はというと、こんな地味な手順を踏んで調査したんです(泣)。Microsoftの中の人ならリストのエクセルファイルとか、ルート証明書そのものを持っていて簡単に調査できるんでしょうけどねぇ、、、トホホ。

1. 公開されているPDFファイル「 Windows Root Certificate Program Members - September 2014」からCERTIFICATES IN DISTRIBUTION FROM ALL MEMBER CAsの表を各ページ、テキストでコピペする。
2. Emacsのテキスト編集で何とか、TSV(タブ区切り)ファイルにする。
3. Macのテキストエディタで開きUTF-16で保存する。
4. MacのExcelでインポートする。
5. インポートした時点で、カラム位置のズレや文字化けがあるので手作業で修正。
6. ルート証明書リストのExcelが完成！！！ (泣)
7. ちゃんとしたエクセル表なので、フィルタ使って調べたり、簡単なスクリプト書いて集計 したりできる。

さらなる野望

家族から「リビングにファンが煩いマシンを置くな！」と非難され、泣く泣くファンレスの超小型マシンDiginnos LIVAをサーバー代わりに使っているんですが、ブラウザで変なサイトに行くこともあまりないので、ルート認証局のリストは27で、初期出荷時からあまり増えていないはずで、今回、試しに開いて、イタリアのActalis Authentication CA G1が増えてしまいました。

なんかこう、 あれです、411もあるわけですから、フルコンプしたいですよねぇ？ 先生、大事なことだからもう一回言います。

フルコンプしたいですよねぇ？！！！

これをフルコンプするには、 411の全ての認証局それぞれに、そこから発行されたどれか一つのSSLサーバー証明書を使っているサイト見つけて、Internet ExplorerでHTTPSアクセスすればいいだけですが、マイナーな認証局から発行された証明書を使っているサイトを見つけるなんて、海水浴行った海岸のどこかで落とした10円玉見つけるようなもんで、ほとんど無理ですよね。 例えば、Symantecなんかは色んな認証局を買ったので、グループだけで70もの認証局が登録されているわけですが、Symantecにそれぞれの認証局から発行された証明書のすべてを見つけるなんて、もう無理です。

こういう時ですねぇ、Certificate Transparencyの公開監査ログを手元に持っているとですねぇ、740万枚ぐらいのサーバー証明書と、そのルート認証局までのチェーンがあるので、それぞれのルート証明書を取り出して、Windowsルート証明書情報のPDFに記載された証明書の拇印ハッシュ値とを比較すれば、そこから発行されたSSLサーバー証明書が一つみつかるので、そこへアクセスすれば前述の「証明書ダイアログ」に表示されるのではないかと！！！(パチパチ)

ゴールデンウィーク中に、ちょっとGo言語でこんなツールを作ろうかなぁ、、、と思ってます。

おわりに

いや〜、オレのゴールデンウィークは有意義だなぁ、、、 (遠い目 ) こんなことばかりしているとカミさんに怒られるので、今日はこのへんで。

追記(2015.05.03 13:28)

オフラインでルート証明書をアップデートする公式アップデーター http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/rootsupd.exe からルート証明書が「抜ける」んじゃね？と某木村大先生からご指摘いただきました。確かにそのとおりでした。(つ〜か、前にツール使ってそれができてたものが、参照情報しか取れなくなったと勘違いしてできなくなって、そのままにしてたんですが 、指摘を頂いてから見てみたらちゃんとありました。) その実行ファイルには、証明書のリストである .SST (Microsoft Serialized Certificate Files)が入っており、その中からルート証明書が取り出せそうです。前は作ったツール使ってたんですが、今は PowerShell から取り出せそう。試したらまた報告します。ルート証明書が抜けたとして、ただ開いただけで、「信頼するルート認証機関」のリストに表示されるんかいな？？？

関連記事

• Windows信頼するルート認証機関コンプへの道(第一回) (2015.05.10)
• Windowsルート証明書の更新プログラム(2014.09)と戯言など (2015.05.03)
• Windowsルート証明書の更新プログラム(2010.08)
• Windowsルート証明書の更新プログラム(2010.05)
• Windowsルート証明書の更新プログラム(2009.11)
• Windowsルート証明書の更新プログラム(2009.09)の続き
• Windowsルート証明書の更新プログラム(2009.09)
• Windowsルート証明書の更新プログラム(2009.02)
• Windows95の信頼するルート認証機関(2008.11.28)

ちょっと遠い関連記事

• Android 4.3.1 と 4.4 KitKatのルート証明書リストの違いを見てみたぞ(2013年11月10日)
• Android 4.0.4 と 4.3.1 のルート証明書リストの違いを見てみたぞ(2013年11月6日)
• Xperiaに搭載されたルート認証局証明書 (2010年4月26日)
• Android 4.0 以降のルート証明書ストアを調べるツールを作ってみたいぞ (2012年09月30日)
• (小ネタ)Android 4.0 ICSのルート証明書ストア (2012年09月04日)
• (小ネタ)Root CA Viewer Lite for Android(Free)の公開 (2014年10月24日)

SSL/TLS CipherSuiteウォッチャーの@kjurです。

2013年11月13日にマイクロソフトから度肝が抜かれるほどびっくりした Windows 7 SP1以降の「重要」更新プログラムが出てもうアップデートした人も いるんじゃないかと。既にSurface Pro 2などのWindows 8.1にはこの 更新が適用されているというので二度見しちゃいましたよ。

マイクロソフトセキュリティアドバイザリ(2868725) RC4を無効化する更新プログラム
http://support.microsoft.com/kb/2868725/ja
http://technet.microsoft.com/ja-jp/security/advisory/2868725

BEAST対策でRC4マンセーみたいな感じだったのに、RC4使えなくしちゃうんですよ。いきなりですごくないですか? 証明書とかSHA1を止める準備も着々と進んでいてマジでマイクロソフトやるなぁと度肝を抜かれました。

となりの人がこのパッチを適用されたWindows 8.1のSurface Pro 2を持っているのでちょっとマシンをお借りしてCipherSuite比較してみました。(Special Thanks To 隣の平井堅に似た人)

ちなみにこっちはWindows 7 SP1でRC4無効化パッチ(KB2868725)未適用のIE8.0のCiphrSuite。

Client Hello Version: TLS 1.0
TLS Version: TLS 1.0
Num Cipher Suites: 12
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)

そんでこれがWindows 8.1 Pro、IE 11.0.9600.16384のCipherSuite。

Client Hello Version: TLS 1.2
TLS Version: TLS 1.2
Num Cipher Suites: 19
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x006a)
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)

特徴的なのはこんなとこ。

• 本当にRC4はなくなってしまった。
• ClientHelloではClientHelloのバージョンもTLSバージョンもTLSv1.2になっており、接続に失敗してもTLSのバージョンをダウングレードしたりはしないんですが、頂いた報告や私も確認してみた所、クライアントがTLSv1.2のみを要求して、サーバーがTLSv1.0と返してきてもハンドシェイクできてしまうみたいです。iOSとか他の実装はClientHelloをダウングレードしてやり直すものが多いですが。本来ならばClientHello TLSv1.0、TLS versionがTLSv1.2とするのが正しいClientHello要求だと思います。
• 対応するCipherSuiteが12から19に増えました。
• SHA2系のCipherSuite、AES GCMのCipherSuiteが追加されました。
• でもRSA GCMは無くてECDSA GCMだけでかなり残念
• CipherSuiteの優先順位が微妙

GCMの対応はAndroid、MacOS X版Chrome、Android版Operaに続いてIE11もとうとう来たかという感じですね。Firefoxの対応が待たれます。過剰なBEAST対策祭りでAES止めちゃってRC4しか残してないとかRC4と3DESしか残してないとかいうサイトはつながらなくなったり、弱い暗号になっちゃったりするかもしれないのでケアしないといけないかもですね。

今日はこの辺で

とある事情で手元にsshdサーバーを立ち上げなければならず、とりあえずWindows 7上でcygwin OpenSSH sshdかなとも思ったんですが、なんかcygrunserv 入れろとか、設定とかいろいろ面倒臭いのでググって探してみるとfreeSSHdというのを見つけてしまいました。

幾つか立ち上がってるサーバーの設定を緩めてその場をしのぐなんていう手もあったのかもしれませんが、外向けに出しているサーバーの設定をいじるのもなんだかねぇ、、、と思いまして、使ってみたら「あら、意外にイケルじゃない」みたいな感じだったのでレポートしたいと思います。

インストール

インストールはウィザードでボタン押すだけ。サーバーの鍵も作ります。簡単です。Windowsのサービスとして入れることもできますが、自分の場合は暫定利用なもんでそうはしませんでした。

設定画面

サーバーの設定は、サーバー起動後にタスクトレイに入ってるアイコンから行います。開いて見るとデフォルトでsshdが動いており、オプションでtelnetdも動いちゃうようです。

sshdの設定はこんな感じ。まぁ、普通か、、、

対応している暗号はこんなの。CASTっていうのがやりますね。

ユーザのアカウントは独自のID/PWアカウント、Windowsのアカウント、sshクライアント鍵によるアカウントの3つが使えます。

ってなわけで、Windowsのsshdサーバーを手軽に立てたいときには楽チンポンで使えるので、個人的にはかなりおススメです。

こんなのが別途急に必要になったのもiPhoneのTouchTerm Pro SSHのせいなんですが、この話はまた今度、、、

仕事、仕事、で鬱積したものを何かにぶつけてみたくなり、今さらの感もありますが2010年9月16日にリリースされたInternet Explorer 9 betaのCipher Suiteを調べてみました。

バージョンはこんな感じです。

SSLのバージョンの設定

SSLのバージョンの設定ではSSL 2.0、SSL 3.0、TLS 1.0、TLS 1.1、TLS 1.2が設定できるようになっており、デフォルトは下の図みたいな感じです。

Cipher Suiteの違い

IE 9 betaのCipher SuitesはIE7、IE8に比べて以下のような特徴があります。

• TLS 1.2をサポートしておりRSA SHA256系、ECDSA SHA256系、AES_128/256_GCMなどが追加されている。GCMはSuite-B対応ですね。
• IE7、IE8にはあったEXPORT系のCipher Suiteが無くなった。

SSL2.0、SSL3.0、TLS1.0、TLS1.1、TLS1.2を全て有効にした場合のCipherSuitesはこんな感じ。

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_RC4_128_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
TLS_RSA_WITH_RC4_128_MD5

TLS拡張の違い

IE7、IE8と比較してTLS extensionには以下のような特徴があります。

• Renegotiation Info (0xff01)拡張が増えた。
• IE8のサポート楕円曲線はsecp256r1、secp384r1、secp512r1だったが、一つ減ってsecp256r1、secp384r1になった。

拡張の部分をwiresharkでみるとこんな感じです。

Cipher Suiteの表

いつもの場所にHTMLの表をアップデートして置いておきました。

ではでは

自分はWindows XPが大好きなのでWindow VistaやWindows 7はほとんど使ってなかったんですが、最近になって仕方なく使っています。これを書いているThinkPad X201sもWindows 7ですし、、、、

証明書ビューアーで証明書見ててちょっと疑問に思ったんです。

有効期間　1999/ 07/ 10 から 2019/ 07/ 10

なんで「有効」と開始日の日にちだけが太字になるんだろう？？？と、、、、「有効」にだけ特別な意味があるのか？？とか、、、、

で、ちょっと探して英語版の出力を見てみました。英語版では

Valid from 10. 3. 2009 to 10. 3. 2010

となっています。すると、単純にUnicodeでのバイト数で太字の位置を決めてるんじゃないかと、、、正しくは

有効期間　1999/ 07/ 10 から 2019/ 07/ 10 じゃなくて
有効期間　1999/ 07/ 10 から 2019/ 07/ 10

なんじゃないかと、、、 結構実装が適当ですねぇｗ。日付に余計な空白があるのも非常に違和感があります。

今日は小ネタで、、、、
おやすみなさい。

マイクロソフトのルート証明書の更新プログラムが2010年8月23日にリリースされていました。最近、全く気にしてなかったんですが nahi さんのつぶやきを見ていたら更新されていたことを知りました。

前回から3ヶ月しか経っていないので、大した更新も無いんじゃないかと思っているんですが、今更ながら調べてみました。自分の持っているルートが338→341に増えたので、たった3つだけ増えたってことらしいです。 で、増えたのは以下の3つ。

国	認証局名
US	Microsoft Root Certificate Authority 2010
US	AffirmTrust Premium ECC
LT	Registru Centro Sertifikavimo Centras, VI Registru Centras RCSC (RootCA)

Microsoft Root Certificate Authority 2010

MSのルートもSHA256withRSA 4096bitのルート証明書を出してきたみたいです。

AffirmTrust Premium ECC

米国 AffirmTrust の楕円のルート証明書です。曲線はOIDが1.3.132.0.34で 鍵長 384bit の曲線名がSEC 2ではsecp384r1、NISTではP-384と呼ばれているものです。 SEC 2は楕円暗号業界団体 Standards for Efficient Cryptography Group (SECG) が定めた楕円暗号に 関する規格です。署名アルゴリズムは SHA384withECDSA でした。

Registru Centro Sertifikavimo Centras

リトアニア(LT)のルート証明書は適格証明書(QC)のルート証明書になっていて SHA1withRSA 4096bit 鍵の証明書でした。QCステートメントを見てみると以下の値が設定されていました。

0.4.0.1862.1.1 QcCompliance

ETSI TS 101 862で規定されたQC準拠であることを示す。

0.4.0.1862.1.3 QcEuRetentPeriod: 値=10

この証明書は10年間CAで保存される。

0.4.0.1862.1.4 QcEuSSCD

証明書の公開鍵に対応した秘密鍵がセキュアな署名生成デバイス (SSCD:Secure Signature Creation Devidce)上にあることを示す。

OIDが 1.3.6.1.4.1.311.21.1のMicrosoft CertSrv CA Version (cAKeyCertIndexPair?)拡張 が入っているのでWindows Server 2003以降のCAから発行されたもののようです。

これからRSA鍵のルートCAは鍵長4096bitっていうのが多くなってくるんでしょうね。

関連記事

• Windowsルート証明書の更新プログラム (2010.05)
• Windows ルート証明書の更新プログラム(2009.11)
• Windows ルート証明書の更新プログラム(2009.09)の続き
• Windows ルート証明書の更新プログラム(2009.09)
• Windows ルート認証機関の更新(2009.02)

手持ちのRedHat7.3のイメージでVMwareのホスト側のバージョンアップをしたらバージョンの不一致のようでフォルダ共有機能が使えなくなってしまった。このままだと面倒臭いので、入れなおすことにした。忘れっぽいのでメモを残す。

1. VMwareアプリのメニューで「VM＞VMware Toolsのアップグレード」を選択。
2. % mount /dev/cdrom /mnt/cdrom
3. 適当な場所で解凍

   % cd /tmp
   % tar xvfz /mnt/cdrom/VMware-*.tar.gz
   % cd vmware-tools-distrib
   % cd vmware-install.pl
   

   RedHat7.3ならば、カーネルが古すぎて対応できない1つを除きバイナリが入っているのでコンパイルの必要はなかった。
4. 以降、デフォルトでOK
5. インストーラ終了後、vmxnetドライバを設定。

   % /etc/init.d/networking stop
   % rmmod pcnet32
   % rmmod vmxnet
   % modprobe vmxnet
   % /etc/init.d/networking start
   

これでちゃんと、/mnt/hgfsでフォルダ共有が戻ってきた。よかった。

英語キーボードがすきなのに日本語キーボードを使わざるを得なかったり、EmacsなどCtrlキーを多用するソフトを使っている人はコントロールキーやCapsLock、Escなど入れ替えを行っている人も多いんじゃないかと思います。昔、AltIMEを使っていて、今までKeySwapを愛用していましたが、ちょっと困ったことが起きました。

できて欲しいのは

• 共用で使うマシンで、自分だけキーの入れ替えをしたい。
• CapsLockと左Ctrlの入れ替え
• Escと半角/全角の入れ替え

ってことなんですが、これを満たすようなフリーウエアがなさそうだってことがわかりました。調べてみたフリーウェアはこんなとこ

KeySwap

レジストリ書き換え型。全ユーザ対象にしたキー再配置しかできない。

AltIME

常駐型。いろんな環境でアンインストール等に不具合報告がでているようだ。私も動かないことがあってあきらめた。確かマルチユーザ対応でなかったと思う。

秀Caps

そもそもCapsLockと左Ctrlの入れ替えはできない。

VistaKey

できそうな雰囲気だが、シェアウェアで登録しないと機能が使えなそうだ。

困り果て、Googleで調べているうちに(自己責任ながら)レジストリ書き換えでできそうだってことがわかりました。(参考：Windowsで特定のユーザだけCapsとCtrlを入れ替える)レジストリのScancode Mapというものがデフォルトでは未設定になっているわけですが、これを設定することにより変更できるそうです。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout

ならばユーザ全員に対してですが、

HKEY_CURRENT_USER\Keyboard Layout

ならば現ユーザに対してのみ設定されます。

ブログで紹介されているのは、CapsLockとCtrlの入れ替えのみなので、KeySwapを使ってEscと全角半角を入れ替えるScancode Mapの値を調べてHKEY_CURRENT_USERで設定してやれば、無事目的のことはできました。 前述の二組のキー入れ替えのためのカレントユーザ向けレジストリ設定は以下のようになります。

Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Keyboard Layout]
"Scancode Map"=hex:00,00,00,00,00,00,00,00,05,00,00,00,3a,00,1d,00,1d,00,3a,00,\
29,00,01,00,01,00,29,00,00,00,00,00