SSLレコードをDNSレコードに格納する
すべての認証局とすべての特別な種類のSSL証明書（拡張検証など）を削除せず、SSLを必要とするすべての人に、独自の自己署名SSL証明書を作成してDNSレコードに保存することを要求しないのはなぜですか。
それは、サードパーティの認証局とDNSSECの両方に信頼を置く必要があるのではないでしょうか。また、自己署名証明書を使用するときにブラウザから提供されるセキュリティ警告を削除することもできます。つまり、DNSが汚染されていない限り、問題は発生しません。また、DNSに関しては、非常に多くの選択肢があります。一般的なブラウザによって信頼されている認証局に関しては、あなたが持っていないプロバイダー。
すべての認証局とすべての特別な種類のSSL証明書（拡張検証など）を削除せず、SSLを必要とするすべての人に、独自の自己署名SSL証明書を作成してDNSレコードに保存することを要求しないのはなぜですか。
[〜＃〜] dane [〜＃〜] の標準さえあります。また、すでに一部のサイトで使用されていますが、現在は主にHTTPSではなくSMTPSに使用されています。
ただし、DNSルックアップがスプーフィングされないようにするためにDNSSecが必要です。それ以外の場合、中間者攻撃者は、DNSルックアップ内に独自の証明書を送信する可能性があります。残念ながら、現時点ではDNSSecは広く使用されていないため、現時点では、確立されたPKI構造を使用する必要があります。
しかし、DNSSecが十分に深く導入されると、DANEは有望なテクノロジーであり、それを使用して独自の自己署名証明書を使用するか、従来のCAベースの証明書で追加の信頼パスを使用できます。
CAと同じくらい多くの問題について、DNSはSSL CAよりも信頼性が大幅に低くなっています。 SSLは、リモートサーバーのIDを確認することによってDNSが改ざんされているときにユーザーを保護できるツールの1つです。証明書をDNSに移動した場合（DNSSECを使用せずにDNS応答の信頼性を検証しない場合）、DNSを所有している誰かに、検出する方法なしに接続全体を所有する権限を与えたことになります。 DNSSECについて説明しましたが、DNSSECなしで証明書を実行したいようですが、これは失敗する運命にあります。
DNSの改ざんは簡単です。
1日の終わりに、私と同じネットワーク上にいて、トラフィックを受動的に見ることができれば、MITMを実行しなくても、DNS応答を改ざんすることができます。 DNSは通常UDPを使用するので、リクエストを確認すると、正当なサーバーと「競合」して応答を返すことができます。再帰的な検索が必要な場合、またはOpenDNSやGoogleパブリックDNSのためにインターネットに出かける場合は、ほぼ確実にレースに勝って偽の応答を挿入します。