Requests: Les requêtes ne fonctionnent pas dans un conteneur Docker

Pouvez-vous exécuter openssl version dans votre conteneur ?

Cela peut aussi très certainement être lié à la version Python, nous aimerions le savoir aussi.

salut

Python 2.7 (12)
Openssl 1.0.2g

Merci

Exécutez-vous la même version de Requests dans le conteneur et à l'extérieur ? Quelles sont les deux versions ?

2.11.1 lors du travail et 2.12.5 à l'intérieur du conteneur. Cela fait-il une différence?

Oui, il y a des changements de code décents entre ces deux versions. Vous voulez essayer de rétrograder rapidement à 2.11 dans le conteneur pour voir ce qui se passe ?

Toujours en échec, mais avec un message d'erreur différent
...
...
Fichier "/usr/local/lib/python2.7/dist-packages/requests/adapters.py", ligne 491, en envoi
lever SSLError(e, request=request)
SSLError : EOF s'est produit en violation du protocole (_ssl.c:590)

Hum. Cette erreur différente est à peu près la même erreur. Pouvez-vous nous révéler quel serveur Web vous essayez de contacter ?

C'est mon propre serveur, qui a un certificat auto-signé. J'envoie verify=False pour ignorer SSL mais ne semble pas l'aimer

réponse=sess.post(url,params, headers=h,verify=False)

Pouvez-vous afficher la configuration TLS de votre serveur et à quelle version d'OpenSSL il est lié ?

Son TLS 1.2 et la même version openSSL... rien de spécial. je ne pense pas là
est-ce que quelque chose ne va pas côté serveur car cela fonctionne bien en dehors du docker
récipient

Le ven 31 mars 2017 à 16:07, Cory Benfield [email protected]
a écrit:

Pouvez-vous montrer la configuration TLS pour votre serveur, et ce qu'OpenSSL
version à laquelle il est lié ?

-
Vous recevez ceci parce que vous avez créé le fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/kennethreitz/requests/issues/3948#issuecomment-290738188 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AMK55o2K5PaiflW3wHWD_rZYm_WFXXGyks5rrRa6gaJpZM4Mvjzc
.

Ainsi, "mauvais" ici n'est défini que s'il y a un décalage entre ce que le client et le serveur attendent. Par intérêt, votre serveur attend-il du SNI ? Atteignez-vous votre serveur via le nom d'hôte ou l'IP ?

Dans ce conteneur, pouvez-vous boucler votre serveur avec la même URL ? Ou même simplement par telnet ? Je me demande si les requêtes peuvent même atteindre le serveur à partir duquel vous avez déployé le conteneur.

salut

En réponse aux deux. il attend SNI et je l'accède via le nom d'hôte

Du conteneur je peux telnet au serveur, il n'y a aucun problème avec
cette. J'ai exposé un autre service via http et cela fonctionne bien, c'est purement
la poignée de main SSL ce qui échoue

Le ven 31 mars 2017 à 16h16, Ian Cordasco [email protected]
a écrit:

Dans ce conteneur, pouvez-vous boucler votre serveur avec la même URL ? Ou même
juste telnet? Je me demande si les requêtes peuvent même atteindre le serveur depuis
où vous avez déployé le conteneur.

-
Vous recevez ceci parce que vous avez créé le fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/kennethreitz/requests/issues/3948#issuecomment-290740743 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AMK55kVKzprqGA1n1PKJznWX_g_V7nsxks5rrRi-gaJpZM4Mvjzc
.

D'accord, quel est le résultat de l'exécution de openssl s_client -connect host:port sur votre serveur depuis l'intérieur du conteneur ?

salut

Il se connecte sans problème (connecté (00003))

Le ven 31 mars 2017 à 16:19, Cory Benfield [email protected]
a écrit:

Ok, quel est le résultat de l'exécution de openssl s_client -connect host:port to
votre serveur depuis l'intérieur du conteneur ?

-
Vous recevez ceci parce que vous avez créé le fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/kennethreitz/requests/issues/3948#issuecomment-290741631 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AMK55oeDzw5HhrujLbMFLA6CCowT0umwks5rrRmLgaJpZM4Mvjzc
.

Désolé, tout le résultat. Je suis intéressé par le résultat de la négociation.

