Requests: Solicitudes que no funcionan en un contenedor Docker

Creado en 31 mar. 2017  ·  37Comentarios  ·  Fuente: psf/requests

Hola

Esa es la vieja historia de que SSL no funciona con solicitudes, sino un paso más allá ... Contenedores Docker

Tengo una aplicación que usa solicitudes y funciona bien en mi máquina local, pero, al implementarla en un contenedor Docker, tengo un error con el módulo de solicitudes (error SSL)

[2017-03-31 11: 32: 29,863] ERROR en la aplicación: Excepción en / enviar [POST]
Rastreo (llamadas recientes más última):
Archivo "/usr/local/lib/python2.7/dist-packages/flask/app.py", línea 1982, en wsgi_app
respuesta = self.full_dispatch_request ()
Archivo "/usr/local/lib/python2.7/dist-packages/flask/app.py", línea 1614, en full_dispatch_request
rv = self.handle_user_exception (e)
Archivo "/usr/local/lib/python2.7/dist-packages/flask/app.py", línea 1517, en handle_user_exception
volver a subir (exc_type, exc_value, tb)
Archivo "/usr/local/lib/python2.7/dist-packages/flask/app.py", línea 1612, en full_dispatch_request
rv = self.dispatch_request ()
Archivo "/usr/local/lib/python2.7/dist-packages/flask/app.py", línea 1598, en dispatch_request
return self.view_functions rule.endpoint
Archivo "app.py", línea 62, en sendrequest
response = sess.post (url, params, headers = h, verify = False)
Archivo "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", línea 535, en la publicación
return self.request ('POST', url, data = data, json = json, * kwargs)Archivo "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", línea 488, en solicitudresp = self.send (preparación, * send_kwargs)
Archivo "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", línea 609, en enviar
r = adaptador.enviar (solicitud, ** kwargs)
Archivo "/usr/local/lib/python2.7/dist-packages/requests/adapters.py", línea 497, en enviar
aumentar SSLError (e, solicitud = solicitud)
SSLError: ("apretón de manos incorrecto: SysCallError (-1, 'EOF inesperado')",)

He oído que podría estar relacionado con openSSL. ¿Alguna idea de cómo se puede resolver esto? ¿Debería incluir alguna dependencia?

Comentario más útil

intente instalar estas versiones:

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

Todos 37 comentarios

¿Puede ejecutar openssl version en su contenedor?

Esto definitivamente también puede estar relacionado con la versión de Python, también nos gustaría saberlo.

Hola

Python 2.7 (12)
Openssl 1.0.2g

Gracias

¿Está ejecutando la misma versión de Solicitudes en el contenedor y fuera? ¿Cuáles son las dos versiones?

2.11.1 al trabajar, y 2..12.5 dentro del contenedor. ¿Hace alguna diferencia?

Sí, hay algunos cambios de código decentes entre esas dos versiones. ¿Quiere intentar bajar de categoría a 2.11 rápidamente en el contenedor para ver qué sucede?

Sigue fallando, pero con un mensaje de error diferente
...
...
Archivo "/usr/local/lib/python2.7/dist-packages/requests/adapters.py", línea 491, en enviar
aumentar SSLError (e, solicitud = solicitud)
SSLError: EOF se produjo en violación del protocolo (_ssl.c: 590)

Hrm. Ese error diferente es prácticamente el mismo error. ¿Puede revelarnos con qué servidor web está tratando de contactar?

Ese es mi propio servidor, que tiene un certificado autofirmado. Estoy enviando verify = False para ignorar SSL pero no parece gustarle

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

¿Puede mostrar la configuración de TLS para su servidor y con qué versión de OpenSSL está vinculada?

Su TLS 1.2 y la misma versión openSSL ... nada especial. No creo que haya
hay algo mal en el lado del servidor, ya que funciona bien fuera de la ventana acoplable
envase

El viernes 31 de marzo de 2017 a las 4:07 p.m., Cory Benfield [email protected]
escribió:

¿Puede mostrar la configuración de TLS para su servidor y qué OpenSSL
versión a la que está vinculado?

