web-dev-qa-db-fra.com

"1408F10B: routines SSL: SSL3_GET_RECORD: appel du numéro de version incorrect:" sur Indy

J'ai une application Web qui fait de fréquents appels TIdHTTP à l'API Google Analytics (environ 25 000 à 50 000 par jour). De temps en temps, les appels à l'API échouent avec le message d'erreur dans la ligne d'objet (pas souvent - moins de 1 fois sur 1 000). Je n'ai jamais réussi à trouver un modèle pour que cela se produise. Et réessayer l'appel ayant échoué fonctionne généralement. Cela semble donc totalement aléatoire.

J'ai la dernière version de openssl (1.0.2.1 - 20/03/2015). Et la dernière version d'Indy (fichiers de code source du 01/07/2015).

Vous trouverez ci-dessous le code source de base pour effectuer ces appels.

Quelqu'un a une idée de ce que cela pourrait être? 

Effectuer deux appels simultanés à l'API aurait-il une incidence sur les choses (cela se passe dans une application Web multi-thread)?

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 met à jour certaines lignes de code en:

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

Ça marche. Je vais surveiller et voir si les erreurs SSL disparaissent.

Solution Corrige les modifications apportées à sslVSSLv3. Je n'ai plus les erreurs! Cela est quelque peu surprenant, étant donné que la plupart des autres services adoptent plutôt TLS.

delphigoogle-analyticsopensslindy
6
M Schenkel

Problème résolu en changeant ceci:

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

Pour ça:

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

Vous voudrez peut-être essayer TLS 1.0 à la place pour éviter SSLv3.

Il faut tenir compte de deux choses avec Google et TLS 1.2. Et une partie de cela peut avoir changé maintenant. (Cette discussion est très spécifique et ne concerne que les serveurs Google et TLS 1.2). 

Tout d'abord, vous devez désactiver la compression si vous utilisez TLS 1.2 et ECDSA. Ce fait étrange est apparu dans une discussion sur la liste de diffusion OpenSSL sous ECDHE-ECDSA Support . Voici un ticket d’assistance lié qu’il a généré: Bug 3277: OpenSSL s_client doc option manquante .

Deuxièmement, si vous n'utilisez pas les chiffrements ChaCha20/Poly1305, vous devez être attentif aux suites de chiffrement de secours pour TLS 1.2. Je n'ai jamais été capable de le comprendre (surtout depuis que toutes les suites DH éphémères devraient être supportées), mais je le sais utilisé comme étant le cas des tests. Veillez donc à inclure les éléments suivants pour le repli (ceci est également nécessaire pour les serveurs Microsoft exécutant IIS 8 (ou peut-être 7) et versions antérieures):

  • 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

Problème résolu en changeant ceci:

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

Pour ça:

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

Cela est surprenant de voir que la plupart des services passent à la place à TLS.

2
M Schenkel

Je doute que Google autorise toujours l'accès à ses serveurs avec SSLv3 (voir Poodle attack).

L’attaque de POODLE (qui signifie "Padding Oracle On Downgraded Legacy Encryption") est un exploit de type man-in-the-middle qui prend avantage du repli des clients de logiciels Internet et de logiciels de sécurité sur SSL 3.0.

Par conséquent, si votre client reçoit un message d'erreur relatif à SSLv3, je contacterais un expert du réseau pour vérifier si ce message d'erreur peut être causé par une attaque par intercepteur.

Il pourrait également s'agir d'un simple problème de réseau, car il n'est pas reproductible.

Pour un diagnostic plus approfondi, un enregistrement Wireshark serait utile (pour l'expert, pas pour moi).

0
mjn