アカウント名:
パスワード:
証明書いらない暗号通信のプロトコルをさ
確かに接続毎に証明書を送って、ルート証明書で中間証明書を検証し、中間証明書でサーバ証明書を検証し、とかコストが大きいし、証明書不用になればうれしいですね。しかも証明書を簡単に差し替えられないから（特にルート証明書）、長年にわたってセキュリティを確保するために 2048bit とか 4096bit とか、ずんずん大きくなって行きますし。
組織を証明しなければならないときとかには EV SSL 証明書などが必須ですが、そうでないとき、つまりドメイン名の示す相手と暗号通信できれば良い、ということであれば、公開鍵を DNS に公開するぐらいで SSL 証明
別案としては検証用の fingerprint データを DNS に公開するという手もあります。
たとえば anonymous SSH とかで、サーバ側の fingerprint を DNS で検証できるだけでも良いかもしれません。
いずれにせよ DNS のセキュリティ確保は必須で、DNSSEC も避けては通れない、というのが前提です。
いっそのことドメイン名の代わりにfingerprintを使えば
>いずれにせよ DNS のセキュリティ確保は必須で、DNSSEC も避けては通れない、というのが前提です。
キャリアグレードで言えば、最終的なエンドユーザー向けのDNSはキャッシュDNSでDNSSECは非対応、というのが今後も続く相場ですよ。
というのも、DNSSECで検証されると児童ポルノのブロックなど社会的に必要とされている機能群の一部が働かなくなる(「児童ポルノなど有害コンテンツを配信するサイトにも"正しく"送り届けようとしてしまう)上に、キャリアは(上流に別途DNSSEC対応のDNSを立ててそこと階層化するなどして)該当キャッシュDNS自体を含めて網の中でキャッシュポイズニング対策などは可能であるからです。
なにを主張されたいのかが良くわかりませんが、キャッシュ・エンドユーザ間で DNSSEC なしであっても、ISP 内なり自組織内なりで DNS のセキュリティが確保できているのであれば、DNS 上に公開鍵なり fingerprint なりを公開して接続相手を検証するというアイディアは同程度にセキュリティを確保できるはずです。それが充分かどうかは状況次第ですし、もともと SSL 証明書を置き換えるアイディアではないので。
個人的には公衆無線 LAN とか危ない回線が増えて行く以上、DNSSEC 等の DNS セキュリティ確保がエンドユーザまであるべきだと考えていますが、証明書なしで暗号通信をという話とは別問題でしょう。
あえてオフトピックに付き合うと、ISP の DNS がセキュリティ的に信用できなければ、（少なくとも現在の ISP の動向からすれば OP53B は無いので）クライアントにフルリゾルバを導入したり、または Google Public DNS 経由などでもクライアントでの検証は可能なように思います。
なお、
(「児童ポルノなど有害コンテンツを配信するサイトにも"正しく"送り届けようとしてしまう) 上に、
というくだりはおかしいように思います。DNSSEC は検証ができるだけなので、SSL 証明書が FQDN に合わないことを検出できたりするのと同様、「正しく」送り届けようという挙動は無いと理解しています。
DNSSEC は成り済ましを検出できるわけで、「成り済まされなかった場合」の結果を得ることはできません。ブロッキングはまさに成り済ましですから、エンドユーザまで DNSSEC を通しても、合法な（緊急避難？）成り済ましか悪意の成り済ましかが区別ができないだけです。
もっとも、ブロッキングするドメインについてのみ、DNSSEC 非対応に見せてフォワードするなりする方法もありそうですし、単に DNSSEC の検証を無視してブロッキング対象の A や AAAA を差し替えてもブロックされた旨を示すページが表示されないだけなので、少なくとも DNSSEC がそれほどブロッキングを阻害するようには思えません。
>DNSSEC は成り済ましを検出できるわけで、>「成り済まされなかった場合」の結果を得ることはできません。
実際には、さまざまなDNS関連製品のDNSSECの実装の多くの部分に「DNSSECの検証をしてみてダメなら自前で解決を図ってみる(=ブロックが効かない)」という挙動が含まれています。これらがそこかしこにあるため、結果として「DNSSECを有効にするとブロックが効かなくなる」と判断せざるを得ないケースが多くあります。
ここについては、もはや仕様上の優先順位として「DNSSECに対応した問い合わせが確実に正しい結果を返すべき」と「ローカルに配置されたDNS管理者はそれ
「児童ポルノのブロック」が、きちんとした規格のDNSSECで動かなくなるのは、なにかたまたま動くハックをしているせいだと思います。
これは次世代のガラパゴスの萌芽だと思います。
ガラパゴスの原因は、大量のたまたま動くハックであると思いますので。
将来を考えると、「児童ポルノのブロック」を絶対の要件とするのはヤバイかも知れません。
ガラパゴスと言いたいだけの無知な学生が暴れてる、まで読んだ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
いい加減誰か作ってよ (スコア:1)
証明書いらない暗号通信のプロトコルをさ
Re: (スコア:5, 興味深い)
確かに接続毎に証明書を送って、ルート証明書で中間証明書を検証し、中間証明書でサーバ証明書を検証し、とかコストが大きいし、証明書不用になればうれしいですね。しかも証明書を簡単に差し替えられないから（特にルート証明書）、長年にわたってセキュリティを確保するために 2048bit とか 4096bit とか、ずんずん大きくなって行きますし。
組織を証明しなければならないときとかには EV SSL 証明書などが必須ですが、そうでないとき、つまりドメイン名の示す相手と暗号通信できれば良い、ということであれば、公開鍵を DNS に公開するぐらいで SSL 証明
Re:いい加減誰か作ってよ (スコア:4, 興味深い)
別案としては検証用の fingerprint データを DNS に公開するという手もあります。
たとえば anonymous SSH とかで、サーバ側の fingerprint を DNS で検証できるだけでも良いかもしれません。
いずれにせよ DNS のセキュリティ確保は必須で、DNSSEC も避けては通れない、というのが前提です。
Re: (スコア:0)
いっそのことドメイン名の代わりにfingerprintを使えば
Re: (スコア:0)
>いずれにせよ DNS のセキュリティ確保は必須で、DNSSEC も避けては通れない、というのが前提です。
キャリアグレードで言えば、
最終的なエンドユーザー向けのDNSはキャッシュDNSでDNSSECは非対応、
というのが今後も続く相場ですよ。
というのも、DNSSECで検証されると
児童ポルノのブロックなど社会的に必要とされている機能群の一部が働かなくなる
(「児童ポルノなど有害コンテンツを配信するサイトにも"正しく"送り届けようとしてしまう)
上に、
キャリアは(上流に別途DNSSEC対応のDNSを立ててそこと階層化するなどして)
該当キャッシュDNS自体を含めて
網の中でキャッシュポイズニング対策などは可能であるからです。
Re:いい加減誰か作ってよ (スコア:3)
なにを主張されたいのかが良くわかりませんが、キャッシュ・エンドユーザ間で DNSSEC なしであっても、ISP 内なり自組織内なりで DNS のセキュリティが確保できているのであれば、DNS 上に公開鍵なり fingerprint なりを公開して接続相手を検証するというアイディアは同程度にセキュリティを確保できるはずです。それが充分かどうかは状況次第ですし、もともと SSL 証明書を置き換えるアイディアではないので。
個人的には公衆無線 LAN とか危ない回線が増えて行く以上、DNSSEC 等の DNS セキュリティ確保がエンドユーザまであるべきだと考えていますが、証明書なしで暗号通信をという話とは別問題でしょう。
あえてオフトピックに付き合うと、ISP の DNS がセキュリティ的に信用できなければ、（少なくとも現在の ISP の動向からすれば OP53B は無いので）クライアントにフルリゾルバを導入したり、または Google Public DNS 経由などでもクライアントでの検証は可能なように思います。
なお、
というくだりはおかしいように思います。DNSSEC は検証ができるだけなので、SSL 証明書が FQDN に合わないことを検出できたりするのと同様、「正しく」送り届けようという挙動は無いと理解しています。
DNSSEC は成り済ましを検出できるわけで、「成り済まされなかった場合」の結果を得ることはできません。ブロッキングはまさに成り済ましですから、エンドユーザまで DNSSEC を通しても、合法な（緊急避難？）成り済ましか悪意の成り済ましかが区別ができないだけです。
もっとも、ブロッキングするドメインについてのみ、DNSSEC 非対応に見せてフォワードするなりする方法もありそうですし、単に DNSSEC の検証を無視してブロッキング対象の A や AAAA を差し替えてもブロックされた旨を示すページが表示されないだけなので、少なくとも DNSSEC がそれほどブロッキングを阻害するようには思えません。
Re: (スコア:0)
>DNSSEC は成り済ましを検出できるわけで、
>「成り済まされなかった場合」の結果を得ることはできません。
実際には、さまざまなDNS関連製品のDNSSECの実装の多くの部分に
「DNSSECの検証をしてみてダメなら自前で解決を図ってみる(=ブロックが効かない)」
という挙動が含まれています。
これらがそこかしこにあるため、結果として
「DNSSECを有効にするとブロックが効かなくなる」と判断せざるを得ないケースが多くあります。
ここについては、もはや仕様上の優先順位として
「DNSSECに対応した問い合わせが確実に正しい結果を返すべき」と
「ローカルに配置されたDNS管理者はそれ
Re: (スコア:0)
「児童ポルノのブロック」が、きちんとした規格のDNSSECで動かなくなる
のは、なにかたまたま動くハックをしているせいだと思います。
これは次世代のガラパゴスの萌芽だと思います。
ガラパゴスの原因は、大量のたまたま動くハックであると思いますので。
将来を考えると、「児童ポルノのブロック」を絶対の要件とするのは
ヤバイかも知れません。
Re: (スコア:0)
ガラパゴスと言いたいだけの無知な学生が暴れてる、まで読んだ。