-
Estás recibiendo esto porque eres el autor del hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/kennethreitz/requests/issues/3948#issuecomment-290738188 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AMK55o2K5PaiflW3wHWD_rZYm_WFXXGyks5rrRa6gaJpZM4Mvjzc
.

Entonces, "incorrecto" aquí se define solo en si hay una discrepancia entre lo que esperan el cliente y el servidor. Por interés, ¿su servidor espera SNI? ¿Está llegando a su servidor a través del nombre de host o IP?

En ese contenedor, ¿puede curvar su servidor con la misma URL? ¿O simplemente telnet? Me pregunto si las solicitudes pueden llegar al servidor desde donde ha implementado el contenedor.

Hola

En respuesta a ambos. espera SNI y lo alcanzo a través del nombre de host

Desde el contenedor puedo hacer telnet al servidor, no hay problema con
ese. He expuesto otro servicio a través de http y funciona bien, es puramente
el protocolo de enlace SSL lo que está fallando

El viernes 31 de marzo de 2017 a las 4:16 p.m., Ian Cordasco [email protected]
escribió:

En ese contenedor, ¿puede curvar su servidor con la misma URL? O incluso
sólo telnet a él? Me pregunto si las solicitudes pueden llegar al servidor desde
donde ha desplegado el contenedor.

-
Estás recibiendo esto porque eres el autor del hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/kennethreitz/requests/issues/3948#issuecomment-290740743 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AMK55kVKzprqGA1n1PKJznWX_g_V7nsxks5rrRi-gaJpZM4Mvjzc
.

Ok, ¿cuál es el resultado de ejecutar openssl s_client -connect host:port en su servidor desde el interior del contenedor?

Hola

Se conecta sin ningún problema (conectado (00003))

El viernes 31 de marzo de 2017 a las 4:19 p.m., Cory Benfield [email protected]
escribió:

Ok, ¿cuál es el resultado de ejecutar openssl s_client -connect host: port to
su servidor desde el interior del contenedor?

-
Estás recibiendo esto porque eres el autor del hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/kennethreitz/requests/issues/3948#issuecomment-290741631 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AMK55oeDzw5HhrujLbMFLA6CCowT0umwks5rrRmLgaJpZM4Mvjzc
.

Lo siento, todo el resultado. Me interesa cuál es el resultado de la negociación.

Verifique el código de retorno: 19 (certificado autofirmado en la cadena de certificados)

El viernes 31 de marzo de 2017 a las 4:34 p.m., Cory Benfield [email protected]
escribió:

Lo siento, todo el resultado. Me interesa cuál es el resultado de la
la negociación es.

-
Estás recibiendo esto porque eres el autor del hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/kennethreitz/requests/issues/3948#issuecomment-290746053 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AMK55o4JyAkpP5h1ZPLBOkRONN2z9Em8ks5rrRz-gaJpZM4Mvjzc
.

Ese no es todo el resultado. Copie y pegue todo lo de ese comando.

No, todo el resultado. Toda la salida. Todo lo que imprime.

No hay nada más interesante allí, solo la versión tls, la información del certificado, etc.

Estoy teniendo exactamente la misma respuesta fuera del contenedor.
El El vie, 31 de marzo de 2017 a las 16:40, Cory Benfield [email protected]
escribió:

No, todo el resultado. Toda la salida. Todo lo que imprime.

-
Estás recibiendo esto porque eres el autor del hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/kennethreitz/requests/issues/3948#issuecomment-290747930 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AMK55iD8dY2eDxdfz1j0YzpteN8ThFJ3ks5rrR58gaJpZM4Mvjzc
.

Esa información es exactamente lo que me interesa. Algo en nuestro TLS Client Hello está volviendo loco a su servidor, por lo que estoy interesado en ver qué está negociando su servidor.

Ok, hagamos algo para asegurarnos de que no sea mi certificado. Buscaré cualquiera
otra página que utiliza un certificado autofirmado (si conoce alguno, por favor
compartir) e intentaré contra eso, para que puedas conectar eso
servidor también

El El vie, 31 de marzo de 2017 a las 16:46, Cory Benfield [email protected]
escribió:

