wget以外のカールにソフトウェア.download.prss.microsoft.comの信頼問題があるのはなぜですか?

wget以外のカールにソフトウェア.download.prss.microsoft.comの信頼問題があるのはなぜですか?

次の URL は microsoft.com サブドメインにリダイレクトされます。https://tb.rg-adguard.net/dl.php?go=3dd1ce66 つまり、https://software.download.prss.microsoft.com/db/Win10_20H2_v2_EnglishInternational_x64.iso?t=......任意のトークンで)

以下を実行して最終リダイレクトURLを取得できます。

curl -LsI -o /dev/null -w %{url_effective} "https://tb.rg-adguard.net/dl.php?go=7e583fea

しかし、私が走っても何でも構いwget https://tb.rg-adguard.net/dl.php?go=3dd1ce66ません。wget https://software.download.prss.microsoft.com/db/Win10_20H2_v2_EnglishInternational_x64.iso?t=...................

Firefoxを使用してファイルをダウンロードすると、証明書エラーが発生し続けます。

wget https://software.download.prss.microsoft.com/db/Win10_20H2_v2_EnglishInternational_x64.iso\?t\=...................
--2022-04-12 14:57:29--  https://software.download.prss.microsoft.com/db/Win10_20H2_v2_EnglishInternational_x64.iso?t=..........................
Resolving software.download.prss.microsoft.com (software.download.prss.microsoft.com)... 152.199.21.175, 2606:2800:233:1cb7:261b:1f9c:2074:3c
Connecting to software.download.prss.microsoft.com (software.download.prss.microsoft.com)|152.199.21.175|:443... connected.
ERROR: The certificate of ‘software.download.prss.microsoft.com’ is not trusted.

異なるアプリケーション(Firefoxとwget)が一貫して動作しないのはなぜですか?実際に証明書を信頼しない理由はありますか(もしFirefoxが証明書を認識しないのはなぜですか)、またはwgetに問題がありますか?

私はFedora 35 x64、Wget 1.21.2、およびFirefox 98.0を使用しています。

ベストアンサー1

何が壊れたの?

次の既知の問題を発見したようです。https://github.com/dotnet/core/issues/6830最後のコメントはこんな感じです。

OneOCSPのアップデート:新しいCABフォーラムの要件により、OneOCSPは2022年5月31日より前にアルゴリズムをSHA-256に切り替えます。

質問によると(GnuTLS)は、OCSP URLがあり、oneocsp.microsoft.comがSHA1を使用して応答に署名する wgetため、Microsoft証明書の受け入れを拒否します。URI:http://oneocsp.microsoft.com/ocspSHA1の価値が下落しましたそして署名には使用しないことをお勧めします。

確かにwgetはユーザーを安全に保護することで正しいことをします。 SHA1は長年安全ではないと考えられており、証明書への署名は何年もサポートされていません。

実際、この問題がより早く発見され解決されなかったことは非常に驚くべきことです。しかし、OCSPはx509証明書自体よりもユーザーにとってあまり目立っていないようです。

これがなぜ問題になるのですか?

OCSP有効期限前の証明書失効の問題を解決します。証明書には、サーバーを指すOCSP URLを含めることができます。クライアントはそれを読み取り、サーバーに証明書がまだ有効でキャンセルされていないことを確認するように要求します。

サーバーは証明書が有効であることを示すために応答に署名し、応答はすぐに(秒または分単位で)期限切れになります。したがって、証明書自体が有効であっても、それを確認するためにOCSPサーバーが続行する必要があります。

ただし、MicrosoftのOCSPサーバーはパフォーマンスが悪いです。

デジタル署名は実際に文書のデジタル指紋に署名するものであり、SHA1は以前に指紋を生成するために使用されてきた。しかし、人々は既存のSHA1指紋と一致する新しい文書を作成する方法を見つけました。これにより、既存の署名と一致するように見える文書を偽造することができます。

したがって、GNUTLS は Microsoft OCSP サーバーの SHA1 署名応答を信頼しないため、一部の Microsoft 証明書の信頼を拒否します。したがって、証明書自体が失効したかどうかを確認する方法はありません。

私の作品を見せて...

opensslを使用して証明書のOCSP URLを確認できました。まず証明書を入手してください。

openssl s_client -showcerts -servername software.download.prss.microsoft.com -connect software.download.prss.microsoft.com:443 </dev/null

次に、証明書をファイルにコピーして貼り付け、次のように読みます。

openssl x509 -in <filename> -text

帽子の問題を解決するためにGoogleがどのように案内したのか疑問に思った場合:

wgetgnutlsデバッグオプションを有効にしてこれを実行しました。

GNUTLS_DEBUG_LEVEL=2 wget --verbose https://tb.rg-adguard.net/dl.php?go=3dd1ce66

これは本物長いデバッグ出力は最終的に次のようになります。

gnutls[2]: looking for key purpose '1.3.6.1.5.5.7.3.1', but have '1.3.6.1.5.5.7.3.4'
ERROR: The certificate of ‘software.download.prss.microsoft.com’ is not trusted.

このエラーは誤解を招く可能性がありますが、Googleを引き続き使用するためのより多くの情報を提供しました。

おすすめ記事