it-swarm.com.de

"1408F10B: SSL-Routinen: SSL3_GET_RECORD: Falscher Versionsnummernaufruf:" unter Indy

Ich habe eine Web-App, die häufig TIdHTTP Aufrufe an die Google Analytics-API durchführt (etwa 25.000 bis 50.000 pro Tag). Gelegentlich schlagen Aufrufe der API mit der Fehlermeldung in der Betreffzeile fehl (nicht oft - weniger als 1 von 1000 Mal). Ich konnte nie ein Muster finden, um es zu erreichen. Das Wiederholen des fehlgeschlagenen Anrufs funktioniert normalerweise. Es scheint also völlig zufällig.

Ich habe die neueste Version von openssl (1.0.2.1 - 20.03.2015). Und die neueste Version von Indy (Quellcode-Dateien vom 01.07.2015).

Nachfolgend finden Sie den grundlegenden Quellcode für diese Anrufe.

Hat jemand eine Idee was es sein könnte? 

Würden zwei gleichzeitige Aufrufe der API Auswirkungen haben (dies geschieht in einer Webanwendung mit mehreren Threads)?

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=..........');

Update 1 Einige Codezeilen aktualisieren auf:

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

Es klappt. Ich werde überwachen und sehen, ob SSL-Fehler verschwinden.

Lösung Es stellte sich heraus, dass die Änderungen an sslVSSLv3 korrigiert wurden. Ich bekomme die Fehler nicht mehr! Dies ist etwas überraschend, da die meisten anderen Dienste stattdessen TLS verwenden.

6
M Schenkel

Problem gelöst durch Änderung dieses Problems:

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

Zu diesem:

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

Möglicherweise möchten Sie stattdessen TLS 1.0 ausprobieren, um SSLv3 zu vermeiden.

Bei Google und TLS 1.2 sind zwei Dinge zu beachten. Und einiges davon mag sich inzwischen geändert haben. (Diese Diskussion ist sehr spezifisch und gilt nur für Google-Server und TLS 1.2). 

Erstens müssen Sie die Komprimierung deaktivieren, wenn Sie TLS 1.2 und ECDSA verwenden. Dieser seltsame Factoid zeigte sich in einer Diskussion auf der OpenSSL-Mailingliste unter ECDHE-ECDSA Support . Hier ist ein zugehöriges Support-Ticket, das es generiert hat: Fehler 3277: OpenSSL s_client doc fehlende Option .

Zweitens: Wenn Sie die ChaCha20/Poly1305-Chiffren nicht verwenden, müssen Sie sich der Fallback-Chiffriersätze für TLS 1.2 bewusst sein. Ich war nie in der Lage, dies herauszufinden (vor allem, da alle ephemeren DH-Suiten unterstützt werden sollten), aber ich weiß, dass used der Fall war, um Tests durchzuführen. Stellen Sie daher sicher, dass Sie Folgendes für den Fallback-Vorgang angeben (dies ist auch für Microsoft-Server erforderlich, auf denen IIS 8 (oder möglicherweise 7) und früher ausgeführt wird):

  • 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

Problem gelöst durch Änderung dieses Problems:

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

Zu diesem:

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

Dies ist überraschend, da die meisten Dienste stattdessen zu TLS wechseln.

2
M Schenkel

Ich bezweifle, dass Google weiterhin Zugriff auf ihre Server über SSLv3 zulässt (siehe Poodle attack).

Der POODLE-Angriff (der für "Padding Oracle On Downgraded Legacy Encryption" steht) ist ein Man-in-the-Middle-Exploit, der Vorteil des Rückfalls von Internet- und Sicherheitssoftware-Clients auf SSL 3,0.

Wenn Ihr Client also eine SSLv3-bezogene Fehlermeldung erhält, würde ich einen Netzwerkexperten kontaktieren, um zu prüfen, ob diese Fehlermeldung durch einen Man-in-the-Middle-Angriff verursacht werden kann.

Es kann auch ein einfaches Netzwerkproblem sein, da es nicht reproduzierbar ist.

Für eine tiefere Diagnose wäre eine Wireshark-Aufnahme hilfreich (für den Experten, nicht für mich).

0
mjn