Requests: Solicitações que não funcionam em um contêiner Docker

Você pode executar openssl version em seu contêiner?

Isso também pode estar definitivamente relacionado à versão Python, gostaríamos de saber disso também.

Oi

Python 2.7 (12)
Openssl 1.0.2g

Obrigado

Você está executando a mesma versão de Requests no contêiner e fora dela? Quais são as duas versões?

2.11.1 ao trabalhar, e 2..12.5 dentro do contêiner. Isso faz alguma diferença?

Sim, existem algumas mudanças de código decentes entre essas duas versões. Quer tentar fazer o downgrade para 2.11 rapidamente no contêiner para ver o que acontece?

Ainda falhando, mas com uma mensagem de erro diferente
...
...
Arquivo "/usr/local/lib/python2.7/dist-packages/requests/adapters.py", linha 491, em envio
aumentar SSLError (e, solicitação = solicitação)
SSLError: EOF ocorreu em violação do protocolo (_ssl.c: 590)

Hrm. Esse erro diferente é praticamente o mesmo erro. Você pode nos revelar qual servidor da web está tentando entrar em contato?

Esse é o meu próprio servidor, que possui um certificado autoassinado. Estou enviando verificar = Falso para ignorar SSL, mas não parece gostar

resposta = sess.post (url, params, cabeçalhos = h, verificar = Falso)

Você pode mostrar a configuração de TLS para o seu servidor e a qual versão do OpenSSL ele está vinculado?

Seu TLS 1.2 e a mesma versão openSSL ... nada de especial. Não acho que haja
há algo errado no lado do servidor, pois funciona bem fora do docker
recipiente

Na sexta-feira, 31 de março de 2017 às 16h07, Cory Benfield [email protected]
escreveu:

Você pode mostrar a configuração TLS para o seu servidor, e o que OpenSSL
versão contra a qual ele está vinculado?

-
Você está recebendo isto porque é o autor do tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kennethreitz/requests/issues/3948#issuecomment-290738188 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AMK55o2K5PaiflW3wHWD_rZYm_WFXXGyks5rrRa6gaJpZM4Mvjzc
.

Portanto, "errado" aqui é definido apenas se houver uma incompatibilidade entre o que o cliente e o servidor esperam. Sem interesse, seu servidor espera SNI? Você está acessando seu servidor via hostname ou IP?

Nesse contêiner, você pode enrolar seu servidor com a mesma URL? Ou apenas telnet para ele? Eu me pergunto se as solicitações podem até mesmo chegar ao servidor de onde você implantou o contêiner.

Oi

Em resposta a ambos. ele espera SNI e eu o alcanço via hostname

Do contêiner, posso telnetar para o servidor, não há problema com
naquela. Eu expus outro serviço via http e ele funciona bem, é puramente
o handshake SSL o que está falhando

Na sexta-feira, 31 de março de 2017 às 16:16, Ian Cordasco [email protected]
escreveu:

Nesse contêiner, você pode enrolar seu servidor com a mesma URL? Ou mesmo
apenas telnet para ele? Eu me pergunto se as solicitações podem chegar ao servidor de
onde você implantou o contêiner.

-
Você está recebendo isto porque é o autor do tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kennethreitz/requests/issues/3948#issuecomment-290740743 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AMK55kVKzprqGA1n1PKJznWX_g_V7nsxks5rrRi-gaJpZM4Mvjzc
.

Ok, qual é o resultado de executar openssl s_client -connect host:port em seu servidor de dentro do contêiner?

Oi

Ele se conecta sem nenhum problema (conectado (00003))

Na sexta-feira, 31 de março de 2017 às 16:19, Cory Benfield [email protected]
escreveu:

Ok, qual é o resultado de executar openssl s_client -connect host: port para
seu servidor de dentro do contêiner?

-
Você está recebendo isto porque é o autor do tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kennethreitz/requests/issues/3948#issuecomment-290741631 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AMK55oeDzw5HhrujLbMFLA6CCowT0umwks5rrRmLgaJpZM4Mvjzc
.

Desculpe, o resultado completo . Estou interessado em saber qual é o resultado da negociação.

Verifique o código de retorno: 19 (certificado autoassinado na cadeia de certificados)

Na sexta-feira, 31 de março de 2017 às 16:34, Cory Benfield [email protected]
escreveu:

Desculpe, o resultado completo . Estou interessado em qual é o resultado do
negociação é.

-
Você está recebendo isto porque é o autor do tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kennethreitz/requests/issues/3948#issuecomment-290746053 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AMK55o4JyAkpP5h1ZPLBOkRONN2z9Em8ks5rrRz-gaJpZM4Mvjzc
.

Esse não é todo o resultado. Copie e cole tudo desse comando.

Não, todo o resultado. Todas as saídas. Tudo que ele imprime.

Não há nada mais interessante lá, apenas a versão tls, informações cert etc ...

Estou tendo exatamente a mesma resposta fora do contêiner
El El vie, 31 de março de 2017 às 16:40, Cory Benfield [email protected]
escribió:

