6

QtWebkit(内部でQSslSocketを使用)を使用してwww.hotmail.comに接続すると、ログイン後に次のsslエラーが発生しました。

  1. ローカルで検索された証明書の発行者証明書が見つかりませんでした
  2. ルートCA証明書は、この目的では信頼されていません
  3. 証明書を確認できませんでした。

ログインする前にmail.yahoo.comで同じエラーが発生する可能性があります。これら2つのサーバーへの安全な接続により、SSLエラーが発生することがわかりました。

  1. https://gfx8.hotmail.com
  2. https://csc.beap.bc.yahoo.com

securesocketclientと呼ばれるQTに含まれている小さなsslデモプログラムがあります。この小さなクライアントを使用して上記の2つのサーバーのポート443に接続すると、同じエラーが発生する可能性があります。多くの開発システムでこの問題が発生しているため、これはQTのバグであると99%確信しています。Linux、Mac、WindowsのQTに影響します。これは、QT4.7.4からQT4.8.4までずっと影響します(以前のバージョンは試していません)。バグはopenssl0.9.8で再現されています。

一部の人々は、プリコンパイルされたQTバイナリでopenssl1.0.0を使用することでバグが修正されたと誤って主張する可能性があります。プリコンパイルされたQTバイナリはopenssl0.9.8ヘッダーファイルでコンパイルされるため、これは誤りです。openssl 0.9.8は、openssl1.0.0とバイナリ互換ではありません。あるバージョンのopensslでQTをコンパイルし、別のバージョンのopensslバイナリを使用すると、一部の構造体メンバーが誤って解釈されます。この結論に到達するために、QTとopensslソースコードに多くのステップアンドトレースを行いました。