Vérifiez le code de retour : 19 (certificat auto-signé dans la chaîne de certificats)

Le ven 31 mars 2017 à 16:34, Cory Benfield [email protected]
a écrit:

Désolé, tout le résultat. Je suis intéressé par ce que le résultat de la
la négociation est.

-
Vous recevez ceci parce que vous avez créé le fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/kennethreitz/requests/issues/3948#issuecomment-290746053 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AMK55o4JyAkpP5h1ZPLBOkRONN2z9Em8ks5rrRz-gaJpZM4Mvjzc
.

Ce n'est pas tout le résultat. Veuillez copier et coller tout à partir de cette commande.

Non, tout le résultat. Toute la sortie. Tout ce qu'il imprime.

Il n'y a rien d'autre d'intéressant là-bas, juste la version tls, les informations sur le certificat, etc.

J'ai exactement la même réponse en dehors du conteneur
El El vie, 31 mars 2017 à 16h40, Cory Benfield [email protected]
description :

Non, tout le résultat. Toute la sortie. Tout ce qu'il imprime.

-
Vous recevez ceci parce que vous avez créé le fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/kennethreitz/requests/issues/3948#issuecomment-290747930 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AMK55iD8dY2eDxdfz1j0YzpteN8ThFJ3ks5rrR58gaJpZM4Mvjzc
.

Cette information est exactement ce qui m'intéresse. Quelque chose dans notre client TLS Hello rend votre serveur fou, et je suis donc intéressé de voir ce que votre serveur négocie.

Ok, faisons quelque chose pour être sûr que ce n'est pas mon certificat. je vais chercher n'importe quel
autre page qui utilise un certificat auto-signé (si vous en connaissez, veuillez
partager) et je vais essayer contre cela, vous pourrez donc connecter cela
serveur aussi

El El vie, 31 mars 2017 à 16h46, Cory Benfield [email protected]
description :

Cette information est exactement ce qui m'intéresse. Quelque chose dans notre TLS
Client Hello rend votre serveur fou, et je suis donc intéressé à voir
ce que votre serveur négocie.

-
Vous recevez ceci parce que vous avez créé le fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/kennethreitz/requests/issues/3948#issuecomment-290749603 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AMK55oT_6jlrkIO4VlXRsoohjEGzNy3pks5rrR_TgaJpZM4Mvjzc
.

Ce n'est pas votre certificat. Le message d'erreur en question (EOF inattendu) signifie que lors de la négociation TLS, le serveur nous a envoyé un paquet TCP FIN ou RST. Cela signifie que le serveur a choisi de fermer la connexion, pas nous. Cela signifie que le serveur a décidé que nous ne faisions pas quelque chose qui lui plaisait. Par conséquent, cela ne peut pas être la faute de votre certificat : nous n'en sommes pas encore à le valider.

@javixeneize sans les informations que nous vous avons demandées, je ne sais pas ce que nous pouvons faire d'autre pour vous aider.

Ok ok... je vous fournirai ça lundi
El El vie, 31 mars 2017 à 17:19, Ian Cordasco [email protected]
description :

@javixeneize https://github.com/javixeneize sans les informations
nous vous avons demandé, je ne sais pas ce que nous pouvons faire d'autre pour vous aider.

-
Vous recevez ceci parce que vous avez été mentionné.

Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/kennethreitz/requests/issues/3948#issuecomment-290759070 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AMK55ugTXZp-cZpp9JJJ7WmACcYXho2Rks5rrSeegaJpZM4Mvjzc
.

