SSL.com は、すべてのお客様と訪問者が幸せで安全、健康的なホリデー シーズンを過ごし、2021 年が豊かな年になることを願っています。 新年が少しでも少ない年になることを祈りますが、うーん…。 興味深い 2020 年は、いろいろな意味で大変な年でしたが、ネットワーク セキュリティ、デジタル証明書、およびセキュリティの世界から重要なニュースを聞かない月はないだろう。 PKI.
OpenSSL の DoS 脆弱性
この問題については、次の記事で取り上げました。 ブログ投稿 今月初めに述べましたが、繰り返す価値があります。重大度の高い脆弱性 OpenSSLの OpenSSL 1.0.2 および 1.1.1i より前のすべてのバージョンに影響を与える問題が発見されました。この脆弱性が悪用されて、サービス拒否 (DoS) 攻撃が行われる可能性があります。 OpenSSL 1.1.1i8 年 2020 月 XNUMX 日にリリースされた、修正が含まれています。
OpenSSL ユーザーは、できるだけ早くインストールを更新する必要があります。修正を適用するには XNUMX つのパスがあります。
- OpenSSL 1.1.1のユーザーおよびサポートされていない1.0.2ユーザーは、1.1.1iにアップグレードする必要があります。
- OpenSSL 1.0.2のプレミアムサポートのお客様は、1.0.2xにアップグレードする必要があります。
OpenSSL は現在、ほとんどの HTTPS Web サーバーにインストールされています。この脆弱性について詳しくは、SSL.com の Web サイトをご覧ください。 blog、および OpenSSL プロジェクトの セキュリティアドバイザリ.
Cloudflareは新しいプライバシープロトコルを提唱
ティム·アンダーソン 報告 The Register では、Cloudflare が「『プライバシーを尊重したインターネット』を可能にするという新しいインターネット プロトコルの採用を推進している」と報じられています。これらのプロトコルにはプライバシーを強化したプロトコルが含まれています。 DNS over HTTPS（DoH）、追加の暗号化 TLS 握手、ユーザーパスワードの処理に関するセキュリティの向上。
忘却のDoH
DNS over HTTPS（DoH） これまで平文として送信されてきた DNS クエリと応答を暗号化することで、インターネット プライバシーの脆弱な部分に対処します。 オブリビアス DoH (ODoH) DoH サーバーがクライアントの IP アドレスを認識できないようにすることで、DNS プライバシー保護をさらに一歩進めます。
ODoH の本質は、クライアントと DoH サーバーの間にネットワーク プロキシを導入することです。プロキシは DNS クエリを認識できず、DoH サーバーのみが読み取ることができます。サーバーはクライアントの IP アドレスを知りません。プロキシとサーバーが共謀していない限り、クエリは非公開です。
Cloudflareはすでに、Cloudflare、Apple、Fastlyのエンジニアによって開発されたODoHのサポートを宣言しています。チェックアウトするとさらに詳しく知ることができます 彼らの論文 arxiv.org で。
暗号化されたクライアント こんにちは (ECH)
暗号化されたクライアント こんにちは (ECH) 強化されたハンドシェイク暗号化を提供します TLS、超えて 暗号化された SNI (ESNI)、サーバー名表示 (SNI) のみを保護します。 TLS 握手。 Cloudflareの研究エンジニア、クリストファー・パットン 書き込み,
ESNI は大きく前進しましたが、完全なハンドシェイク暗号化を達成するという目標には達していません。不完全であること（SNI を保護するだけであること）のほかに、次のような脆弱性があります。 いくつかの高度な攻撃これは、実現するのは難しいものの、対処する必要があるプロトコル設計の理論上の弱点を示しています。
...
ECH の最終的な目標は、次のことを保証することです。 TLS 同じ ECH サービス プロバイダーの背後にある異なるオリジン サーバーに対して行われた接続は、相互に区別できません。
当然のことながら、ECH は「DoH と並んで、CDN (コンテンツ配信ネットワーク) のコンテキストでのみ完全に意味をなす」ため、Cloudflare は「自身を ECH プロバイダーになる可能性が高いと考えています」。 ECH について詳しくは、IETF をご覧ください。 提案案.
不透明なパスワード
OPAQUE パスワード (Oblivious Pseudo-Random Function (OPRF) と Password Authenticated Key Exchange (PAKE) を組み合わせたもじり) は、ユーザーのパスワードがサーバーに転送されるのを完全に回避するメカニズムです。 OPAQUE は、「サーバーとクライアントが共同でソルト付きハッシュを計算し、中間の XNUMX 番目のソルトを使用して比較する」ことでこれを実現します。これにより、サーバーは認証中にユーザーのパスワードを知ることができなくなり、ユーザーもサーバーのシークレット ソルトを知ることがなくなります。」
OPAQUE パスワードについて詳しくは、以下をご覧ください。 本論文 [PDF リンク] カリフォルニア大学アーバイン校と IBM の研究者、および Cloudflare エンジニアの Tatiana Bradley 氏による ブログ投稿.
SolarWinds 攻撃に関連する可能性のある FTP 認証情報の漏洩
過去数週間を人里離れたオフグリッドの小屋で過ごしていない限り（今考えると悪い考えではありません）、おそらくすでにかなりの量のことを聞いているでしょう。 サプライチェーン攻撃 これにより、SolarWinds の Orion IT 監視ソフトウェアと政府および業界の多くのユーザーが侵害されました。ラヴィー・ラクシュマナンの16月XNUMX日 ストーリー Hacker News では、攻撃者がどのようにして「2019 年 XNUMX 月には SolarWinds Orion プラットフォームのソフトウェア ビルドとコード署名インフラストラクチャを侵害し、ソフトウェア リリース プロセスを通じて悪意のあるバックドアを配布した可能性が高い」と論じています。
そのアイデアは…ビルド システムを侵害し、ソフトウェアのソース コードに独自のコードを静かに挿入し、企業がコンパイルしてパッケージに署名するのを待ち、最後に、新しくリリースされた更新プログラムに変更が期待どおりに反映されるかどうかを確認することでした。
2019 年 XNUMX 月のタイムラインは、セキュリティ研究者の Vinoth Kumer のタイムラインと一致しています。 発見、2019 年 123 月、公開 GitHub リポジトリから Solarwinds の更新サーバーの平文 FTP 資格情報が漏洩し、このサーバーにはパスワード「solarwinds17」でアクセス可能だったことがわかりました。問題のリポジトリは「2018 年 XNUMX 月 XNUMX 日以来」一般に公開されており、攻撃者志望者が漏洩した認証情報を発見して悪用する十分な時間が与えられていました。
もちろん、SolarWinds がユーザーにセキュリティ対策を無効にするようアドバイスしたことも役に立ちませんでした。
さらに悪いことに、Orion ソフトウェア アップデートに追加された悪意のあるコードは、SolarWinds 独自の機能により、標的となったシステム上のウイルス対策ソフトウェアやその他のセキュリティ ツールによって気付かれなかった可能性があります。 サポート勧告、ファイル ディレクトリがウイルス対策スキャンとグループ ポリシー オブジェクト (GPO) の制限から免除されない限り、製品が正しく動作しない可能性があると記載されています。
