Let's Encrypt は別のサブネットを使用した検証に切り替えます

非営利認証センター 暗号化しよう、コミュニティによって管理され、誰にでも無料で証明書を提供します。 объявил ドメインの証明書を取得する権限を確認するための新しいスキームの導入について。 テストで使用される「/.well-known/acme-challenge/」ディレクトリをホストするサーバーへの接続は、異なるデータセンターにあり、異なる自律システムに属する 4 つの異なる IP アドレスから送信されるいくつかの HTTP リクエストを使用して実行されます。 異なる IP からの 3 つのリクエストのうち少なくとも 4 つが成功した場合にのみ、チェックは成功したとみなされます。

複数のサブネットからチェックすることで、BGP を使用した架空のルートの置換を通じてトラフィックをリダイレクトする標的型攻撃を実行し、外部ドメインの証明書を取得するリスクを最小限に抑えることができます。 マルチポジション検証システムを使用する場合、攻撃者は、異なるアップリンクを持つプロバイダーの複数の自律システムのルート リダイレクトを同時に実現する必要がありますが、これは単一のルートをリダイレクトするよりもはるかに困難です。 異なる IP からリクエストを送信すると、単一の Let's Encrypt ホストがブロック リストに含まれている場合のチェックの信頼性も高まります (たとえば、ロシア連邦では、letsencrypt.org の一部の IP が Roskomnadzor によってブロックされました)。

1 月 3 日までは、ホストが他のサブネットからアクセスできない場合に、プライマリ データ センターからの検証が成功した場合に証明書の生成を許可する移行期間が設けられます (たとえば、ファイアウォールのホスト管理者が他のサブネットからのリクエストのみを許可している場合にこれが発生する可能性があります)。メインの Let's Encrypt データ センター、または DNS のゾーン同期違反が原因です)。 ログに基づいて、追加の XNUMX つのデータセンターからの検証に問題があるドメインのホワイト リストが作成されます。 連絡先情報が完了したドメインのみがホワイト リストに含まれます。 ドメインがホワイト リストに自動的に含まれない場合は、プレミスの申請を次の方法で送信することもできます。 特別なフォーム.

現在、Let's Encrypt プロジェクトは 113 億 190 万の証明書を発行し、約 150 億 61 万のドメインをカバーしています (81 年前は 77 億 69 万のドメインがカバーされ、91 年前は XNUMX 万のドメインがカバーされました)。 Firefox Telemetry サービスの統計によると、HTTPS 経由のページ リクエストの世界シェアは XNUMX% (XNUMX 年前は XNUMX%、XNUMX 年前は XNUMX%)、米国では XNUMX% です。

さらに、注目できるのは、 意図 りんご
有効期限が 398 日 (13 か月) を超える Safari ブラウザでの証明書の信頼を停止します。 この制限は、1 年 2020 月 1 日以降に発行される証明書にのみ導入される予定です。 825 月 2.2 日より前に受け取った有効期間が長い証明書の場合、信頼は保持されますが、XNUMX 日 (XNUMX 年) に制限されます。

この変更は、有効期間が最長 5 年と長い安価な証明書を販売する認証センターのビジネスに悪影響を与える可能性があります。 Apple によれば、このような証明書の生成はさらなるセキュリティ上の脅威を生み出し、新しい暗号標準の迅速な実装を妨げ、攻撃者が被害者のトラフィックを長期間にわたって制御したり、気付かないうちに証明書が漏洩した場合にフィッシングに使用したりする可能性があると述べています。ハッキングの結果。

出所: オープンネット.ru

コメントを追加します