2009年03月13日

新たな中間者攻撃にはEV SSLの活用を――ベリサイン

これは、BlackHat で公表された
に対するアンサーソングですね。
こりゃどんな攻撃だったかというとにある通り、
エンドユーザーの SSL や HTTPS に対する理解の浅さを利用したり
巧妙な? 見た目の偽装によって中間車攻撃に気付かせない工夫をする
という、良く考えると中々怖い攻撃だなと思うんですが
(自分がどれだけ SSL 通信に敏感になっているか分かりませんし、いわんや例えばうちの母親)
EV だったら見た目からして分かりやすいし大丈夫だよ!! ってこと言ってらっしゃいます。

「見た目からして分かりやすい」っていうのは
EV SSL サーバ証明書を使ってるサイトを見にいくと、対応ブラウザであれば
  • アドレスバーなど分かりやすい部分が緑いろっぽくなる
  • アドレスバーなどに証明書所有者や発行者の名前が表示される
ので、そのサイトが一体誰によって運営されてるか分かりやすくなる、というものです

そんなん EV SSL じゃなくたって審査してある証明書だったら表示したらいいじゃない
と思う方もいらっしゃいますでしょうが、上は技術的な話の一部でして
審査基準も統一ルールが定められてて中々厳しい内容になっていたりして
多分、だから、その審査基準の下で名前表示してもいいよね、ってことなんだと思います。
たぶん。

Moxie Marlinspike さんのプレゼンだと
login.yahoo.com や mail.google.com のアカウント情報が引っこ抜けたということなので
この辺りに EV SSL サーバ証明書を導入した方がいいよ!! って言ってるんだと思いますが
きっとクラウドがバリバリの Web サーバが後に沢山控えているだろうサービスで
EV SSL を実現するとなると何枚くらい証明書買ったら勘弁してもらえるんでしょうねぇ。
ラベル:EV MITM
posted by OJH at 22:17| Comment(0) | TrackBack(0) | ニュース | このブログの読者になる | 更新情報をチェックする

IIS で SSL するなら certreq.exe が素敵

Windows Server には certreq なんてコマンドがあったんですね
IIS 使っていいて SSL サーバ証明書を導入しようとしたときに
CSR を作るウィザードとか出てくると思うんですが
その API をコマンドラインから叩けるものみたいです
別件で検索してたら
というページを拝見しまして
を見ながらいじってみました。

作ってみた inf ファイルはこんな感じ
[NewRequest]
Subject = "C=JP,ST=Tokyo,L=Chiyoda-ku,O=SSL-PKI,CN=ssl-pki.seesaa.net"
Exportable = TRUE
KeyLength = 2048
MachineKeySet = TRUE
SMIME = FALSE
比較的ミニマルな感じで作ってみました。
Subject の RDN の区切り文字が "," なんですよね。
これは IIS のウィザードでも "," が入力できないのと対応しています。

これを test.inf という名前で保存して
> certreq -new test.inf test.csr
とコマンドを打つと test.csr に CSR が書き出されます。
秘密鍵は Windows の奥底に保存されて眠っているはず。
RFC 5280 のことは考えず、とりあえず署名して証明書作ります。
ここは慣れてるので OpenSSL で
$ openssl req -x509 -new -out CA.crt -keyout CA.key
$ openssl x509 -req -in test.csr -CA CA.crt -CAkey CA.key -set_serial 37 -out test.crt
これで test.crt という証明書ができました。

最後にこれを Windows にインストールします
> certreq -accept test.crt
これで「保留中の要求を処理し、証明書をインストールする」と同じ状態になります。
「IIS マネージャ」の「サイトのプロパティ」の「ディレクトリセキュリティ」の「サーバ証明書」から
「既存の証明書を利用」とか「現在の証明書を置き換える」を選ぶと
test.crt も一覧の中に出てきます。
今回はここで止めてしまったんですがこれだとルート証明書が無くてちょっと良くないかも。
まぁ、実際はルート証明書とか中間認証局の証明書もインストールしましょう。

IIS で SSL するだけなら簡単なんですが
CSR とサイトが紐付いてしまっているうえに
「更新」で Subject の Distinguished Name や鍵長が変更できなかったり
不自由な部分があるんですけど certreq.exe を使えば分離できて happy な感じ。
もしかしたらウィザード自体が個別に呼べたりするなら何の問題も無いんですけど。
変に CSR 作って証明書入れるだけの為にサイト作るよりはこっちがスマートだなぁ。
ラベル:CSR IIS Windows ssl
posted by OJH at 00:41| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2009年03月11日

RFC 5280 の 4.2.1.9. Basic Constraints

