どさにっき IoT

by やまや
10月下旬

2016年10月21日(金)

GlobalSign の件、つづき

_ たしかに RFC としては CRLに失効理由として一時停止という状態が定義されていて、 OCSPでは一時停止状態でも恒久失効と同じに扱うと定義されている。

_ が、各 OS、ブラウザにインストールされている「信頼されるルート CA」は、これだけでなくさらに CA/Browser Forum で策定される基準にしたがっている。で、その baseline requirements

4.9.13. Circumstances for Suspension
The Repository MUST NOT include entries that indicate that a Certificate is suspended.
と規定されてるそうで。RFC 的には一時停止状態ってのもありうるけど、まっとうな CA ではそういうのは許さん、恒久的な失効しかありえん、と。

_ ということで、OCSP で失効させたものを復活させたという globalsign の対処は妥当だったのかどうかという疑念が再発するわけだけど、わしみたいな素人が思いつくような疑問は当然のように 識者たちでも議論が始まっていた。うん、どうなるんかね。

Comodo もやらかした

_ さらに globalsign の件とはまったく関係なく、 Comodo SSL もやらかしたようで。証明書の発行プロセス中のドメイン所有者の確認に問題があり、正しくない相手に証明書を発行してしまったと。で、その理由が「OCR の読み取りエラーで l と 1 を間違えた」というナナメウエすぎるものでお口ぽかーん。


2016年10月17日(月)

GlobalSign 失効騒ぎ

_ 先週 GlobalSign がやらかした障害について 詳細な報告書が出てた。一読してだいたい理解できたけど、字ばっかで図がないのでやっぱりわかりづらい。わかりやすくしてみる。

_ 障害発生前の状態。

+----------+     +--------+      +----------+
| Root(R1) |-----| 中間CA |------| EE証明書 |
+----------+     +--------+      +----------+
                      |
+----------+     +---------+
| Root(R2) |-----|crossroot|
+----------+     +---------+
EE(エンドエンティティ)証明書ってのはサーバ証明書とかクライアント証明書とかコード署名証明書とか、要するに一般ユーザが買う証明書のこと。通常は EE - 中間 CA - Root1(R1) のパスで検証されるけど、信頼する CA のリストに Root(R1) が含まれないクライアントのために、EE - 中間 CA - クロスルート CA - Root(R2) というパスもある。ここで、Root(R1) とクロスルートは同じ Subject で同じ鍵を有する。これらが同じということは中間 CA から見れば Issuer が同じということなので、どちらのパスを通っても検証が可能になる。R1、R2 についての詳しい情報は ここ

_ で、このクロスルート CA が引退することになったので、10/7 にこいつの証明書を失効させて CRL に載せたそうな。CRL を使って失効検証している場合、この時点で R2 による検証はできなくなり、R1 に一本化された。ここまでは問題なし。

_ OCSP での失効処理は少し遅れて 10/13 に実施。が、ここに不具合があり、クロスルート証明書を失効させるつもりが、同じ subject で同じ鍵である Root(R1) の証明書の方を失効扱いにしてしまったらしい。ただ、この R1 は CRL も OCSP もどちらも配布ポイントが証明書に定義されていなかったので、実際には失効させようにもできない。なので、次善策として、R1 が発行したすべての証明書を失効させるという動作になり、結果として R1 の下にいるすべての中間 CA の証明書が失効した、と。やらかしたことに気がついて OCSP レスポンダはほどなく修正したんだけど、これはブラウザや OS によってキャッシュされるので、影響は数日続く(逆に言えば、障害以前のキャッシュがあれば障害の影響を受けなかった)。

_ ここから globalsign の報告書には記載されていないこと。

_ 証明書の失効状態は大きくわけて2つある。revoked(失効)と hold(一時停止)。通常失効といえば前者で、失効させたら二度と復活できない。一方、秘密鍵がどっかいっちゃった、いま探してるけど第三者に盗まれる恐れはないよ、なんてときには一時的に hold という状態にすることができる。で、hold な状態から有効な状態に戻すことはできるけど、そうではない revoked な状態から有効な状態に戻すことはできない。globalsign は間違えて失効させてしまった、と言ってるわけで、キャッシュ切れを待とうが何をしようが一度失効させてしまったものを復活させることはできないのでは? やろうと思えば CRL から消して OCSP の応答を good に変えることでできなくはないけど、それをやったことが発覚すると CA の認定取り消しもありうるレベルの運用規程違反じゃないの?

