自堕落な技術者の日記

2015年5月12日に、IPAのサイトでCRYPTRECのWGで作成した 「SSL/TLS暗号設定ガイドライン」が公開されました。

このSS/TLS設定ガイドラインが作成された背景や概要は菊池先生の CRYPTRECシンポジウム2015での 講演資料にわかりやすく書いてありますので、これをご覧頂くのが 一番よいかと思います。

このガイドラインはサーバー管理者向けに、 なるべく暗号のことは細かく触れずに、 (とはいえ細かい暗号の話も多いですが、、、) 昨年度、特に多かったSSL/TLS関連の様々な脆弱性に対して、 どのように設定すればいいのかを解説しています。 紹介されているコラムなど読み物としてもなかなかおもしろいので、 是非ご覧いただければと思います。

ガイドラインでは、用途に応じて3つのタイプに分けて設定を紹介しています。

• 政府・金融・医療など高いセキュリティが求められる場合の設定→高セキュリティ型
• 一般的な推奨設定→推奨セキュリティ型
• 古いブラウザ、ゲーム機、フィーチャーフォンなどへの対応も必要な場合→セキュリティ例外型

特に暗号スイートやプロトコルの設定を、昨今の脆弱性・暗号危殆化に照らして どのように設定するのかというのが、管理者のみなさん悩ましいところだと思うのですが、 これを巻末のAppendixにて、具体的にどのサーバーではどう設定すればよいのかを 記載しています。

ただ、あれを全部読んで動く設定ファイルを作るのってページ数も多いし結構骨が折れるかなと思います。 そこで、ガイドラインの公開を記念して、 ガイドラインのタイプやサーバーの種類を選んで、ボタンを押せば設定ファイルが 作れるようなツールを作ってみました。(ぱちぱちぱち)

HTTPS設定ファイル生成ツール0.2(ベータ版)
https://kjur.github.io/jsrsasign/tool/tool_httpscfg.html

今のところ、Apacheとnginxだけだったり、推奨設定の一部だけだったりするんですが、 プロトコルや暗号スイートなどは押さえているので、よかったら使ってみてください。

字は小さいですが、スマホブラウザでも設定ファイルが作れます。ぼちぼちアップデートして フル対応にしますので、乞うご期待ってことで。

あと、このツールの面白いのはCRYPTREC/IPAのガイドラインだけでなく、 MozillaやQualysなどの推奨設定や、Linux系OSのデフォルト設定も 試せるようになっている所です。暗号スイートの設定みてニヤニヤしていただければと、、、

今日はこの辺で、、、

(追記 2021.03.25) ツールのリンク切れを修正しました。

情報処理推進機構：情報セキュリティ：IPA暗号フォーラム2008・大川賞受賞記念シンポジウムのご案内

暗号の世代交代という状況をふまえ、また大川賞受賞を記念してRSA暗号の開発者の一人であるAdi Shamir教授（イスラエル・ワイツマン研究所）と基礎研究から応用技術の開発に至る幅広い分野において、我が国の暗号研究をリードしてこられた今井秀樹教授（中央大学、東京大学名誉教授）のお二方をメインゲストにお招きし、「暗号技術の今後」と題して、IPA暗号フォーラムを、開催いたします。

日時：2008年11月21日（金）　13：00〜18：00　（12：30　開場）
会場：東京大学生産技術研究所An棟コンベンションホール

今年も開催されるんですね。昨年はAdi Shamir先生とトイレで隣になりびっくりしました（　´∀｀）つ

情報処理推進機構：情報セキュリティ：調査・研究報告書：情報セキュリティに関する脅威に対する意識調査 報告書

せきゅめもで書かれていたことも、IPA報告書もちょっと違うんじゃないかなぁと思いまして、ひとこと書いてみたいと思います。

IPAで行われたセキュリティの意識調査の報告書で被験者の方に以下のような質問をしており正解は「○」だったりします。

ブラウザの SSL の鍵マーク (サイトの証明書) を確認することは、偽サイトかどうかを見破るのに有効です

正解「○」

この問題の正解率は35.5%だったそうで、せきゅめもさんとこでは設問を勘違いしたのでは？という論調だったんですが、EV SSLサーバー証明書(以下EV証明書)を知っている人なら、この設問はあえて「×」をつけたんじゃないでしょうか？私も「×」だと思います。

EVができる前、とある米国の金融系サービスでHTTPSサイトなのにフィッシング詐欺を行うためのウェブサイトが初めて出現し話題となりました。例えば、本物の金融サービスサイトは