Esa información es exactamente lo que me interesa. Algo en nuestro TLS
Client Hello está volviendo loco a su servidor, así que estoy interesado en ver
lo que está negociando su servidor.

-
Estás recibiendo esto porque eres el autor del hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/kennethreitz/requests/issues/3948#issuecomment-290749603 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AMK55oT_6jlrkIO4VlXRsoohjEGzNy3pks5rrR_TgaJpZM4Mvjzc
.

No es tu certificado. El mensaje de error en cuestión (EOF inesperado) significa que durante el protocolo de enlace TLS el servidor nos ha enviado un paquete TCP FIN o RST. Eso significa que el servidor ha elegido cerrar la conexión, no nosotros. Eso significa que el servidor ha decidido que no estamos haciendo algo que le guste. Como resultado, esto no puede ser culpa de su certificado: aún no hemos llegado al punto de validarlo.

@javixeneize sin la información que le hemos pedido, no estoy seguro de qué más podemos hacer para ayudar.

Ok ok ... te lo proporcionaré el lunes
El El vie, 31 de marzo de 2017 a las 17:19, Ian Cordasco [email protected]
escribió:

@javixeneize https://github.com/javixeneize sin la información
le hemos pedido, no estoy seguro de qué más podemos hacer para ayudar.

-
Recibes esto porque te mencionaron.

Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/kennethreitz/requests/issues/3948#issuecomment-290759070 ,
o silenciar el hilo
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

¿Cuál es tu problema real @ harry1064?

@Lukasa si ve el resultado anterior del comando openssl s_client -connect api.quinto.ai:443 ejecuté dentro del contenedor de la ventana acoplable que se ejecuta en mi servidor, verá que CN es fbbot.quintoapp.com, que apunta al servidor host donde se está ejecutando mi contenedor de la ventana acoplable.
Pero el mismo comando que ejecuté en el servidor host, CN fue api.quinto.ai.
Básicamente, tengo un servidor Python ejecutándose en un contenedor Docker y quiero hacer una solicitud a otro servidor api.quinto.ai, pero no puedo hacerlo usando solicitudes. El mismo código de Python que ejecuté en el intérprete en la máquina host, que funciona bien, pero cuando inicio sesión en el contenedor de la ventana acoplable y ejecuté el mismo código desde el interior del intérprete de Python, no funciona

De forma predeterminada, OpenSSL s_client no presenta el campo de indicación del nombre del servidor, lo que significa que el servidor remoto presentará el certificado que elija. ¿Obtiene el mismo resultado en ambos casos si cambia su comando a:

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

Incluso si no lo hace, esto suena como un problema con la ventana acoplable, no con las solicitudes: parece que está reproduciendo un problema utilizando la línea de comando openssl, que no usa las solicitudes de ninguna manera. Así que no estoy seguro de cómo quiere que solucionemos su problema.

Obtuve la misma respuesta en ambos casos. Así que también creo que este es el problema con la ventana acoplable, ya que tal vez estén usando el mapeo entre iptables.

Quizás esto pueda ayudar a alguien. Para mí, necesitaba instalar esto:

OpenSSL 1.0.2g 1 de marzo de 2016

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

Esta discusión se estancó hace meses. Estoy cerrando esto. Podemos reabrirlo si es necesario.

@ harry1064 @javixeneize , ¿han encontrado una solución para esto? Estoy con el mismo problema y tal vez esto pueda ser un problema de Docker. Pero realmente no sé cómo superar esto ...

¡Gracias!

No...

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

@ harry1064 https://github.com/harry1064 @javixeneize
https://github.com/javixeneize , chicos, han encontrado una solución para
¿esta? Estoy con el mismo problema y tal vez esto pueda ser un problema de Docker. Pero
Realmente no sé cómo superar esto ...

¡Gracias!

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/requests/requests/issues/3948#issuecomment-356944272 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AMK55roWfMLccuizdHkWQTTOq2gU3BXMks5tJhYegaJpZM4Mvjzc
.

intente instalar estas versiones:

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

Hola ,
Tuve un problema similar, después de degradar a las versiones mencionadas anteriormente, todo salió bien ( python 3.6 )

¿Fue útil esta página
0 / 5 - 0 calificaciones