7
votes

"1408F10B: SSL routines: SSL3_GET_RECORD: Numéro de version erroné:" sur Indy

J'ai une application Web qui fait des appels fréquents Tidhttp forts> à l'API Google Analytics (environ 25 000 à 50 000 par jour). Chaque si souvent, les appels à l'API échouent avec le message d'erreur de la ligne d'objet (pas souvent - moins de 1 sur 1000 fois). Je n'ai jamais pu trouver un modèle pour que cela se produise. Et réessayer l'appel en échec fonctionne habituellement. Donc, il semble tout à fait aléatoire.

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

ci-dessous est le code source de base pour faire ces appels. P>

Quelqu'un a des idées ce qu'elle pourrait être? P>

Faire deux appels simultanés à l'API affecte les choses (cela se déroule dans une application Web multi-threadé)? P>

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


5 commentaires

Non liée à votre question, mais vous devez 1) ne pas utiliser réutiliser , 2) ne pas ajouter manuellement dégonfler ou gzip dans Demande.Acceptaccoding (Définir la propriété TIDHTTPCompressor à la place), 2) Utilisez Demande.acceptlanguage au lieu de Demande.Customheaders.add () < / Code>, et 4) Supprimez le : devant l'URL que vous passez à obtenez () . Et si vous faites autant de demandes, vous pouvez envisager d'utiliser demande.Connection: = 'Garder-alive' au lieu de 'Fermer' afin que vous puissiez réutiliser une seule connexion HTTP pour plusieurs demandes.


Merci à nouveau @RemyleBeau pour votre surveillance active des problèmes Indy. Je vais jeter un oeil à vos suggestions. J'ai trouvé que revenir à SSLVSSLV3 pour les appels de Google API s'occupe du problème. Surprenant Voyant tellement d'autres services s'éloigne de cela à cause du caniche. Vous avez une explication pour pourquoi la plupart du temps SSLVTLSV1_2 a fonctionné, mais chaque si souvent ce ne serait pas?


@RemyleBeau - merci. Je les ai mis en œuvre. En fait, j'ai un paramètre pour basculer entre fermer et gardien-vivant . À l'époque, il fut fixé à "Fermer". Question: "Garder-vivant" sera-t-elle efficace si après l'appel, je libère l'objet IDHTTP? En outre, en ce qui concerne le : , c'était une faute de frappe.


Par défaut, non. Si vous libérez l'objet TIDHTTP , il fermera la connexion. Si vous souhaitez réutiliser la même connexion pour un nouvel objet TIDHTTP , vous devez 1) enregistrer le dernier port hôte / et < Code> iohandler Valeurs de la propriété, 2) Définissez la propriété iohandler à NIL sans fermer la connexion, 3) Attribuer l'objet IOHANDLER IOHANDLER à un autre TIDHTTP objet et attribuez l'hôte enregistré / / valeurs , 5) Définissez le fidhttp.response.keepalive propriété sur true et http.response.connection propriété sur Garder-vie . Cela permettra fidhttp pour réutiliser la connexion existante.


Consultez ceci: Stackoverflow.com/Questtions/50840101/...


3 Réponses :


0
votes

Je doute que Google autorise toujours l'accès à leurs serveurs à l'aide de SSLV3 (voir Attaque de caniche ).

L'attaque de caniche (qui signifie «rembourrage oracle sur dégradé Le cryptage Legacy ») est un exploit man-in-the-intermédiaire qui prend Avantage des logiciels Internet et des logiciels de sécurité Les retombées des clients à SSL 3.0.

Donc, si votre client obtient un message d'erreur connexe SSLV3, je contacterais un expert en réseau pour vérifier si ce message d'erreur peut être causé par une attaque homme-in-the-intermédiaire.

Cela pourrait également être un simple problème de réseau, car il n'est pas reproductible.

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


6 commentaires

Merci de commenter. Au cours de l'année, j'ai dû mettre à jour d'Indy 9 à Indy 10 pour la seule raison de l'attaque de caniche. Dans ce cas, il s'agissait d'obtenir une interface PayPal pour travailler. Je n'ai pas la version exacte, mais j'utilisais quelque chose avant SSLVTLSV1_2. Mise à niveau vers Indy 10 et utiliser cette nouvelle version résolue à ce problème. Vous dites que vous doutez Google autorise toujours l'accès à l'aide de SSLV3. Si tel était le cas, cela ne serait-il pas logique qu'ils nieraient pour toutes les demandes? Certes, ils n'autorisaient pas certains à travers mais pas d'autres.


"L'attaque du caniche ... est un homme-dans-le-Middle ..." - ce n'est pas une attaque MITM. Si l'homme était au milieu, il aurait accès direct au matériel et n'aurait pas besoin d'utiliser le rembourrage oracle. Les attaques que j'ai vues sont plus comme une MITB (homme dans le navigateur) qui est autorisée à faire des demandes non authentifiées. Dans le navigateur, c'est simplement un CSRF


@Jww the Source originale dit SSLV3 < Code> facilite la tâche des attaquants manoussitaires d'obtenir des données ClearText via une attaque de padding-oracle, alias le problème "caniche"


@mjn - plus de désinformation. Il n'y a pas d'attaquant actif qui intercepte la chaîne. Une meilleure discussion peut être trouvée à Groupe de travail TLS: Repensation TLS 1.3 .


Oui - peut-être une mauvaise mise en réseau: Github.com/google/google-api- Python-Client / Problèmes / 37


@MJN - "Je doute que Google autorise toujours l'accès à leurs serveurs à l'aide de SSLV3" - Google a activé SSLV3 sur leurs serveurs. Voir, par exemple, $ openssl s_client -ssl3 -connect www.google.com:443 . Et ce n'est pas seulement le site principal de Google; ses autres propriétés, comme GDRive et Gmail, aussi. Ils adorent de l'argent et le paquet doit passer à tout prix afin que l'annonce puisse être servie. Google a désactivé SSLV3 dans son navigateur Chrome, cependant. Voir menacePost.com/... .



3
votes

problème résolu en modifiant ceci: xxx

à ceci: xxx

Ceci est surprenant pour savoir que la plupart des services se déplacent à TLS. .


1 commentaires

J'ai rencontré des problèmes avec les serveurs TLS 1.2 et Google. Consultez la réponse ci-dessous qui peut expliquer certaines des choses que vous rencontrez et certains contours potentiels.



5
votes

problème résolu en modifiant ceci: p>

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

2 commentaires

Merci, je reviendrai et apporterai les changements comme vous le suggérez. Et vous permettra de connaître les résultats. Remy Lebeau a souligné que la compression ne doit pas être définie.


@Mschenke - Je pense que TLS 1.2 est un bon choix à cause des suites AES / GCM (AEAD) ou CHACAH20 / POLY1305. Vous devriez essayer de faire fonctionner cela. Si vous ne pouvez pas, revenez à «TLS 1.0 et au-dessus». Il faudra 1,2 si cela peut être négocié; Sinon, cela prendra le plus haut TLS qu'il peut obtenir. Voici comment faire "TLS 1.0 et plus" en C: Comment bloquer les protocoles SSL en faveur de TLS? . Mais je ne sais pas comment le faire avec Delphes ou Indy.