_ …と思っていた。調べてみたら、RFC6960 (OCSP) にこう書かれていた。

The "revoked" state indicates that the certificate has been revoked, either temporarily (the revocation reason is certificateHold) or permanently.
なんと、OCSP では失効と一時停止の区別がなかった。区別がないので、いったん失効扱いにした証明書が後から復活しても OCSP ならとくに問題ないらしい(CRL ならアウト)。

_ もひとつ。OCSP のキャッシュ切れが待てない場合の対処として、別に作成した中間証明書を使ってくれ、と 案内していた。が、R1 が発行した中間 CA は OCSP からは復活したので、もともとの証明書と緊急対応用の証明書で、同じ中間 CA の証明書が同時に2枚存在することになってしまう。そういうのってアリなの? 片方を失効させなくていいの?

_ …と思って確認してみたら、緊急対応用の中間証明書は R1 でも R2 でもない別のルート CA である R3 から発行されていた。

+----------+     +---------+      +----------+
| Root(R1) |-----| 中間CA1 |------| EE証明書 |
+----------+     +---------+      +----------+
                                     |
+----------+     +---------+         |
| Root(R3) |-----| 中間CA3 |---------+
+----------+     +---------+
R1、R3 それぞれのの下にある中間 CA は subject と鍵が同じ。R1 とクロスルート CA の関係と同じ。なので、R1 が失効して信頼できなくなった状況でも、R3 の発行した中間証明書を使っていれば R3 への検証パスがつながる(中間証明書はどちらか一方しか入れられないので、クロスルートのようにどちらでも検証可能にはならない)。ただ、技術的にはこれで検証は可能になるけれど、ルート CA にはそれぞれ利用目的ってものがあって、 リポジトリにもあるとおり、R1 と R3 では発行する証明書の品目が異なる。R1 は DV/OV 用のサーバ証明書を発行していて、R3 は EV 証明書らしい。混ぜちゃって大丈夫なの? めんどくさいから CP/CPS とか読んでないけど、そういうことをやっちゃってもいいような運用規程になってるの?


2016年9月14日(水)

無題

_ いくつか反響あったので補足。「ユーザがサブドメインを自由に作成できるサービス」について。

_ WoSign がやらかした件では github.com だったけど、TXT レコードへの記述が必要なのでこういうサービスは不可。共用の DNS ホスティングサービスで、ドメインの所有者チェックが甘いところだと、example.com の所有者とはまったく赤の他人が example.com のサブドメインを契約できちゃったりする。こういうところがヤバい。具体的には こういう(これはすでに修正済み)。 JPRS の注意喚起。根本的にはこういうチェックの甘い事業者が悪いんだけど、ちゃんとチェックしてるかどうか外部から判断する方法はない。

_ また、TXT レコードを書ける dynamic DNS サービスもある。 このサービスなんか TXT に対応してる上に、ユーザが自分のドメインをここに持ちこんだ上で、それを dynamic dns としてサブドメインを他ユーザに開放するなんてこともできちゃう。この手法で証明書を取得されるとまさに「庇を貸して母屋を取られる」状態なわけなんだけど、実際試してみたらアンスコを含むサブドメインは規制されていて失敗。が、そのときのエラーメッセージが「2016-02-10 以降一時的にダメにしてるよ」とのことだったので、それ以前はできてたみたいだし、そのうちまたできるようになるかも。ちなみに、_acme-challenge はダメだったけど、wpad というサブドメインはふつーに作れたので別の意味でヤバい。この DDNS サービスに近寄っちゃダメ。

_ Let's Encrypt (というより、その根拠となる ACME プロトコル)の問題は、あるドメインの管理者とそのサブドメインの管理者が同じとはかぎらないのに、サブドメインのコントロール可能をもって親ドメインの管理してるとみなしていること。

_ ちなみに、同じように DNS でドメイン所有の確認をしているサービスはほかにもいくつかあるけど、たとえば Google AppsOffice365はサブドメインを使わずそのドメインそのもの(apex)に認証トークンを記述するよう求めていて、Let's Encrypt のような問題が起きることはない。まあ、ANY 応答のサイズがまた肥大化するという別の問題はあるけど。


10月下旬
やまや