「証明書の不正発行や日付改ざんを行っていた認証局「WoSign」、Firefoxが同社による証明書をブロックへ」記事へのコメント

一方で、Firefox は Let's Encrypt を信頼済みルートCAへ追加

[Printable is bad. (38668)]

Mozilla が Let's Encrypt Root を認証局として信頼 [letsencrypt.jp] によると、Firefox 50 以降では、Let's Encrypt が Firefox の信頼されたルート証明機関に含まれるようになります。

今までは、Let's Encrypt は、IdenTrust Root からチェーンされていたことで信頼済みとして扱われていたわけですが、これからは独立した認証局として信頼済みとなります。

無料でTLS証明書を発行している中国のCA「WoSign」をブロックする一方で、同じく無料でTLS証明書

Re:

[Anonymous Coward]

Let's Encryptも同じ問題を抱えているという指摘 [ya.maya.st]もあるため、これが事実ならば信頼済みに入れて欲しくないですね。

Let's Encrypt、というよりACMEプロトコルの仕様は問題ないと思う

[Printable is bad. (38668)]

Let's Encryptも同じ問題を抱えている

全然同じじゃないです。中国最大級の認証局「WoSign」がニセの証明書を発行していたことが判明 [gigazine.net]によると「WoSign」の件は「脆弱性」です。一方、「DNSレコードに認証用のレコードを追加」することでドメイン所有者と認証されるのはACME プロトコルの仕様です。認証の仕組みの概要についてはLet's Encrypt の仕組み [letsencrypt.jp]をご覧ください。

そもそも、ACMEプロトコルの認証用レコードに「_」が含まれているのは、セキュリティ上の理由です。DNSにはアンダースコア付きのレコードが登録できる [ietf.org]けど、HTTP [ietf.org]とかSMTPとかでは使えないので、ホスティングサービスにお

Re:

[Anonymous Coward]

ここまで間違い・まとはずれだらけなコメントが参考になるといわれても。

全然同じじゃないです。

同じです。
WoSignと同様にサブドメイン管理者が親ドメインのSSL証明書を取得できることに問題があるという指摘ですが、理解できていますか？
TXTレコードでドメイン所有権を確認することは一般的ですが、サブドメインのTXTレコードで親ドメインの所有権を確認するのは、一般的ではありません。

ACMEなんて、Let's Encryptのために作られたもので実績も何もないです。
それを「問題ない

Re:Let's Encrypt、というよりACMEプロトコルの仕様は問題ないと思う

[Printable is bad. (38668)]

使えます。 [ietf.org]

ご指摘ありがとうございます。

RFC 2616（HTTP/1.1）の URL の定義の参照先は RFC 2396 であるためアンダースコアは使えませんが、RFC 2616 は2014年6月に改訂版HTTP/1.1 仕様 (RFC7230 ～ RFC7235) が発行されたことにより廃止になっており、「HTTPとかSMTPとかでは使えない」の根拠として不適切でした。新しい HTTP/1.1 の RFC を確認したところ、[RFC 7230] 2.7. Uniform Resource Identifiers [ietf.org] の参照先は [RFC 3986 Uniform Resource Identifier (URI): Generic Syntax] 3.2.2. Host [ietf.org] になっており、URI の書式としてホスト名にアンダースコアが使えるようになっていました。廃止になった古いRFCを提示してしまったことを、お詫び申し上げます。

ホスト名にアンダースコアは使えないと記憶していたので調べなおしてみたところ、有効なホスト名の制限 [wikipedia.org] に、

ドメイン名と違い、ホスト名のラベルはASCII文字の'a'から'z'まで(大文字小文字は無視される)と、'0'から'9'の数字そしてハイフンだけを使うことが出来る。ラベルの最初と最後の文字にハイフンを使うことは出来ない。ハイフン(そしてラベルの間に打つドット)以外の特殊文字は時に誤って使われるが許容されない。 また、アンダースコアはWindowsで構築されたシステムで一般に使われるが、RFC 952によれば許容されない。また、DomainKeysやSRVレコードのようないくつかのシステムはそれらの特別なドメイン名がホスト名と混同されない事を確実にするために故意にアンダースコアを使用する(これらはドメイン名であるので許容される)。

と、ホスト名にはアンダースコアが使えないとありました。しかし、RFC 952 も古いので、新しいインターネットにおけるホスト名の要件が定義された RFC 1123 を確認したところ、ホスト名に使える文字は増えたものの（先頭に数字も使えるようになった）、アンダースコアが使えないのは同じでした。

新しい HTTP/1.1 の仕様（参照先RFC 3986は URI の仕様）では確かにホスト名にアンダースコアは使えるけど、インターネット上のホスト名にはアンダースコアは使えない（[RFC 1123 ]Requirements for Internet Hosts -- Application and Support [ietf.org]）ので、アンダースコアを含むホスト名の使用はイントラネットやローカルなどでの使用に限定されるようです。

WoSignと同様にサブドメイン管理者が親ドメインのSSL証明書を取得できることに問題があるという指摘ですが、理解できていますか？
TXTレコードでドメイン所有権を確認することは一般的ですが、サブドメインのTXTレコードで親ドメインの所有権を確認するのは、一般的ではありません。

ACMEなんて、Let's Encryptのために作られたもので実績も何もないです。
それを「問題ないと思います」といわれても、実際に問題があるでしょ、としかいえません。

「サブドメインのTXTレコードで親ドメインの所有権を確認する」のは、一般的です。

確かに、SPFレコードなんかは、親ドメインに効力を与えるのは親ドメインのTXTレコード（"@"）だし、サブドメイン付きの "@mail.example.com" に効力を与えるのは "mail" というサブドメインのTXTレコードです。

しかし、前述した DKIM や DomainKeys の仕様も、「key1._domainkey」「_adsp._domainkey」「_policy._domainkey」といったサブドメインのTXTレコードが、親ドメインに効力を発揮しています。これは、「_acme-challenge」というサブドメインのTXTレコードが、親ドメインに効力を発揮しているのと同じことです。それ以外にも、SRVレコードなども同じようにサブドメインのTXTレコードが、親ドメインのものとして扱われています。

DNSの仕組みは古いので、どのアプリケーションに対するレコードなのかを定義するラベルが存在しないため、DKIM とか SRV とか ACME は、サブドメイン名をラベルのように使っているわけです。

確かに、サブドメインの管理者が違うケースなどを考えるとセキュリティ上問題があるケースも考えられますが、ラベル（サブドメイン名）無しに全アプリケーション向けのTXTレコードを書くと、他のアプリケーションに向けたTXTレコードもすべて取得しなければならなくなり、効率が悪くなります。DKIM とか SRV も同様の問題を抱えているのですから、ACME が仕様を変更するのではなく、サブドメインの管理者が別の場合にはサブドメイン名にアンダースコアを認めないことでセキュリティは確保すべきだと思います。

確かにあまり良い仕様とは思えませんが、DNSの仕様が古く、TXTレコードの対象アプリケーションを指定するラベルというものが存在しないので、サブドメイン名をラベルのように使うのは現状ではやむを得ないでしょう。