RFC4255（SSHFP）がhttpsに使用されないのはなぜですか？
私は数時間前にこのアイデアを思いつきましたが、もちろんそれはすでに存在し、 RFC ...さえあります.
SSL/TLS証明書のフィンガープリントをDNS経由で公開しないのはなぜですか？答えが正当であることを確認するためにDNSSECが必要であり、ネームサーバーが安全な環境にあることを確認する必要がありますが、SSL/TLSにはまだ問題がないことがわかります。
この変更により、認証局（CA）からDNSネームサーバーにすべての暗号化されたトラフィックを保護するための権限が移動します。その場合、すべてのDNSプロバイダー（DNSSECを持つ）はCAのように非常に高いセキュリティ環境になるはずなので、これは問題になる可能性があります。しかし、すべてのネームサーバーがすでにこれである必要はありませんか？ほとんどのウェブサイトは機密トラフィックにプレーンhttpを使用しており、ほとんどの人はGoogleにログインするときに南京錠がなくても気付かないでしょう。彼らはすでに大きな責任を負っていると思います。
ドメインのネームサーバーを信頼しない場合は、代わりにルートサーバーにフィンガープリントを含めることができますが、どれほどの負荷がかかるかはわかりません。
もう1つの問題は、DNSSECがまだそれほど広く実装されていないことです。しかし、私の質問の理由は、IETFが「展開を容易にするために」証明書の検証を要求せずにhttp/2.0での暗号化をサポートすることを検討しているためです。
私の意見では、セキュリティは正しく行われるべきであるか、まったく行われないべきです。人々に誤った安心感を与えないでください。しかし、とにかくプロトコルを変更する（すべてのWebサーバーをアップグレードする）場合は、DNSSECを実装し、これを正しい（認証された）方法で行うこともできます。
要するに問題/変更：
- 大量のCAではなく、（ルート？）ネームサーバーを信頼する必要があります。
- dnsレコードタイプを追加するか、sshfpレコードの使用を拡張する必要があります。そして
- dnssecをより広くサポートする必要があります。
何か不足していますか？証明書のフィンガープリントを認証されたチャネルで公開するだけでよいのに、SSL/TLS証明書に最高額を支払うのはなぜですか？
Http 2.0での認証されていない暗号化のポイントは、他の構成をまったく変更する必要なく暗号化を有効にすることを奨励することです。これは不必要に遅く（鍵交換のための別の往復であり、これは特に海外やパケットの損失が悪いため）、セキュリティをほとんど追加できないため、これには反対です。それは誤った安心感を与えることさえあります。良い面としては、トラフィックを難読化します。
DNSを使用するこの提案により、Webサーバーに暗号化を実装する作業が多少増えますが、暗号化の広範な可用性を非常に高く維持しながら（通常は）、SSL/TLSと同じくらい安全になります（私は彼らが保持するとは思わない）証明書で行うように、sshfp/httpfp/tlsfp対応のネームサーバーの途方もなく高い価格を引き上げます）。認証されていない暗号化は、他のすべてのオプション（署名付き証明書、保存された証明書、安全に公開された指紋）が利用できない場合でも最後の手段となる可能性があります（ただし、完全に誤ったセキュリティを提供するため、ユーザーには表示しないでください）。減速するだけの価値があるかどうかはわかりません。
これにルートサーバーを使用できない場合は、ドメインのネームサーバーを「合理的に安全な環境」（通常の南京錠）として使用し、EVのCA署名付き証明書（緑色のバー）を使用することもできます。次に、オンラインバンキングをしているときに、緑色のバーを探すように伝えます。ネームサーバーはすでにかなり大きな責任を負っています。そのため、CAほど安全であるとは期待できない場合でも、十分安全である可能性があります。少なくとも、はるかに柔軟なシステムになります。手頃な価格の証明書の場合、ドメインと1つのサブドメインに制限されています（サブドメインは既に「www。」で占められています）。
簡単にもう一度私の質問：httpsにSSHFPのようなシステムを使用しない理由はありますかif DNSSECは広く利用可能でしたか？
そのためのRFC があります。これは、DNSSECが行うことの意図の一部です。
ここで、「トップドル」またはその削減についてあまり期待しないでください。サーバー名に関して何らかの方法で公開鍵を「認証」する必要性は、DNSSECに切り替えることによって魔法のように取り除かれません。 「CA」の役割は移動しただけで、関連するコストはまだ残っています。レジストラがこれらのコストを想定しなければならない場合、それらの価格は上昇することが予測できます。遅かれ早かれ、誰かが代金を支払わなければならなくなり、SSLサーバーの所有者になるのではないかと私は強く疑っています。
哲学的に、認証構造（PKI）と名前付け構造（DNS）をマージすることが良いアイデアかどうかは不明です。ホスト名にバインドされた証明書を発行する特定のケースを処理する場合、マージによりDNSとPKI間の通信が確実に簡素化されます。しかし、これは2つの責任が絡み合うことも意味します。優れたレジストラである誰もが優れたCAであると信じるには、かなりの希望的な考えが必要です。 2種類のアクティビティは、漠然と似ていますが、同一ではありません。
また、証明書はHTTPSサーバーを超えるスコープを持つことが想定されています。これらは、たとえばソフトウェア（アプリケーション、ドライバー...）に署名するときなど、DNSおよびホスト名とはまったく関係のないコンテキストで使用できます。
経済的に、それはあまり変わりません。商用CAの中で最も使用されているのはVeriSign（別名Symantec）です。 DNSSECに切り替えると、最終的な証明機関はVeriSignではなくなりますが、ルートDNSのほとんどを管理する人、つまりVeriSignになります。それが変更になるでしょうね。
Politically、「state CA」に問題があります。 Windowsシステムによってデフォルトで信頼されている数十のCAの多くは、「バニティCA」がスポンサーであるか、さまざまな政府によって運営されています。同じ政府が、より多くの帯域幅と可用性を必要とするDNS関連のインフラストラクチャを運用する意図はありません。そして、彼らは彼らのprecioouuss証明書が「二流市民」になるのを見て憤慨するでしょう。
セキュリティの場合、これはほとんど問題ではありません。偽の証明書イベントは非常にまれです。そのような発生が年に1回あると聞いています。インターネット関連の詐欺やフィッシングなどの攻撃の大部分は、既存のCAをだますことに依存していません。つまり、現在のCAシステムは機能します。壊れていないものは直さないでください。ええ、CAシステムは壊れやすく、故障しやすい傾向がありますが、時折の違反について多くの宣伝がなされているにもかかわらず、生の事実はそれが生き残っているということです。
概要：標準の準備が整い、RFCが公開され、ソフトウェアが作成されます。今欠けているのは、「商用CA X.509」の世界から「商用レジストラDNSSEC」の世界に切り替える理由だけです。それが実際に何をするのかわかりません。
CERT RRは非推奨になりました。 DNSに公開鍵素材を入れるための現在の提案はDANEと呼ばれます。彼らは RFC 6698 のドキュメントであるTLSAレコードタイプを定義しています。これにより、ドメイン管理者は特定の証明書、または特定のサービスのCAをアサートできます。
それは存在します-それはDANEと呼ばれます- http://tools.ietf.org/html/rfc6698 （CERT RFCは何の牽引力も持っていないので、理由はわかりません）。
レコードを生成するには、これを使用できます。
https://github.com/pieterlexis/swede
このFirefoxプラグインはそれらを検証できます：
残念ながら完全ではありません。
証明書パトロールチームには、更新されたプラグインがあります。
https://labs.nic.cz/page/1207/dane-patrol/
しかし、それも機能しないようです:(
chromeサポートは書かれていますが公開されていません。TLSAが重要な場合は、Adamにメールを送信してください。）：
https://www.imperialviolet.org/2012/10/20/dane-stapled-certificates.html
TLSAは証明書を検証できるだけでなく、サイト所有者が自分のサイトで使用されている証明書は特定のCAによってのみ署名されることを主張できることに注意してください。これにより、不正/ハッキングされたCAの問題を解決できます。残り。
CA（またはCAの関連会社、CAの子会社など）は、任意のドメインの証明書に署名できることに注意してください。 CAエコシステムを安全にするにはeveryCAを安全にする必要があります！