hotmailとyahooemailは非常に人気のあるWebサイトであるため、このバグはQTのセキュリティの観点から深刻なバグだと思います。私はすでにそれをQTバグシステム(https://bugreports.qt.io/browse/QTBUG-23625)に報告しましたが、私の過去の経験に基づいて、いつディジアがそれを手に入れるのか疑問です。

このバグを修正する方法についての考えをお気軽に共有してください。私はignoreSslErrorsを呼び出す方法を知っており、問題がないふりをします。しかし、それはopensslの使用を意図した方法ではありません。


この問題に関するさらなる調査からのいくつかの更新。

https://gfx8.hotmail.comの証明書パスは次のとおりです。

  • ルートCA:Versign Class 3 Public Primary Certification Authority-G5
  • 中間CA:VersignClass3拡張検証SSLSGCCA
  • サーバー証明書:gfx-ecn.hotmail.com

ルートCAはWindows証明書ストアにあり、起動時に正しくロードされます。おそらくどういうわけかQTは中間証明書を取得しないと思います。以下に示すように、opensslコマンドラインプログラムを使用してテストを実行します。

openssl s_client -showcerts -connect gfx8.hotmail.com:443

出力は次のとおりです。

CONNECTED(000001AC)depth = 0 1.3.6.1.4.1.311.60.2.1.3 = US、1.3.6.1.4.1.311.60.2.1.2 =ワシントン、businessCategory =民間組織、serialNumber = 600413485、C = US、postalC ode = 98052、ST =ワシントン、L =レドモンド、ストリート= 1 Microsoft Way、O = Microso ft Corporation、OU = Windows Azure CDN、CN = gfx-ecn.hotmail.com

検証エラー:num = 20:ローカル発行者証明書を取得できません検証リターン:1

深さ=01.3.6.1.4.1.311.60.2.1.3 =米国、1.3.6.1.4.1.311.60.2.1.2 =ワシントン、ビジネスカテゴリ=民間組織、シリアル番号= 600413485、C =米国、郵便番号= 98052、 ST =ワシントン、L =レドモンド、ストリート= 1 Microsoft Way、O = Microso ft Corporation、OU = Windows Azure CDN、CN = gfx-ecn.hotmail.com

検証エラー:num = 27:証明書が信頼されていません検証リターン:1

深さ=01.3.6.1.4.1.311.60.2.1.3 =米国、1.3.6.1.4.1.311.60.2.1.2 =ワシントン、ビジネスカテゴリ=民間組織、シリアル番号= 600413485、C =米国、郵便番号= 98052、 ST =ワシントン、L =レドモンド、ストリート= 1 Microsoft Way、O = Microso ft Corporation、OU = Windows Azure CDN、CN = gfx-ecn.hotmail.com

エラーの検証:num = 21:最初の証明書を検証できませんreturn:1を検証します

証明書チェーン0秒:/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Washington/businessCategory=PrivateOrganization/serialNumber=600413485/C=US/postalCode=98052 / ST = Washington / L = Redmond / street = 1 Microsoft Way / O = Microsoft Corporation / OU = Windows Azure CDN / CN = gfx-ecn.hotmail.com i:/ C = US / O = VeriSign、Inc./OU = VeriSign Trust Network / OU = https://www.verisign.com/rpa(c)06 / CN = VeriSign Class 3 Extended Validation SSLSGCCAの利用規約

-----証明書の開始-----

MIIG0DCCBbigAwIBAgIQfRbsuTLd2GrmU38TPnVOCTANBgkqhkiG9w0BAQUFADCB vjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNjE4MDYGA1UEAxMv VmVyaVNpZ24gQ2xhc3MgMyBFeHRlbmRlZCBWYWxpZGF0aW9uIFNTTCBTR0MgQ0Ew HhcNMTIxMTA3MDAwMDAwWhcNMTQxMTA4MjM1OTU5WjCCAR0xEzARBgsrBgEEAYI3 PAIBAxMCVVMxGzAZBgsrBgEEAYI3PAIBAhMKV2FzaGluZ3RvbjEdMBsGA1UEDxMU UHJpdmF0ZSBPcmdhbml6YXRpb24xEjAQBgNVBAUTCTYwMDQxMzQ4NTELMAkGA1UE BhMCVVMxDjAMBgNVBBEUBTk4MDUyMRMwEQYDVQQIEwpXYXNoaW5ndG9uMRAwDgYD VQQHFAdSZWRtb25kMRgwFgYDVQQJFA8xIE1pY3Jvc29mdCBXYXkxHjAcBgNVBAoU FU1pY3Jvc29mdCBDb3Jwb3JhdGlvbjEaMBgGA1UECxQRV2luZG93cyBBenVyZSBD RE4xHDAaBgNVBAMUE2dmeC1lY24uaG90bWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC + jRmBRv2iw1N2LirFdhgqmZ3G + BBc8gAn50O6TT1u zNqrjicf3KJ + BDHSGcnkysvWovwnUhDhMzAWf521iYi2lFZqC3txewGvjrKM0Gqz DhHrF + bzvNjyrIION89354cFxU1eK2okegYHkWIuyPHyCN6PFGK52OlkBixb34xv WvAZfjSu /時間+ F + lkedFZvJdd6KS4e8N / TGJ / dndfmReaKSiNFWBFbwhkndLdXU3p ZnVLCysETMuUoIsDIPcgDfji1XkoKLsri9WijVhjNH1MFf / T6 / g4PpWqZGl4si3t yQ0rdefDGfgX8lvq63aXnaap4SbjTYLviFRle / PMkXV7AgMBAAGjggJmMIICYjCB 0AYDVR0RBIHIMIHFghBnZngxLmhvdG1haWwuY29tghBnZngyLmhvdG1haWwuY29t ghBnZngzLmhvdG1haWwuY29tghBnZng0LmhvdG1haWwuY29tghBnZng1LmhvdG1h aWwuY29tghBnZng2LmhvdG1haWwuY29tghBnZng3LmhvdG1haWwuY29tghBnZng4 LmhvdG1haWwuY29tghRncmFwaGljcy5ob3RtYWlsLmNvbYIIYS5nZngubXOCE2dm eC1lY24uaG90bWFpbC5jb20wCQYDVR0TBAIwADAdBgNVHQ4EFgQUH0b2ApITW9WB / LA + oaz + 2ZnW / dwwDgYDVR0PAQH / BAQDAgWgMD4GA1UdHwQ3MDUwM6AxoC + GLWh0dHA6Ly9FVkludGwtY3JsLnZlcmlzaWduLmNvbS9FVkludGwyMDA2LmNybDBEBgNV HSAEPTA7MDkGC2CGSAGG + EUBBxcGMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3 LnZlcmlzaWduLmNvbS9jcHMwNAYDVR0lBC0wKwYIKwYBBQUHAwEGCCsGAQUFBwMC BglghkgBhvhCBAEGCisGAQQBgjcKAwMwHwYDVR0jBBgwFoAUTkPIHXbvN1N6T / JY b5TzOOLVvd8wdgYIKwYBBQUHAQEEajBoMCsGCCsGAQUFBzABhh9odHRwOi8vRVZJ bnRsLW9jc3AudmVyaXNpZ24uY29tMDkGCCsGAQUFBzAChi1odHRwOi8vRVZJbnRs LWFpYS52ZXJpc2lnbi5jb20vRVZJbnRsMjAwNi5jZXIwDQYJKoZIhvcNAQEFBQAD ggEBAFdVsrzkxJ6aRnaGIO1hbCDlekEMCT6OTlZXckzZeaIrNfSFLXHe89pWkRr1 AKz43nnM0pLxVuEHRE9pMZH6Om7SjqU5BR1qd6xp + ZJhuJA2I2319PCSbKCpv67X 82J8 / JKjH8e4fpOzb70dKUlNNr7x0aIMYuCq6unXXZQ5u83Uny42jcIQWLOlZRKC dYSqW3JalTYVZNvdEoQVuUEJJLcY1qMVJ9NFtdnrzrmcpK + 52 + nZQXbCkM7W8Vl1 WM / dbOnqsu0 + SIPZ4Q2wIAnT1azmBvxZ2ULvzW98HIAn4 / RdPuimnox8T9R2yrv1 xd5P6oAZWvmnX6e461m6HohhhDw =HSAEPTA7MDkGC2CGSAGG + EUBBxcGMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3 LnZlcmlzaWduLmNvbS9jcHMwNAYDVR0lBC0wKwYIKwYBBQUHAwEGCCsGAQUFBwMC BglghkgBhvhCBAEGCisGAQQBgjcKAwMwHwYDVR0jBBgwFoAUTkPIHXbvN1N6T / JY b5TzOOLVvd8wdgYIKwYBBQUHAQEEajBoMCsGCCsGAQUFBzABhh9odHRwOi8vRVZJ bnRsLW9jc3AudmVyaXNpZ24uY29tMDkGCCsGAQUFBzAChi1odHRwOi8vRVZJbnRs LWFpYS52ZXJpc2lnbi5jb20vRVZJbnRsMjAwNi5jZXIwDQYJKoZIhvcNAQEFBQAD ggEBAFdVsrzkxJ6aRnaGIO1hbCDlekEMCT6OTlZXckzZeaIrNfSFLXHe89pWkRr1 AKz43nnM0pLxVuEHRE9pMZH6Om7SjqU5BR1qd6xp + ZJhuJA2I2319PCSbKCpv67X 82J8 / JKjH8e4fpOzb70dKUlNNr7x0aIMYuCq6unXXZQ5u83Uny42jcIQWLOlZRKC dYSqW3JalTYVZNvdEoQVuUEJJLcY1qMVJ9NFtdnrzrmcpK + 52 + nZQXbCkM7W8Vl1 WM / dbOnqsu0 + SIPZ4Q2wIAnT1azmBvxZ2ULvzW98HIAn4 / RdPuimnox8T9R2yrv1 xd5P6oAZWvmnX6e461m6HohhhDw =HSAEPTA7MDkGC2CGSAGG + EUBBxcGMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3 LnZlcmlzaWduLmNvbS9jcHMwNAYDVR0lBC0wKwYIKwYBBQUHAwEGCCsGAQUFBwMC BglghkgBhvhCBAEGCisGAQQBgjcKAwMwHwYDVR0jBBgwFoAUTkPIHXbvN1N6T / JY b5TzOOLVvd8wdgYIKwYBBQUHAQEEajBoMCsGCCsGAQUFBzABhh9odHRwOi8vRVZJ bnRsLW9jc3AudmVyaXNpZ24uY29tMDkGCCsGAQUFBzAChi1odHRwOi8vRVZJbnRs LWFpYS52ZXJpc2lnbi5jb20vRVZJbnRsMjAwNi5jZXIwDQYJKoZIhvcNAQEFBQAD ggEBAFdVsrzkxJ6aRnaGIO1hbCDlekEMCT6OTlZXckzZeaIrNfSFLXHe89pWkRr1 AKz43nnM0pLxVuEHRE9pMZH6Om7SjqU5BR1qd6xp + ZJhuJA2I2319PCSbKCpv67X 82J8 / JKjH8e4fpOzb70dKUlNNr7x0aIMYuCq6unXXZQ5u83Uny42jcIQWLOlZRKC dYSqW3JalTYVZNvdEoQVuUEJJLcY1qMVJ9NFtdnrzrmcpK + 52 + nZQXbCkM7W8Vl1 WM / dbOnqsu0 + SIPZ4Q2wIAnT1azmBvxZ2ULvzW98HIAn4 / RdPuimnox8T9R2yrv1 xd5P6oAZWvmnX6e461m6HohhhDw =LnZlcmlzaWduLmNvbS9jcHMwNAYDVR0lBC0wKwYIKwYBBQUHAwEGCCsGAQUFBwMC BglghkgBhvhCBAEGCisGAQQBgjcKAwMwHwYDVR0jBBgwFoAUTkPIHXbvN1N6T / JY b5TzOOLVvd8wdgYIKwYBBQUHAQEEajBoMCsGCCsGAQUFBzABhh9odHRwOi8vRVZJ bnRsLW9jc3AudmVyaXNpZ24uY29tMDkGCCsGAQUFBzAChi1odHRwOi8vRVZJbnRs LWFpYS52ZXJpc2lnbi5jb20vRVZJbnRsMjAwNi5jZXIwDQYJKoZIhvcNAQEFBQAD ggEBAFdVsrzkxJ6aRnaGIO1hbCDlekEMCT6OTlZXckzZeaIrNfSFLXHe89pWkRr1 AKz43nnM0pLxVuEHRE9pMZH6Om7SjqU5BR1qd6xp + ZJhuJA2I2319PCSbKCpv67X 82J8 / JKjH8e4fpOzb70dKUlNNr7x0aIMYuCq6unXXZQ5u83Uny42jcIQWLOlZRKC dYSqW3JalTYVZNvdEoQVuUEJJLcY1qMVJ9NFtdnrzrmcpK + 52 + nZQXbCkM7W8Vl1 WM / dbOnqsu0 + SIPZ4Q2wIAnT1azmBvxZ2ULvzW98HIAn4 / RdPuimnox8T9R2yrv1 xd5P6oAZWvmnX6e461m6HohhhDw =LnZlcmlzaWduLmNvbS9jcHMwNAYDVR0lBC0wKwYIKwYBBQUHAwEGCCsGAQUFBwMC BglghkgBhvhCBAEGCisGAQQBgjcKAwMwHwYDVR0jBBgwFoAUTkPIHXbvN1N6T / JY b5TzOOLVvd8wdgYIKwYBBQUHAQEEajBoMCsGCCsGAQUFBzABhh9odHRwOi8vRVZJ bnRsLW9jc3AudmVyaXNpZ24uY29tMDkGCCsGAQUFBzAChi1odHRwOi8vRVZJbnRs LWFpYS52ZXJpc2lnbi5jb20vRVZJbnRsMjAwNi5jZXIwDQYJKoZIhvcNAQEFBQAD ggEBAFdVsrzkxJ6aRnaGIO1hbCDlekEMCT6OTlZXckzZeaIrNfSFLXHe89pWkRr1 AKz43nnM0pLxVuEHRE9pMZH6Om7SjqU5BR1qd6xp + ZJhuJA2I2319PCSbKCpv67X 82J8 / JKjH8e4fpOzb70dKUlNNr7x0aIMYuCq6unXXZQ5u83Uny42jcIQWLOlZRKC dYSqW3JalTYVZNvdEoQVuUEJJLcY1qMVJ9NFtdnrzrmcpK + 52 + nZQXbCkM7W8Vl1 WM / dbOnqsu0 + SIPZ4Q2wIAnT1azmBvxZ2ULvzW98HIAn4 / RdPuimnox8T9R2yrv1 xd5P6oAZWvmnX6e461m6HohhhDw =bnRsLW9jc3AudmVyaXNpZ24uY29tMDkGCCsGAQUFBzAChi1odHRwOi8vRVZJbnRs LWFpYS52ZXJpc2lnbi5jb20vRVZJbnRsMjAwNi5jZXIwDQYJKoZIhvcNAQEFBQAD ggEBAFdVsrzkxJ6aRnaGIO1hbCDlekEMCT6OTlZXckzZeaIrNfSFLXHe89pWkRr1 AKz43nnM0pLxVuEHRE9pMZH6Om7SjqU5BR1qd6xp + ZJhuJA2I2319PCSbKCpv67X 82J8 / JKjH8e4fpOzb70dKUlNNr7x0aIMYuCq6unXXZQ5u83Uny42jcIQWLOlZRKC dYSqW3JalTYVZNvdEoQVuUEJJLcY1qMVJ9NFtdnrzrmcpK + 52 + nZQXbCkM7W8Vl1 WM / dbOnqsu0 + SIPZ4Q2wIAnT1azmBvxZ2ULvzW98HIAn4 / RdPuimnox8T9R2yrv1 xd5P6oAZWvmnX6e461m6HohhhDw =bnRsLW9jc3AudmVyaXNpZ24uY29tMDkGCCsGAQUFBzAChi1odHRwOi8vRVZJbnRs LWFpYS52ZXJpc2lnbi5jb20vRVZJbnRsMjAwNi5jZXIwDQYJKoZIhvcNAQEFBQAD ggEBAFdVsrzkxJ6aRnaGIO1hbCDlekEMCT6OTlZXckzZeaIrNfSFLXHe89pWkRr1 AKz43nnM0pLxVuEHRE9pMZH6Om7SjqU5BR1qd6xp + ZJhuJA2I2319PCSbKCpv67X 82J8 / JKjH8e4fpOzb70dKUlNNr7x0aIMYuCq6unXXZQ5u83Uny42jcIQWLOlZRKC dYSqW3JalTYVZNvdEoQVuUEJJLcY1qMVJ9NFtdnrzrmcpK + 52 + nZQXbCkM7W8Vl1 WM / dbOnqsu0 + SIPZ4Q2wIAnT1azmBvxZ2ULvzW98HIAn4 / RdPuimnox8T9R2yrv1 xd5P6oAZWvmnX6e461m6HohhhDw =dYSqW3JalTYVZNvdEoQVuUEJJLcY1qMVJ9NFtdnrzrmcpK + 52 + nZQXbCkM7W8Vl1 WM / dbOnqsu0 + SIPZ4Q2wIAnT1azmBvxZ2ULvzW98HIAn4 / RdPuimnoxdYSqW3JalTYVZNvdEoQVuUEJJLcY1qMVJ9NFtdnrzrmcpK + 52 + nZQXbCkM7W8Vl1 WM / dbOnqsu0 + SIPZ4Q2wIAnT1azmBvxZ2ULvzW98HIAn4 / RdPuimnox

-----証明書の終了-----

サーバー証明書の件名=/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Washington/businessCategory=PrivateOrganization/serialNumber=600413485/C=US/postalCode=98052/ ST = Washington / L = Redmond / street = 1 Microsoft Way / O = Microsoft Corporation / OU = Windows Azure CDN / CN = gfx-ecn.hotmail.com issuer = / C = US / O = VeriSign、Inc./OU = VeriSign Trust Network / OU = https://www.verisign.com/rpaでの利用規約 (c)06 / CN=VeriSignクラス3拡張検証SSLSGCCA

クライアント証明書のCA名は送信されません

SSLハンドシェイクは1933バイトを読み取り、480バイトを書き込みました

新規、TLSv1 / SSLv3、暗号はAES256-SHAサーバー公開鍵は2048ビット安全な再ネゴシエーションがサポートされています圧縮:なし拡張:なしSSL-セッション:プロトコル:SSLv3暗号:AES256-SHAセッションID:3CC559C15AF17B09346C371A1CB292DF77C272A37FDC4DF69EEE0EE9CC067マスターキー:F626E23FDCC89B1329FD4F5D1ED5A940F0CB14A1C377BFDB6ABA6238B91F9C11390EC16FD117C090B3171FBEE762B792キー引数:なしPSK ID:なしPSK IDヒント:なし開始時間:1355423684タイムアウト:7200(秒)リターンコードの確認:21

opensslの出力から、opensslプログラムが同様のエラーを生成することがわかります(これにより、opensslのバグのように見えますか?)。また、hotmailサーバーはサーバー証明書のみを返し、中間証明書は返しません。それがおそらくエラーの原因です。他のhttpsサーバーで同じsslコマンドを試しました。また、サーバー証明書と中間証明書の両方を返します。私がテストした銀行サイトの中には、証明書チェーン全体をルートCAに戻すものさえありました。したがって、問題は、中間証明書が返されない場合、どのように、どこから取得するのかということです。IEやchromeなどの他のブラウザはこれをどのように処理しますか?


ここでより多くの調査結果。

実際、私が言及した2つのサーバーは両方とも、hotmailとyahooメールのページはめ込みコンポーネントをダウンロードするために使用されます。yahooメールのメインログインページ自体は、完全な証明書チェーンを返します。他のブラウザがメインページにアクセスすると、後で使用できるように中間証明書がローカルに保存されます。ただし、QTWebkitは中間証明書を自動的にキャッシュしないため、問題が発生します。サーバーにアクセスした場合https://gfx8.hotmail.comFirefoxの新しいコピーを直接使用すると、同じエラーが発生します。ただし、最初にhttps:/www.hotmail.comにアクセスしてからhotmailにログインすると、ログイン後に一部のコンポーネントがgfx8サーバーからダウンロードされますが、エラーは発生しません。QTWebkitは、システム証明書ストアから中間証明書をロードせず、システム証明書ストアに中間証明書を追加しないことを発見しました。中間証明書をメモリ内に内部的にキャッシュすることもありません。これにより、完全な証明書チェーンを返さない一部のサーバーで問題が発生します。

中間証明書をPEMファイルに保存して、アプリケーションの起動時にロードしてみました。WindowsとLinuxで正常に動作します。しかし、どういうわけか、それはMacには影響しません。理由はわかりません。

4

1 に答える 1

3

SSL エラーを無視せずにアプリケーションで安全な接続をサポートするには、ロードしているサイトがアクセスしているすべてのドメインのルート証明書が必要です。そのサーバーの証明書も取得します (たとえば、現在のサイトの証明書を表示して chrome から証明書をダウンロードし、チェーン全体を取得しますが、個別にダウンロードできます)。これらすべての証明書を 1 つの別のフォルダーに保存した後、アプリケーションの初期化後に次のコードをどこかに追加します。最初にすべての証明書が読み込まれるため、QT は証明書にアクセスできます。

import os

from PySide.QtNetwork import QSsl, QSslConfiguration, QSslCertificate
from PySide.QtCore import QFile, QIODevice


def load_certs(cert_path):
    # cert_path is a string "/path/to/cert/files"
    ssl_config = QSslConfiguration.defaultConfiguration()
    ssl_config.setProtocol(QSsl.SecureProtocols)

    certs = ssl_config.caCertificates()

    for cert_filename in os.listdir(cert_path):
        if os.path.splitext(cert_filename)[1] in ('.cer', '.crt', '.pem'):
            cert_filepath = os.path.join(cert_path, cert_filename)
            cert_file = QFile(cert_filepath)
            cert_file.open(QIODevice.ReadOnly)
            cert = QSslCertificate(cert_file)
            certs.append(cert)

    ssl_config.setCaCertificates(certs)
    QSslConfiguration.setDefaultConfiguration(ssl_config)

これで、サイトで証明書の検証が必要になったときに失敗しなくなりました。ただし、openssl は実際に Debian システムでの TLS 実装に問題があり、その場合、ページが読み込まれない、または有効な証明書がない場合に同様のエラーが発生するなどの問題が発生します。そのような場合、ページを機能させるには、それらのページに SSLv3 を強制的に使用する必要があります。カスタム仮想関数をQNetworkAccessManagercreateRequestにバインドし、リクエストごとに ssl プロトコルをオーバーライドすることで、これを実現できます。そうすれば、すべてのサイトで古い ssl バージョンに依存する必要がなくなります (デフォルトの ssl プロトコルをグローバルに設定することもできますが、それは最善の考えではありません)。

class Browser(object):

    def __init__(self):
        self.network_manager = QNetworkAccessManager()
        self.network_manager.createRequest = self._create_request
        self.web_page = QWebPage()
        self.web_page.setNetworkAccessManager(self.network_manager)
        self.web_view = QWebView()
        self.web_view.setPage(self.web_page)
        self._override_ssl = None

    def _create_request(self, operation, request, data):
        ssl_protocols = {'sslv2': QSsl.SslV2,
                         'sslv3': QSsl.SslV3,
                         'tlsv1': QSsl.TlsV1,
                         'tlsv1sslv3': QSsl.TlsV1SslV3,
                         'unknownprotocol': QSsl.UnknownProtocol,
                         'secureprotocols': QSsl.SecureProtocols}

        if self._override_ssl is not None:
            ssl_config = QSslConfiguration.defaultConfiguration()
            ssl_config.setProtocol(ssl_protocols[self._override_ssl])
            request.setSslConfiguration(ssl_config)

        reply = QNetworkAccessManager.createRequest(self.network_manager,
                                                    operation,
                                                    request,
                                                    data)

        return reply

    def override_ssl(self, protocol_id):
        # protocol id is a string like 'sslv3' or 'tlsv1'
        self._override_ssl = protocol_id

OK、ほとんどのコードをメモリから入力しました。何かが機能しない場合は報告してください。

于 2012-12-12T06:25:50.590 に答える