J'ai une application Web qui fait des appels fréquents 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];
3 Réponses :
Je doute que Google autorise toujours l'accès à leurs serveurs à l'aide de SSLV3 (voir Attaque de caniche ). p>
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. P> blockQuote>
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. P>
Cela pourrait également être un simple problème de réseau, car il n'est pas reproductible. P>
Pour un diagnostic plus profond, un enregistrement Wireshark serait utile (pour l'expert, pas moi). P>
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 ..." I> - 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" code>
@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" i> - Google a activé SSLV3 sur leurs serveurs. Voir, par exemple, $ openssl s_client -ssl3 -connect www.google.com:443 code>. 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/... .
problème résolu en modifiant ceci: à ceci: p> Ceci est surprenant pour savoir que la plupart des services se déplacent à TLS. . p> p>
J'ai rencontré des problèmes avec les serveurs TLS 1.2 et i> Google. Consultez la réponse ci-dessous qui peut expliquer certaines des choses que vous rencontrez et certains contours potentiels.
problème résolu en modifiant ceci: p>
SSLOptions.Method := sslvSSLv3; SSLOptions.SSLVersions := [sslvSSLv3];
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.
Non liée à votre question, mais vous devez 1) ne pas utiliser
réutiliser code>, 2) ne pas ajouter manuellement
dégonfler code> ou
gzip code> dans
Demande.Acceptaccoding Code> (Définir la propriété
TIDHTTPCompressor code> à la place), 2) Utilisez
Demande.acceptlanguage Code> au lieu de
Demande.Customheaders.add () < / Code>, et 4) Supprimez le
: code> devant l'URL que vous passez à
obtenez () code>. Et si vous faites autant de demandes, vous pouvez envisager d'utiliser
demande.Connection: = 'Garder-alive' code> au lieu de
'Fermer' code> 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 code> et
gardien-vivant code>. À 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
: code>, c'était une faute de frappe.
Par défaut, non. Si vous libérez l'objet
TIDHTTP code>, il fermera la connexion. Si vous souhaitez réutiliser la même connexion pour un nouvel objet code> TIDHTTP code>, vous devez 1) enregistrer le dernier port
hôte code> /
code> et < Code> iohandler code> Valeurs de la propriété, 2) Définissez la propriété
iohandler code> à NIL sans fermer la connexion, 3) Attribuer l'objet
IOHANDLER CODE> IOHANDLER CODE> à un autre
TIDHTTP code> objet et attribuez l'hôte enregistré code> /
/
valeurs code>, 5) Définissez le
fidhttp.response.keepalive code> propriété sur true et
http.response.connection code> propriété sur
Garder-vie code>. Cela permettra
fidhttp code> pour réutiliser la connexion existante.
Consultez ceci: Stackoverflow.com/Questtions/50840101/...