アカウント名:
パスワード:
Mozilla が Let's Encrypt Root を認証局として信頼 [letsencrypt.jp] によると、Firefox 50 以降では、Let's Encrypt が Firefox の信頼されたルート証明機関に含まれるようになります。
今までは、Let's Encrypt は、IdenTrust Root からチェーンされていたことで信頼済みとして扱われていたわけですが、これからは独立した認証局として信頼済みとなります。
無料でTLS証明書を発行している中国のCA「WoSign」をブロックする一方で、同じく無料でTLS証明書
Let's Encryptも同じ問題を抱えているという指摘 [ya.maya.st]もあるため、これが事実ならば信頼済みに入れて欲しくないですね。
Let's Encryptも同じ問題を抱えている
全然同じじゃないです。中国最大級の認証局「WoSign」がニセの証明書を発行していたことが判明 [gigazine.net]によると「WoSign」の件は「脆弱性」です。一方、「DNSレコードに認証用のレコードを追加」することでドメイン所有者と認証されるのはACME プロトコルの仕様です。認証の仕組みの概要についてはLet's Encrypt の仕組み [letsencrypt.jp]をご覧ください。
そもそも、ACMEプロトコルの認証用レコードに「_」が含まれているのは、セキュリティ上の理由です。DNSにはアンダースコア付きのレコードが登録できる [ietf.org]けど、HTTP [ietf.org]とかSMTPとかでは使えないので、ホスティングサービスにお
ここまで間違い・まとはずれだらけなコメントが参考になるといわれても。
全然同じじゃないです。
同じです。WoSignと同様にサブドメイン管理者が親ドメインのSSL証明書を取得できることに問題があるという指摘ですが、理解できていますか？TXTレコードでドメイン所有権を確認することは一般的ですが、サブドメインのTXTレコードで親ドメインの所有権を確認するのは、一般的ではありません。
ACMEなんて、Let's Encryptのために作られたもので実績も何もないです。それを「問題ないと思います」といわれても、実際に問題があるでしょ、としかいえません。
HTTP [ietf.org]とかSMTPとかでは使えない
使えます。 [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のために作られたもので実績も何もないです。 それを「問題ないと思います」といわれても、実際に問題があるでしょ、としかいえません。
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レコードの対象アプリケーションを指定するラベルというものが存在しないので、サブドメイン名をラベルのように使うのは現状ではやむを得ないでしょう。
ふーむ、DNSへの追加とはいえ、ちょっと気になりますね
「サブドメイン管理者が」ではなくて「親ドメインに任意のサブドメインを追加できる人」または「サブドメイン管理者で共用DNSに攻撃が可能な人」じゃないのかな
別ACですが、すごく怒っているのは伝わってくるんだけど・・・
> ユーザーが自由にサブドメインを作れるサービス（レンタルサーバとかレンタルブログとか）で、> 「_acme-challenge.example.com」のようにサブドメイン名にアンダースコアが使えるような> サービスは見たことがないので実害も無いでしょう。
これに、反論しないとあまり意味が無いような気もしますがそういうサービスが有るという主張をされているのでしょうか？であれば、実例を上げてほしいですね。# ってか、ホスト名に「＿」っていつの間に使って良くなったんだっけ？
Let's Encryptは、
・親ドメインに任意のサブドメインを追加できる
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
一方で、Firefox は Let's Encrypt を信頼済みルートCAへ追加 (スコア:3)
Mozilla が Let's Encrypt Root を認証局として信頼 [letsencrypt.jp] によると、Firefox 50 以降では、Let's Encrypt が Firefox の信頼されたルート証明機関に含まれるようになります。
今までは、Let's Encrypt は、IdenTrust Root からチェーンされていたことで信頼済みとして扱われていたわけですが、これからは独立した認証局として信頼済みとなります。
無料でTLS証明書を発行している中国のCA「WoSign」をブロックする一方で、同じく無料でTLS証明書
Re: (スコア:1)
Let's Encryptも同じ問題を抱えているという指摘 [ya.maya.st]もあるため、これが事実ならば信頼済みに入れて欲しくないですね。
Let's Encrypt、というよりACMEプロトコルの仕様は問題ないと思う (スコア:5, 参考になる)
全然同じじゃないです。中国最大級の認証局「WoSign」がニセの証明書を発行していたことが判明 [gigazine.net]によると「WoSign」の件は「脆弱性」です。一方、「DNSレコードに認証用のレコードを追加」することでドメイン所有者と認証されるのはACME プロトコルの仕様です。認証の仕組みの概要についてはLet's Encrypt の仕組み [letsencrypt.jp]をご覧ください。
そもそも、ACMEプロトコルの認証用レコードに「_」が含まれているのは、セキュリティ上の理由です。DNSにはアンダースコア付きのレコードが登録できる [ietf.org]けど、HTTP [ietf.org]とかSMTPとかでは使えないので、ホスティングサービスにお
Re:Let's Encrypt、というよりACMEプロトコルの仕様は問題ないと思う (スコア:2, 参考になる)
ここまで間違い・まとはずれだらけなコメントが参考になるといわれても。
全然同じじゃないです。
同じです。
WoSignと同様にサブドメイン管理者が親ドメインのSSL証明書を取得できることに問題があるという指摘ですが、理解できていますか？
TXTレコードでドメイン所有権を確認することは一般的ですが、サブドメインのTXTレコードで親ドメインの所有権を確認するのは、一般的ではありません。
ACMEなんて、Let's Encryptのために作られたもので実績も何もないです。
それを「問題ないと思います」といわれても、実際に問題があるでしょ、としかいえません。
HTTP [ietf.org]とかSMTPとかでは使えない
使えます。 [ietf.org]
Re:Let's Encrypt、というよりACMEプロトコルの仕様は問題ないと思う (スコア:2)
ご指摘ありがとうございます。
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] に、
と、ホスト名にはアンダースコアが使えないとありました。しかし、RFC 952 も古いので、新しいインターネットにおけるホスト名の要件が定義された RFC 1123 を確認したところ、ホスト名に使える文字は増えたものの（先頭に数字も使えるようになった）、アンダースコアが使えないのは同じでした。
新しい HTTP/1.1 の仕様（参照先RFC 3986は URI の仕様）では確かにホスト名にアンダースコアは使えるけど、インターネット上のホスト名にはアンダースコアは使えない（[RFC 1123 ]Requirements for Internet Hosts -- Application and Support [ietf.org]）ので、アンダースコアを含むホスト名の使用はイントラネットやローカルなどでの使用に限定されるようです。
「サブドメインの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レコードの対象アプリケーションを指定するラベルというものが存在しないので、サブドメイン名をラベルのように使うのは現状ではやむを得ないでしょう。
Re:Let's Encrypt、というよりACMEプロトコルの仕様は問題ないと思う (スコア:1)
ふーむ、DNSへの追加とはいえ、ちょっと気になりますね
M-FalconSky (暑いか寒い)
Re: (スコア:0)
「サブドメイン管理者が」ではなくて
「親ドメインに任意のサブドメインを追加できる人」または「サブドメイン管理者で共用DNSに攻撃が可能な人」じゃないのかな
Re: (スコア:0)
別ACですが、すごく怒っているのは伝わってくるんだけど・・・
> ユーザーが自由にサブドメインを作れるサービス（レンタルサーバとかレンタルブログとか）で、
> 「_acme-challenge.example.com」のようにサブドメイン名にアンダースコアが使えるような
> サービスは見たことがないので実害も無いでしょう。
これに、反論しないとあまり意味が無いような気もしますが
そういうサービスが有るという主張をされているのでしょうか？
であれば、実例を上げてほしいですね。
# ってか、ホスト名に「＿」っていつの間に使って良くなったんだっけ？
Let's Encryptは、
・親ドメインに任意のサブドメインを追加できる