Requests: Anfragen funktionieren nicht in einem Docker-Container

Können Sie openssl version in Ihrem Container ausführen?

Das kann auch ganz sicher mit der Python-Version zusammenhängen, das würden wir auch gerne wissen.

Hi

Python 2.7 (12)
Openssl 1.0.2g

Vielen Dank

Führen Sie im Container und außerhalb dieselbe Version von Requests aus? Was sind die beiden Versionen?

2.11.1 beim Arbeiten und 2..12.5 im Container. Macht es einen Unterschied?

Ja, es gibt einige anständige Codeänderungen zwischen diesen beiden Versionen. Möchten Sie versuchen, im Container schnell auf 2.11 herunterzustufen, um zu sehen, was passiert?

Scheitert immer noch, aber mit einer anderen Fehlermeldung
...
...
Datei "/usr/local/lib/python2.7/dist-packages/requests/adapters.py", Zeile 491 in send
SSLError auslösen (e, request=request)
SSLError: EOF ist unter Verletzung des Protokolls aufgetreten (_ssl.c:590)

Hm. Dieser andere Fehler ist so ziemlich der gleiche Fehler. Können Sie uns verraten, mit welchem ​​Webserver Sie Kontakt aufnehmen möchten?

Das ist mein eigener Server, der ein selbstsigniertes Zertifikat hat. Ich sende verify=False, um SSL zu ignorieren, scheint es aber nicht zu mögen

response=sess.post(url,params, headers=h,verify=False)

Können Sie die TLS-Konfiguration für Ihren Server zeigen und mit welcher OpenSSL-Version sie verknüpft ist?

Es ist TLS 1.2 und dieselbe openSSL-Version ... nichts Besonderes. ich glaube da nicht
ist auf der Serverseite etwas falsch, da es außerhalb des Dockers einwandfrei funktioniert?
Container

Am Freitag, 31. März 2017 um 16:07 Uhr, Cory Benfield [email protected]
schrieb:

Können Sie die TLS-Konfiguration für Ihren Server zeigen und was OpenSSL
Version, gegen die es verlinkt ist?

—
Sie erhalten dies, weil Sie den Thread verfasst haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/kennethreitz/requests/issues/3948#issuecomment-290738188 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AMK55o2K5PaiflW3wHWD_rZYm_WFXXGyks5rrRa6gaJpZM4Mvjzc
.

"Falsch" wird hier also nur dadurch definiert, ob eine Diskrepanz zwischen den Erwartungen von Client und Server besteht. Erwartet Ihr Server aus Interesse SNI? Erreichst du deinen Server über Hostname oder IP?

Können Sie in diesem Container Ihren Server mit derselben URL zusammenführen? Oder einfach nur telnet dazu? Ich frage mich, ob Anfragen überhaupt den Server erreichen können, von dem aus Sie den Container bereitgestellt haben.

Hi

Als Reaktion auf beides. es erwartet SNI und ich erreiche es über den Hostnamen

Vom Container kann ich zum Server telnet, es gibt kein Problem mit
das. Ich habe einen anderen Dienst über http bereitgestellt und es funktioniert gut, es ist rein
der SSL-Handshake, was fehlschlägt

Am Freitag, 31. März 2017 um 16:16 Uhr, Ian Cordasco [email protected]
schrieb:

Können Sie in diesem Container Ihren Server mit derselben URL zusammenführen? Oder auch
einfach telnet dazu? Ich frage mich, ob Anfragen überhaupt den Server erreichen können von
wo Sie den Container bereitgestellt haben.

—
Sie erhalten dies, weil Sie den Thread verfasst haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/kennethreitz/requests/issues/3948#issuecomment-290740743 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AMK55kVKzprqGA1n1PKJznWX_g_V7nsxks5rrRi-gaJpZM4Mvjzc
.

Ok, was ist das Ergebnis, wenn Sie openssl s_client -connect host:port aus dem Container auf Ihren Server ausführen?

