アカウント名:
パスワード:
証明書いらない暗号通信のプロトコルをさ
確かに接続毎に証明書を送って、ルート証明書で中間証明書を検証し、中間証明書でサーバ証明書を検証し、とかコストが大きいし、証明書不用になればうれしいですね。しかも証明書を簡単に差し替えられないから（特にルート証明書）、長年にわたってセキュリティを確保するために 2048bit とか 4096bit とか、ずんずん大きくなって行きますし。
組織を証明しなければならないときとかには EV SSL 証明書などが必須ですが、そうでないとき、つまりドメイン名の示す相手と暗号通信できれば良い、ということであれば、公開鍵を DNS に公開するぐらいで SSL 証明
別案としては検証用の fingerprint データを DNS に公開するという手もあります。
たとえば anonymous SSH とかで、サーバ側の fingerprint を DNS で検証できるだけでも良いかもしれません。
いずれにせよ DNS のセキュリティ確保は必須で、DNSSEC も避けては通れない、というのが前提です。
>いずれにせよ DNS のセキュリティ確保は必須で、DNSSEC も避けては通れない、というのが前提です。
キャリアグレードで言えば、最終的なエンドユーザー向けのDNSはキャッシュDNSでDNSSECは非対応、というのが今後も続く相場ですよ。
というのも、DNSSECで検証されると児童ポルノのブロックなど社会的に必要とされている機能群の一部が働かなくなる(「児童ポルノなど有害コンテンツを配信するサイトにも"正しく"送り届けようとしてしまう)上に、キャリアは(上流に別途DNSSEC対応のDNSを立ててそこと階層化するなどして)該当キャッシュDNS自体を含めて網の中でキャッシュポイズニング対策などは可能であるからです。
なにを主張されたいのかが良くわかりませんが、キャッシュ・エンドユーザ間で DNSSEC なしであっても、ISP 内なり自組織内なりで DNS のセキュリティが確保できているのであれば、DNS 上に公開鍵なり fingerprint なりを公開して接続相手を検証するというアイディアは同程度にセキュリティを確保できるはずです。それが充分かどうかは状況次第ですし、もともと SSL 証明書を置き換えるアイディアではないので。
個人的には公衆無線 LAN とか危ない回線が増えて行く以上、DNSSEC 等の DNS セキュリティ確保がエンドユーザまであるべきだと考えていますが、証明書なしで暗号通信をという話とは
>DNSSEC は成り済ましを検出できるわけで、>「成り済まされなかった場合」の結果を得ることはできません。
実際には、さまざまなDNS関連製品のDNSSECの実装の多くの部分に「DNSSECの検証をしてみてダメなら自前で解決を図ってみる(=ブロックが効かない)」という挙動が含まれています。これらがそこかしこにあるため、結果として「DNSSECを有効にするとブロックが効かなくなる」と判断せざるを得ないケースが多くあります。
ここについては、もはや仕様上の優先順位として「DNSSECに対応した問い合わせが確実に正しい結果を返すべき」と「ローカルに配置されたDNS管理者はそれすら上書できるべきか」の競合であり、多くのDNS関連製品は上記を優先しているということになります。
実際問題として、後者はあなたの表現で言う「なりすまし」にほかなりませんので自分としては上記「DNSSEC側を優先する」には一定の理解をもっています。その結果として、前述したような「キャリア網上流にDNSSEC対応のDNSを設置して情報の正当性検証はそこが担う、 エンドユーザーに提供するDNSはそれにぶら下げるキャッシュ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)
>いずれにせよ DNS のセキュリティ確保は必須で、DNSSEC も避けては通れない、というのが前提です。
キャリアグレードで言えば、
最終的なエンドユーザー向けのDNSはキャッシュDNSでDNSSECは非対応、
というのが今後も続く相場ですよ。
というのも、DNSSECで検証されると
児童ポルノのブロックなど社会的に必要とされている機能群の一部が働かなくなる
(「児童ポルノなど有害コンテンツを配信するサイトにも"正しく"送り届けようとしてしまう)
上に、
キャリアは(上流に別途DNSSEC対応のDNSを立ててそこと階層化するなどして)
該当キャッシュDNS自体を含めて
網の中でキャッシュポイズニング対策などは可能であるからです。
Re: (スコア:3)
なにを主張されたいのかが良くわかりませんが、キャッシュ・エンドユーザ間で DNSSEC なしであっても、ISP 内なり自組織内なりで DNS のセキュリティが確保できているのであれば、DNS 上に公開鍵なり fingerprint なりを公開して接続相手を検証するというアイディアは同程度にセキュリティを確保できるはずです。それが充分かどうかは状況次第ですし、もともと SSL 証明書を置き換えるアイディアではないので。
個人的には公衆無線 LAN とか危ない回線が増えて行く以上、DNSSEC 等の DNS セキュリティ確保がエンドユーザまであるべきだと考えていますが、証明書なしで暗号通信をという話とは
Re:いい加減誰か作ってよ (スコア:0)
>DNSSEC は成り済ましを検出できるわけで、
>「成り済まされなかった場合」の結果を得ることはできません。
実際には、さまざまなDNS関連製品のDNSSECの実装の多くの部分に
「DNSSECの検証をしてみてダメなら自前で解決を図ってみる(=ブロックが効かない)」
という挙動が含まれています。
これらがそこかしこにあるため、結果として
「DNSSECを有効にするとブロックが効かなくなる」と判断せざるを得ないケースが多くあります。
ここについては、もはや仕様上の優先順位として
「DNSSECに対応した問い合わせが確実に正しい結果を返すべき」と
「ローカルに配置されたDNS管理者はそれすら上書できるべきか」の競合であり、
多くのDNS関連製品は上記を優先しているということになります。
実際問題として、後者はあなたの表現で言う「なりすまし」にほかなりませんので
自分としては上記「DNSSEC側を優先する」には一定の理解をもっています。
その結果として、前述したような
「キャリア網上流にDNSSEC対応のDNSを設置して情報の正当性検証はそこが担う、
エンドユーザーに提供するDNSはそれにぶら下げるキャッシュDNSでDNSSEC非対応にする」
につながるわけです。