Não, todo o resultado. Todas as saídas. Tudo que ele imprime.

-
Você está recebendo isto porque é o autor do tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kennethreitz/requests/issues/3948#issuecomment-290747930 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AMK55iD8dY2eDxdfz1j0YzpteN8ThFJ3ks5rrR58gaJpZM4Mvjzc
.

Essa informação é exatamente o que me interessa. Algo em nosso TLS Client Hello está deixando seu servidor louco, então estou interessado em ver o que seu servidor está negociando.

Ok, vamos fazer algo para ter certeza de que não é meu certificado. Vou procurar qualquer
outra página que usa um certificado autoassinado (se você souber de algum, por favor
compartilhar) e vou tentar contra isso, então você será capaz de conectar isso
servidor também

El El vie, 31 de março de 2017 às 16:46, Cory Benfield [email protected]
escribió:

Essa informação é exatamente o que me interessa. Algo em nosso TLS
O Hello do cliente está deixando seu servidor louco, por isso estou interessado em ver
o que seu servidor está negociando.

-
Você está recebendo isto porque é o autor do tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kennethreitz/requests/issues/3948#issuecomment-290749603 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AMK55oT_6jlrkIO4VlXRsoohjEGzNy3pks5rrR_TgaJpZM4Mvjzc
.

Não é o seu certificado. A mensagem de erro em questão (EOF inesperado) significa que durante o handshake TLS o servidor nos enviou um pacote TCP FIN ou RST. Isso significa que o servidor optou por encerrar a conexão, não nós. Isso significa que o servidor decidiu que não estamos fazendo algo de que ele gosta. Portanto, a culpa não pode ser do seu certificado: ainda não chegamos ao ponto de validá-lo.

@javixeneize sem as informações que pedimos, não tenho certeza do que mais podemos fazer para ajudar.

Ok ok ... vou providenciar isso na segunda
El El vie, 31 de março de 2017 a las 17:19, Ian Cordasco [email protected]
escribió:

@javixeneize https://github.com/javixeneize sem as informações
pedimos, não tenho certeza do que mais podemos fazer para ajudar.

-
Você está recebendo isso porque foi mencionado.

Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kennethreitz/requests/issues/3948#issuecomment-290759070 ,
ou silenciar o tópico
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

Qual é o seu problema real @ harry1064?

@Lukasa se você ver o resultado acima do comando openssl s_client -connect api.quinto.ai:443 que executei dentro do contêiner do docker em execução no meu servidor, verá que o CN é fbbot.quintoapp.com, que está apontando para o servidor host onde meu contêiner do docker está sendo executado.
Mas o mesmo comando que executei no servidor host, CN era api.quinto.ai.
Basicamente, tenho um servidor Python em execução no docker container e quero fazer uma solicitação a outro servidor api.quinto.ai, mas não consigo fazer isso usando as solicitações. O mesmo código python que executei no interpretador na máquina host, que está funcionando bem, mas quando eu entro no contêiner do docker e executei o mesmo código de dentro do interpretador python, não está funcionando

Por padrão, o OpenSSL s_client não apresenta o campo de indicação do nome do servidor, o que significa que o servidor remoto apresentará qualquer certificado que escolher. Você obtém a mesma saída em ambos os casos se alterar o comando para:

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

Mesmo se você não fizer isso, isso soa como um problema com o docker, não com Requests: você parece estar reproduzindo um problema usando a linha de comando do openssl, que não usa Requests de forma alguma. Portanto, não tenho certeza de como você deseja que resolvamos seu problema.

Eu obtive a mesma resposta com ambos os casos. Então eu também acho que esse é o problema com o docker, pois eles talvez estejam usando o mapeamento entre iptables.

Talvez isso possa ajudar alguém. Para mim, eu precisava instalar isso:

OpenSSL 1.0.2g 1 de março de 2016

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

Essa discussão ficou obsoleta meses atrás. Estou fechando isso. Podemos reabri-lo se necessário.

@ harry1064 @javixeneize vocês encontraram uma solução para isso? Estou com o mesmo problema e talvez seja um problema do Docker. Mas eu realmente não sei como superar isso ...

Obrigado!

Não...

El El jue, 11 de abril de 2018 a las 14:11, Gabriel Gularte <
notificaçõ[email protected]> escribió:

@ harry1064 https://github.com/harry1064 @javixeneize
https://github.com/javixeneize vocês encontraram uma solução para
isto? Estou com o mesmo problema e talvez seja um problema do Docker. Mas
Eu realmente não sei como superar isso ...

Obrigado!

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/requests/requests/issues/3948#issuecomment-356944272 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AMK55roWfMLccuizdHkWQTTOq2gU3BXMks5tJhYegaJpZM4Mvjzc
.

tente instalar estas versões:

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

Olá ,
Tive um problema semelhante, depois de degradar para as versões mencionadas acima, tudo correu bem ( python 3.6 )