web-dev-qa-db-ja.com

「1408F10B：SSLルーチン：SSL3_GET_RECORD：間違ったバージョン番号呼び出し：」Indyで

私は頻繁にTIdHTTP Google Analytics APIを呼び出すWebアプリを持っています（1日あたり約25,000〜50,000）。多くの場合、APIの呼び出しは失敗し、件名にエラーメッセージが表示されます（1000回に1回未満）。それを実現するためのパターンを見つけることはできませんでした。失敗した呼び出しを再試行すると、通常は機能します。したがって、それは完全にランダムに見えます。

Opensslの最新バージョン（1.0.2.1-03/20/2015）を持っています。また、Indyの最新バージョン（2015年7月1日付けのソースコードファイル）。

以下は、これらの呼び出しを行うための基本的なソースコードです。

誰もがそれが何であるかについて何か考えを持っていますか？

APIに対して2つの同時呼び出しを行うと影響がありますか（これはマルチスレッドWebアプリで行われています）。

IdSSLIOHandlerSocket1 := TIdSSLIOHandlerSocketOpenSSL.create(nil);
IdSSLIOHandlerSocket1.PassThrough := True;
IdHTTP := TIdHTTP.create(nil);
IdHTTP.reusesocket := rsTrue;
IdSSLIOHandlerSocket1.reusesocket := rsTrue;
idhttp.handleredirects := True;
with IdSSLIOHandlerSocket1 do begin
  SSLOptions.Method := sslvTLSv1_2;
  SSLOptions.SSLVersions := [sslvTLSv1_2];
  SSLOptions.VerifyMode := [];
  SSLOptions.VerifyDepth := 2;
end;
with IdHTTP do begin
  IOHandler := IdSSLIOHandlerSocket1;
  ProxyParams.BasicAuthentication := False;
  Request.UserAgent := 'EmbeddedAnalytics API Interface';
  Request.ContentType := 'text/html';
  request.connection := 'close';
  Request.Accept := 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8';
  Request.BasicAuthentication := False;
  Request.UserAgent := 'Mozilla/3.0 (compatible; Indy Library)';
  HTTPOptions := [hoForceEncodeParams];
  Request.AcceptEncoding := 'gzip,deflate';
  Request.CustomHeaders.Add('Accept-Language: en-us,en;q=0.5');
  idhttp.Request.CustomHeaders.Add('Authorization: Bearer '+FToken);
end;
idhttp.get(':https://www.googleapis.com/analytics/v3/data/realtime?ids=..........');

pdate 1一部のコード行を次のように更新します。

SSLOptions.Method := sslvSSLv3;
SSLOptions.SSLVersions := [sslvSSLv3];

できます。 SSLエラーがなくなるかどうかを監視して確認します。

ソリューション sslVSSLv3に変更を加えると修正されました。エラーはもう発生しません！他のほとんどすべてのサービスが代わりにTLSを採用していることを見ると、これは多少意外です。

delphigoogle-analyticsopensslindy
6
M Schenkel

これを変更することで解決した問題：

SSLOptions.Method := sslvTLSv1_2;
SSLOptions.SSLVersions := [sslvTLSv1_2];

これに：

SSLOptions.Method := sslvSSLv3;
SSLOptions.SSLVersions := [sslvSSLv3];

SSLv3を回避するために、代わりにTLS 1.0を試すことをお勧めします。

GoogleとTLS 1.2について注意すべき点が2つあります。そして、これのいくつかは今までに変わっているかもしれません。 （この説明は非常に具体的で、GoogleサーバーとTLS 1.2にのみ適用されます）。

まず、TLS 1.2とECDSAを使用する場合は、圧縮を無効にする必要があります。この奇妙なファクトイドは、OpenSSLメーリングリストの ECDHE-ECDSAサポート での議論に現れました。これが生成した関連サポートチケットは次のとおりです。 Bug 3277：OpenSSL s_client doc missing option 。

次に、ChaCha20/Poly1305暗号を使用していない場合は、TLS 1.2のフォールバック暗号スイートに注意する必要があります。私はこれを理解することはできませんでしたが（特に、すべての短命なDHスイートがサポートされているはずなので）、私はそれを知っていますusedテスト。したがって、フォールバック用に以下を必ず含めてください（これは、IIS 8（またはおそらく7）以前を実行しているMicrosoftサーバーでも必要です）：

  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA
5
jww

これを変更することで解決した問題：

SSLOptions.Method := sslvTLSv1_2;
SSLOptions.SSLVersions := [sslvTLSv1_2];

これに：

SSLOptions.Method := sslvSSLv3;
SSLOptions.SSLVersions := [sslvSSLv3];

これは驚くべきことですが、ほとんどのサービスが代わりにTLSに移行しています。

2
M Schenkel

GoogleがまだSSLv3を使用してサーバーへのアクセスを許可しているとは思えません（ Poodle 攻撃を参照）。

POODLE攻撃（「ダウングレードされたレガシー暗号化でのOracleの埋め込み」の略）は、インターネットおよびセキュリティソフトウェアクライアントのSSL 3.0へのフォールバックを利用する中間者攻撃です。

クライアントがSSLv3関連のエラーメッセージを受け取った場合、ネットワークの専門家に連絡して、このエラーメッセージが中間者攻撃によって引き起こされている可能性がないかどうかを確認します。

また、再現性がないため、単純なネットワークの問題である可能性もあります。

より詳細な診断には、Wiresharkの録音が役立ちます（私ではなく専門家にとって）。

0
mjn