Hi

Es verbindet sich ohne Probleme (connected(00003))

Am Freitag, 31. März 2017 um 16:19 Uhr, Cory Benfield [email protected]
schrieb:

Ok, was ist das Ergebnis der Ausführung von openssl s_client -connect host:port to
Ihr Server aus dem Container?

—
Sie erhalten dies, weil Sie den Thread verfasst haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/kennethreitz/requests/issues/3948#issuecomment-290741631 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AMK55oeDzw5HhrujLbMFLA6CCowT0umwks5rrRmLgaJpZM4Mvjzc
.

Entschuldigung, das ganze Ergebnis. Mich interessiert das Ergebnis der Verhandlungen.

Rückgabecode verifizieren: 19 (selbstsigniertes Zertifikat in der Zertifikatskette)

Am Freitag, 31. März 2017 um 16:34 Uhr, Cory Benfield [email protected]
schrieb:

Entschuldigung, das ganze Ergebnis. Mich interessiert, was das Ergebnis der
Verhandlung ist.

—
Sie erhalten dies, weil Sie den Thread verfasst haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/kennethreitz/requests/issues/3948#issuecomment-290746053 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AMK55o4JyAkpP5h1ZPLBOkRONN2z9Em8ks5rrRz-gaJpZM4Mvjzc
.

Das ist nicht das ganze Ergebnis. Bitte kopieren Sie alles aus diesem Befehl und fügen Sie es ein.

Nein, das ganze Ergebnis. Die ganze Ausgabe. Alles, was es druckt.

Es gibt dort nichts anderes Interessantes, nur tls-Version, Zertifikatsinfo usw...

Ich habe genau die gleiche Antwort außerhalb des Containers
El El vie, 31. März 2017 um 16:40 Uhr, Cory Benfield [email protected]
Beschreibung:

Nein, das ganze Ergebnis. Die ganze Ausgabe. Alles, was es druckt.

—
Sie erhalten dies, weil Sie den Thread verfasst haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/kennethreitz/requests/issues/3948#issuecomment-290747930 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AMK55iD8dY2eDxdfz1j0YzpteN8ThFJ3ks5rrR58gaJpZM4Mvjzc
.

Diese Informationen sind genau das, was mich interessiert. Etwas in unserem TLS Client Hello macht Ihren Server wütend, und deshalb bin ich daran interessiert zu sehen, was Ihr Server verhandelt.

Ok, lassen Sie uns etwas tun, um sicherzugehen, dass es nicht mein Zertifikat ist. ich werde jeden suchen
andere Seite, die ein selbstsigniertes Zertifikat verwendet (wenn Sie eines wissen, bitte
teilen) und ich werde dagegen versuchen, damit du das verbinden kannst
Server auch

El El vie, 31. März 2017 um 16:46 Uhr, Cory Benfield [email protected]
Beschreibung:

Genau diese Informationen interessieren mich. Etwas in unserem TLS
Client Hello macht Ihren Server wütend, und deshalb bin ich daran interessiert, zu sehen
was Ihr Server verhandelt.

—
Sie erhalten dies, weil Sie den Thread verfasst haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/kennethreitz/requests/issues/3948#issuecomment-290749603 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AMK55oT_6jlrkIO4VlXRsoohjEGzNy3pks5rrR_TgaJpZM4Mvjzc
.

Es ist nicht Ihr Zertifikat. Die fragliche Fehlermeldung (Unexpected EOF) bedeutet, dass der Server uns während des TLS-Handshakes ein TCP-FIN- oder RST-Paket geschickt hat. Das bedeutet, dass der Server entschieden hat, die Verbindung zu schließen, nicht wir. Das bedeutet, dass der Server entschieden hat, dass wir etwas nicht tun, was ihm gefällt. An Ihrem Zertifikat kann dies also nicht liegen: Wir sind noch nicht so weit, es zu validieren.