root<strong i="5">@4f66ccbaef3c</strong>:/# openssl s_client -connect api.quinto.ai:443
CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = fbbot.quintoapp.com
verify return:1
---
Certificate chain
 0 s:/CN=fbbot.quintoapp.com
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFCjCCA/KgAwIBAgISA1Bg18LrjA3qyyrEDmzE+5YSMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xNzAzMTQwNzMyMDBaFw0x
NzA2MTIwNzMyMDBaMB4xHDAaBgNVBAMTE2ZiYm90LnF1aW50b2FwcC5jb20wggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQD0xbEa4W4k4BlPrIxeVX+ekPl1
Od4OuwepY5Ha2BQd6YMiphh+we5H6JVu2XDuPbQnmQMtEwGa2T2Adhic4bGPPC7+
0j+utJuqGBRIbYJ09A5EQOhB4HhOSI82l1ZpPkHpvOiC4UoEgG4KOLnqBX0JydI3
8vhiV4EgbLr77wARsEeinK+Zj+7bpsEK8q+B7mR5km6f6tKT/i++Wd4Fx3Pz7iuK
aCulKzG4IMxopE/9DDf608H/3cFcSHvg/4IguPoOCx2ArNKE7QCNFGYAx9HhnV2y
AYVbd2WGWeJKuNWEwCF+nvxGDo4cHdT6kq9HHB6kPTYrZb7PrKtkq1C3MNB/AgMB
AAGjggIUMIICEDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEG
CCsGAQUFBwMCMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFENiqFyUkXGaxd/woyxi
6SqQz2WqMB8GA1UdIwQYMBaAFKhKamMEfd265tE5t6ZFZe/zqOyhMHAGCCsGAQUF
BwEBBGQwYjAvBggrBgEFBQcwAYYjaHR0cDovL29jc3AuaW50LXgzLmxldHNlbmNy
eXB0Lm9yZy8wLwYIKwYBBQUHMAKGI2h0dHA6Ly9jZXJ0LmludC14My5sZXRzZW5j
cnlwdC5vcmcvMB4GA1UdEQQXMBWCE2ZiYm90LnF1aW50b2FwcC5jb20wgf4GA1Ud
IASB9jCB8zAIBgZngQwBAgEwgeYGCysGAQQBgt8TAQEBMIHWMCYGCCsGAQUFBwIB
FhpodHRwOi8vY3BzLmxldHNlbmNyeXB0Lm9yZzCBqwYIKwYBBQUHAgIwgZ4MgZtU
aGlzIENlcnRpZmljYXRlIG1heSBvbmx5IGJlIHJlbGllZCB1cG9uIGJ5IFJlbHlp
bmcgUGFydGllcyBhbmQgb25seSBpbiBhY2NvcmRhbmNlIHdpdGggdGhlIENlcnRp
ZmljYXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL2xldHNlbmNyeXB0Lm9yZy9y
ZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEAf80at95dsb9WsSMaChtKNEJR
FfuPd/5MZaqFxWM6+AtEGZt2qbeOExIShEHFehUSWQnrCBTiPY6ildK1E5nhduap
4K0O7FrnMVaNBhnoBT7jsZMs7ivLpaKCT6imR71hQTUv07xw1kQJMu/jrHHtVjNi
9iI+VryZeETIVBtCXbirwKxT0JYLicdS/9M9m9wC7/H8xWVkcRR5dMI2Im+4klX4
eGmgi+XCJPkDZZEpfQHmIqQQ9ccCpP0BFs0JqfwLich71NdPihVnJDhVZrEVMcgs
+412WdWCOTIXrEzsL6xddypVETY2k5Z3S8sZTInWA9nYOGHW82xwh6/tRU+yiQ==
-----END CERTIFICATE-----
subject=/CN=fbbot.quintoapp.com
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3157 bytes and written 433 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: 78B1ABFE5A7BF1E698FB5D43D1A75D6F874DD9D2E12816E3276B349FC0C4B96B
    Session-ID-ctx:
    Master-Key: B6EE0F224CB1A93379B86524E9F01D618A018E2F1D68F5AB29F7570611F0D9CF4210F9946335A9FAAEEA143B0BC98D26
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 00 39 b1 81 4d f9 90 0a-b2 dd a8 e7 b5 6b 74 7c   .9..M........kt|
    0010 - ba 4e 8b 51 75 df c4 ae-e1 6c dc 3e 05 a1 0e fc   .N.Qu....l.>....
    0020 - 4e 61 83 34 f4 ea 06 b7-8d 54 82 01 a8 b2 fa 2a   Na.4.....T.....*
    0030 - 48 69 01 b5 06 6b ee 18-3d 93 f5 d7 31 d8 66 8f   Hi...k..=...1.f.
    0040 - a4 6f f4 6c 2d 48 37 9f-33 b7 36 49 39 1f 2f 31   .o.l-H7.3.6I9./1
    0050 - 1a 0d 8f 8e 34 36 3d d1-09 fb 6b 5b 5d 68 80 3e   ....46=...k[]h.>
    0060 - 66 d9 44 11 4d 12 d5 cc-df eb c3 45 ae 04 10 56   f.D.M......E...V
    0070 - 34 ad 98 8f f9 1b f2 33-00 a4 b3 3c a5 40 80 8e   4......3...<.@..
    0080 - 9b f1 b5 40 e5 2b 29 86-7e 2b f6 95 03 4b e3 b4   ...@.+).~+...K..
    0090 - ab 16 25 bc 47 bf fb 87-dc 13 0e 10 a8 1b 18 fb   ..%.G...........
    00a0 - 3b 65 07 96 05 ce 1a c2-9a d4 d8 73 fd 38 40 8b   ;e.........s.8@.
    00b0 - 0e 52 df 26 19 fc 9f 04-06 28 b3 25 5c e2 64 51   .R.&.....(.%\.dQ

    Start Time: 1496212705
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
read:errno=0

Quel est ton problème réel @harry1064 ?

@Lukasa si vous voyez le résultat ci-dessus de la commande openssl s_client -connect api.quinto.ai:443 j'ai exécutée dans le conteneur docker exécuté sur mon serveur, vous verrez CN être fbbot.quintoapp.com qui pointe vers le serveur hôte sur lequel mon conteneur docker s'exécute.
Mais la même commande que j'ai exécutée sur le serveur hôte, CN était api.quinto.ai.
Donc, fondamentalement, j'ai un serveur python exécuté sur un conteneur docker et je souhaite faire une demande à un autre serveur api.quinto.ai mais je ne suis pas en mesure de le faire en utilisant des demandes. Le même code python que j'ai exécuté sur l'interpréteur sur la machine hôte, cela fonctionne bien, mais lorsque je me connecte au conteneur Docker et que j'exécute le même code depuis l'interpréteur python, cela ne fonctionne pas

Par défaut, OpenSSL s_client ne présente pas le champ d'indication du nom du serveur, ce qui signifie que le serveur distant présentera le certificat de son choix. Obtenez-vous le même résultat dans les deux cas si vous modifiez votre commande en :

openssl s_client -connect api.quinto.ai:443 -servername api.quinto.ai

Même si vous ne le faites pas, cela ressemble à un problème avec docker, pas avec Requests : vous semblez reproduire un problème en utilisant la ligne de commande openssl, qui n'utilise en aucune façon Requests. Je ne sais donc pas comment vous voulez que nous résolvions votre problème.

J'ai eu la même réponse avec les deux cas. Je pense donc aussi que c'est le problème avec docker car ils utilisent peut-être le mappage entre iptables.

Peut-être que cela peut aider quelqu'un. Pour moi, j'avais besoin d'installer ceci:

OpenSSL 1.0.2g 1 mars 2016

requests[security]==2.7.0  # not 2.18.x
cryptography==1.9   # not 2.0

Cette discussion est devenue caduque il y a des mois. Je ferme ça. Nous pouvons le rouvrir si nécessaire.

@harry1064 @javixeneize avez-vous trouvé une solution pour cela ? Je suis avec le même problème et peut-être que cela peut être un problème Docker. Mais je ne sais vraiment pas comment surmonter ça...

Merci!

Non...

El El jue, 11 ene 2018 a las 14:11, Gabriel Gularte <
[email protected]> inscription :

@harry1064 https://github.com/harry1064 @javixeneize
https://github.com/javixeneize avez-vous trouvé une solution pour
cette? Je suis avec le même problème et peut-être que cela peut être un problème Docker. Mais
Je ne sais vraiment pas comment surmonter ça...

Merci!

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/requests/requests/issues/3948#issuecomment-356944272 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AMK55roWfMLccuizdHkWQTTOq2gU3BXMks5tJhYegaJpZM4Mvjzc
.

essayez d'installer ces versions :

requests[security]==2.7.0
cryptography==1.9
pyOpenSSL==17.4.0

Bonjour ,
J'ai eu un problème similaire, après être passé aux versions mentionnées ci-dessus, tout s'est bien passé ( python 3.6 )