「基本制限」拡張は
  • その証明書は認証局のものかどうか
  • その証明書を含む階層の深さを幾つまで認めるか
に関して記述されます。
何で「基本」かっていうと、階層をの検証の為に X.509 のバージョン 3 で
拡張を用意したからで、証明書が認証局のかどうかってのは基本ですよね。

id-ce-basicConstraints OBJECT IDENTIFIER ::=  { id-ce 19 }

BasicConstraints ::= SEQUENCE {
     cA                      BOOLEAN DEFAULT FALSE,
     pathLenConstraint       INTEGER (0..MAX) OPTIONAL }

cA

認証局かどうかに関しては cA という真偽値を入れるところで表現します。
これが TRUE ならば証明書の公開鍵を使って署名を検証することを
認証局が認めていることになります。

4.2.1.3. で公開鍵の利用方法の制限に関して見ました。
署名の検証に使うには keyCertSign が指定されてなくてはいけませんでした。
keyCertSign が指定されていたら cA も指定されてなくてはいけませんし
cA が指定されていなかったら keyCertSign は指定されてはいけません (MUST NOT)。
「基本制限」が無かったり、あっても cA が指定されていなかったら
その証明書の公開鍵を署名の検証に使ってはいけません (MUST NOT)

pathLenConstraint

階層の深さに関しては pathLenConstraint というので指定します。
これは、cA が TRUE でないと意味がありません (keyCertSign も同時に指定されてます)。
cA が TRUE で keyCertSign が設定されてなかったら
pathLenConstraint は設定してはいけません (MUST NOT)。

認証局の証明書である場合 pathLenConstraint でもって
「階層に現れる自己署名証明書でない中間証明書の枚数」の最大値を指定します。
pathLenConstraint が 0 だと中間証明書を許さないということになります。
エンドエンティティなど階層の最後の証明書は数えないので注意しましょう。
pathLenConstraint は 0 以上の整数でなくてはいけません (MUST)。
pathLenConstraint が無い場合は階層の深さは無制限となります。

Critical

RFC 5280 に従う認証局は、
証明書の電子署名を検証する為の認証証明書を発行するときには
「基本制限」拡張を含めなくてはいけません (MUST)。
また、「基本制限」拡張はクリティカルでなくてはいけません (MUST)。
証明書の電子署名を検証する以外の目的の認証局証明書であれば
(CRL の署名検証とか鍵交換に使う場合)
クリチィカルであってもノンクリティカルであっても構いません (MAY)。
エンドエンティティーの場合もクリティカル/ノンクリティカルを問いません (MAY)
ラベル:階層 認証局 RFC5280
posted by OJH at 03:11| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2009年03月07日

RFC 5280 の 4.2.1.8. Subject Directory Attributes

「サブジェクトディレクトリ属性」はサブジェクトの属性の確認に使われます。
id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::=  { id-ce 9 }

SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute

Attribute               ::= SEQUENCE {
      type             AttributeType,
      values    SET OF AttributeValue }
            -- at least one value is required

AttributeType           ::= OBJECT IDENTIFIER

AttributeValue          ::= ANY -- DEFINED BY AttributeType
属性の SEQUENCE になるわけですが、これは RDN と何が違うんですかねぇ
RelativeDistinguishedName ::=
  SET SIZE (1..MAX) OF AttributeTypeAndValue

AttributeTypeAndValue ::= SEQUENCE {
  type     AttributeType,
  value    AttributeValue }

AttributeType ::= OBJECT IDENTIFIER

AttributeValue ::= ANY -- DEFINED BY AttributeType
「サブジェクト」とか「発行者」に書くのと何が違うんでしょう
重要度?
例として nationality が挙げられていたりしますが。

この拡張はノンクリティカルにしなくてはいけません (MUST)
posted by OJH at 12:32| Comment(1) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

RFC 5280 の 4.2.1.7. Issuer Alternative Name

4.2.1.6 で Subject に対する Subject Alternative Name を見ましたが
Issuer Alternative Name は Issuer に対する別名になります
サブジェクトの別名と同じ様に記載されなくてはいけません (MUST)

サブジェクトの別名は証明書階層の検証の際に利用されるのですが
発行者の別名は 6 節で説明される証明書階層の検証には利用されません
なので、この拡張はノンクリティカルとすべきです (SHOULD)

id-ce-issuerAltName OBJECT IDENTIFIER ::=  { id-ce 18 }

IssuerAltName ::= GeneralNames
ラベル:別名 発行者 RFC5280
posted by OJH at 12:09| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする
×

この広告は180日以上新しい記事の投稿がないブログに表示されております。