@javixeneize Ohne die Informationen, um die wir Sie gebeten haben, bin ich mir nicht sicher, was wir sonst tun können, um zu helfen.

Ok ok... das werde ich am Montag nachreichen
El El vie, 31. März 2017 um 17:19 Uhr, Ian Cordasco [email protected]
Beschreibung:

@javixeneize https://github.com/javixeneize ohne die Informationen
Wir haben Sie darum gebeten, ich bin mir nicht sicher, was wir sonst tun können, um zu helfen.

—
Sie erhalten dies, weil Sie erwähnt wurden.

Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/kennethreitz/requests/issues/3948#issuecomment-290759070 ,
oder den Thread stumm schalten
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

Was ist dein eigentliches Problem @harry1064?

@Lukasa Wenn Sie das obige Ergebnis des Befehls openssl s_client -connect api.quinto.ai:443 ich in einem Docker-Container ausgeführt habe, der auf meinem Server ausgeführt wird, sehen Sie, dass CN fbbot.quintoapp.com ist, der auf den Hostserver verweist, auf dem mein Docker-Container ausgeführt wird.
Aber der gleiche Befehl, den ich auf dem Hostserver ausgeführt habe, war CN api.quinto.ai.
Im Grunde habe ich also einen Python-Server, der auf einem Docker-Container ausgeführt wird, und möchte eine Anfrage an einen anderen Server api.quinto.ai stellen, aber ich kann dies nicht mit Anfragen tun. Derselbe Python-Code, den ich auf dem Interpreter auf dem Host-Rechner ausgeführt habe, funktioniert gut, aber wenn ich mich beim Docker-Container anmelde und denselben Code aus dem Python-Interpreter heraus ausführe, funktioniert es nicht

Standardmäßig zeigt OpenSSL s_client das Feld zur Angabe des Servernamens nicht an, was bedeutet, dass der entfernte Server das von ihm gewählte Zertifikat präsentiert. Erhalten Sie in beiden Fällen die gleiche Ausgabe, wenn Sie Ihren Befehl ändern in:

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

Selbst wenn Sie dies nicht tun, klingt dies nach einem Problem mit Docker, nicht nach Requests: Sie scheinen ein Problem mit der openssl-Befehlszeile zu reproduzieren, die Requests in keiner Weise verwendet. Ich bin mir also nicht sicher, wie wir Ihr Problem lösen sollen.

Ich habe in beiden Fällen die gleiche Antwort erhalten. Ich denke auch, dass dies das Problem mit Docker ist, da sie möglicherweise die Zuordnung zwischen iptables verwenden.

Vielleicht kann das jemandem helfen. Bei mir musste ich das installieren:

OpenSSL 1.0.2g 1. März 2016

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

Diese Diskussion ist seit Monaten veraltet. Ich schließe das. Wir können es bei Bedarf wieder öffnen.

@harry1064 @javixeneize habt ihr eine lösung dafür gefunden? Ich habe das gleiche Problem und vielleicht kann dies ein Docker-Problem sein. Aber ich weiß wirklich nicht, wie ich das überwinden soll...

Danke!

NÖ...

El El Jue, 11. Dezember 2018 um 14:11 Uhr, Gabriel Gularte <
[email protected]> escribió:

@harry1064 https://github.com/harry1064 @javixeneize
https://github.com/javixeneize habt ihr eine Lösung gefunden für
Dies? Ich habe das gleiche Problem und vielleicht kann dies ein Docker-Problem sein. Aber
ich weiß echt nicht wie ich das überwinden soll...

Danke!

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/requests/requests/issues/3948#issuecomment-356944272 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AMK55roWfMLccuizdHkWQTTOq2gU3BXMks5tJhYegaJpZM4Mvjzc
.

Versuchen Sie, diese Versionen zu installieren:

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

Hallo ,
Ich hatte ein ähnliches Problem, nach dem Degradieren auf die oben genannten Versionen lief alles reibungslos ( python 3.6 )