https://www.aaa-bank.com/

であるのにフィッシングサイトは以下のようになっていました。

https://www.aaabank.com/

どちらもHTTPSのサイトでありドメイン名も酷似しているサイトでフィッシングが行われたのです。ここでミソなのはフィッシングサイトの方もショボイ自己署名やプライベートルートではなくWindowsやFirefoxの信頼するルート認証局に入っているルート認証局から発行されたものであるということです。安物のサーバー証明書であるにせよ、騙す方も得するならきちんと投資するんですよね〜〜〜〜。

SSLサーバー証明書は通信しているウェブサイトとそのFQDNホスト名が一致している事のみを保証するもので、そのウェブサイトが非合法であろうがアダルトであろうがフィッシングサイトであろうが構わないわけです。ですから鍵マークがついているからといってニセサイトであるかどうかはわからないのです。

問題を引き起こす原因は以下の通り。

1. ドメイン名は運営主体組織の名称と何ら関係なくても取得することができる


2. そのドメイン名の持ち主であれば、本当の銀行のドメイン名に酷似していようがメール一本でSSLサーバー証明書を発行するような認証サービスがある

このような問題を解決するためにEV証明書が生まれました。EV証明書は運営企業の登記情報や企業活動拠点を確認した上で発行するので、この証明書でHTTPSフィッシングサイトを立ち上げてもすぐ足がつきます。従って逆に、安心して利用できる正式のサイトということになります。
登記された実体のある企業でも潰れる前とか悪いことしないとは限らないんですけどね、、、（＾＾；

というわけで鍵マークがついているだけでは安心ではなくて、ホスト名が正しいものかどうか、格安ではなくまともなところから出ている証明書かどうか確認したほうがいいんじゃないかと思います。でも、一般ユーザにこんなことをお願いするのって難しいですよね、、、、うちの家族は誰もEV証明書の事なんか知らないと思います(；´Д｀)

EVのウェブブラウザの実装でアドレスバーの色や証明書の表示だけでなく、whoisなどによるドメインの所有者の情報も表示するようになれば、より安心なんじゃないかと思います、、、、

Challenge PKI Test SuiteにてDN中の属性名が大文字だとマズイ件 - livedoor Blog（ブログ）


Challenge PKI Test SuiteですっかりMultivalued RDNに対応させた気になっていたのですが、CのASN.1エンコーダは対応していたものの、スクリプト側の方が対応していなかったことに気づき今しがた書き直しました。

Multivalued RDNとは、一つの相対識別名(RDN)に通常一つのところを複数のAttributeTypeAndValueが入るというものです。例えばこんな感じ、、、、

CN=Taro+OU=HR,O=Foo,C=JP

一つの相対識別名CN=TaroとOU=HRの中に二つのAttributeTypeAndValueが入っています。

とあるCA製品ではCNだけだとローマ字が同じ姓名だとかぶってしまい登録できないみたいなことが無いようにCNには姓名ローマ字、serialNumber(注：証明書シリアル番号ではなく属性タイプ)には社員番号などというようにMulti valued RDNで一つのRDNとしています。

CNとserialNumberとを別のRDNにすると、一人のユーザに2つのディレクトリエントリを消費することになり、ディレクトリサーバーがディレクトリ単位で課金されるような場合にはコストがかかるりますが、Multi valued RDNならば1ユーザ1エントリで済みます。

ただ、スマートカードやアプリケーションなど証明書を利用する側でMulti valued RDNに対応していないケースもあり事前に動作検証をしておくとよいでしょう。

IPA/JNSAのChallnege PKI Test Suiteは2.0以降、証明書等の生成の部分をオリジナルのASN.1エンコーダーに入れ替えたりしているのですが、今日DNを入れて証明書を作ってみようとするとエラーが、、、、証明書中の識別名が

○：ou=Test,c=JP
×：OU=Test,C=JP

のように属性名が小文字だとエラーになり、大文字だとエラーにならないというものです。トホホ、、、急いで修正、、、、

2.2以降だとでる問題なので、公開版には多分影響はありません。

情報処理推進機構：情報セキュリティ：セキュリティ関連NIST文書

NIST OMB M-04-04
連邦政府機関向けの電子認証にかかわるガイダンス
E-Authentication Guidance for Federal Agencies
の邦訳が公開されました。

邦訳
http://www.ipa.go.jp/security/publications/nist/documents/OMBm04-04.pdf
原文
http://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdf