Requests: Requests not working in a Docker container

Can you run openssl version in your container?

This can also very definitely be related to the Python version, we'd like to know that as well.

Hi

Python 2.7 (12)
Openssl 1.0.2g

Thanks

Are you running the same version of Requests in the container and outside? What are the two versions?

2.11.1 when working, and 2..12.5 inside the container. Does it make any difference?

Yeah, there are some decent code changes between those two versions. Want to try downgrading to 2.11 quickly in the container to see what happens?

Still failing, but with a different error message
...
...
File "/usr/local/lib/python2.7/dist-packages/requests/adapters.py", line 491, in send
raise SSLError(e, request=request)
SSLError: EOF occurred in violation of protocol (_ssl.c:590)

Hrm. That different error is pretty much the same error. Can you reveal to us what web server you're trying to contact?

Thats my own server, which has a self signed certificate. I am sending verify=False to ignore SSL but doesnt seem to like it

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

Can you show the TLS configuration for your server, and what OpenSSL version it is linked against?

Its TLS 1.2 and same openSSL version... nothing special. I dont think there
is anything wrong on server side as it works fine outside the docker
container

On Fri, Mar 31, 2017 at 4:07 PM, Cory Benfield notifications@github.com
wrote:

Can you show the TLS configuration for your server, and what OpenSSL
version it is linked against?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/kennethreitz/requests/issues/3948#issuecomment-290738188,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMK55o2K5PaiflW3wHWD_rZYm_WFXXGyks5rrRa6gaJpZM4Mvjzc
.

So, "wrong" here is defined only in whether there is a mismatch between what the client and server expect. Out of interest, does your server expect SNI? Are you reaching your server via hostname or IP?

In that container, can you curl your server with the same URL? Or even just telnet to it? I wonder if requests can even reach the server from where you've deployed the container.

Hi

In response to both. it expects SNI and i reach it via hostname

From the container i can telnet to the server, there is no problem with
that. I have exposed another service via http and it works fine, its purely
the SSL handshake what is failing

On Fri, Mar 31, 2017 at 4:16 PM, Ian Cordasco notifications@github.com
wrote:

In that container, can you curl your server with the same URL? Or even
just telnet to it? I wonder if requests can even reach the server from
where you've deployed the container.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/kennethreitz/requests/issues/3948#issuecomment-290740743,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMK55kVKzprqGA1n1PKJznWX_g_V7nsxks5rrRi-gaJpZM4Mvjzc
.

Ok, what's the result of running openssl s_client -connect host:port to your server from inside the container?

Hi

It connects without any issue (connected(00003))

On Fri, Mar 31, 2017 at 4:19 PM, Cory Benfield notifications@github.com
wrote:

Ok, what's the result of running openssl s_client -connect host:port to
your server from inside the container?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/kennethreitz/requests/issues/3948#issuecomment-290741631,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMK55oeDzw5HhrujLbMFLA6CCowT0umwks5rrRmLgaJpZM4Mvjzc
.

Sorry, the whole result. I'm interested in what the result of the negotiation is.

Verify return code: 19 (self signed certificate in certificate chain)

On Fri, Mar 31, 2017 at 4:34 PM, Cory Benfield notifications@github.com
wrote:

Sorry, the whole result. I'm interested in what the result of the
negotiation is.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/kennethreitz/requests/issues/3948#issuecomment-290746053,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMK55o4JyAkpP5h1ZPLBOkRONN2z9Em8ks5rrRz-gaJpZM4Mvjzc
.

That is not the whole result. Please copy and paste everything from that command.

No, the whole result. All the output. Everything it prints.

There is nothing else interesting there, just tls version, cert info etc...

Im having exactly the same response outside the container
El El vie, 31 mar 2017 a las 16:40, Cory Benfield notifications@github.com
escribió:

No, the whole result. All the output. Everything it prints.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/kennethreitz/requests/issues/3948#issuecomment-290747930,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMK55iD8dY2eDxdfz1j0YzpteN8ThFJ3ks5rrR58gaJpZM4Mvjzc
.

That information is exactly what I am interested in. Something in our TLS Client Hello is making your server mad, and so I'm interested in seeing what your server is negotiating.

Ok, lets do something to be sure its not my certificate. I will search any
other page that uses a self signed certificate ( if you know of any please
share) and i will try against that, so you will be able to connect that
server too

El El vie, 31 mar 2017 a las 16:46, Cory Benfield notifications@github.com
escribió:

That information is exactly what I am interested in. Something in our TLS
Client Hello is making your server mad, and so I'm interested in seeing
what your server is negotiating.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/kennethreitz/requests/issues/3948#issuecomment-290749603,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMK55oT_6jlrkIO4VlXRsoohjEGzNy3pks5rrR_TgaJpZM4Mvjzc
.

It's not your certificate. The error message in question (Unexpected EOF) means that during the TLS handshake the server has sent us a TCP FIN or RST packet. That means the server has chosen to close the connection, not us. That means the server has decided we are not doing something it likes. As a result, this cannot be the fault of your certificate: we haven't gotten to the point of validating it yet.

@javixeneize without the information we've asked you for, I'm not sure what else we can do to help.

Ok ok... i will provide that on monday
El El vie, 31 mar 2017 a las 17:19, Ian Cordasco notifications@github.com
escribió:

@javixeneize https://github.com/javixeneize without the information
we've asked you for, I'm not sure what else we can do to help.

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/kennethreitz/requests/issues/3948#issuecomment-290759070,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMK55ugTXZp-cZpp9JJJ7WmACcYXho2Rks5rrSeegaJpZM4Mvjzc
.

root@4f66ccbaef3c:/# 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

What's your actual problem @harry1064?

@Lukasa if you see the above result of openssl s_client -connect api.quinto.ai:443 command i ran inside docker container running on my server, You will see CN to be fbbot.quintoapp.com which is pointing to host server where my docker container is running.
But the same command i ran on host server, CN was api.quinto.ai.
So basically, i have a python server running on docker container and i want to make request to another server api.quinto.ai but I am not not able to do that using requests. Same python code i ran on interpreter on host machine, that is working fine but when i log in to docker container and ran same code from inside the python interpreter, its not working

By default OpenSSL s_client does not present the server name indication field, which means that the remote server will present whatever certificate it chooses. Do you get the same output in both cases if you change your command to:

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

Even if you don't, this sounds like a problem with docker, not with Requests: you appear to be reproducing a problem using the openssl command line, which doesn't use Requests in any way. So I'm not sure how you want us to solve your problem.

I got same response with both the cases. So i also think this is the problem with docker as they are maybe using mapping between iptables.

Maybe this can help someone. For me I needed to install this:

OpenSSL 1.0.2g 1 Mar 2016

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

This discussion went stale months ago. I'm closing this. We can reopen it if necessary.

@harry1064 @javixeneize do you guys have found a solution for this? I'm with the same problem and maybe this can be a Docker problem. But I really don't know how to overcome this...

Thanks!

Nope...

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 do you guys have found a solution for
this? I'm with the same problem and maybe this can be a Docker problem. But
I really don't know how to overcome this...

Thanks!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/requests/requests/issues/3948#issuecomment-356944272,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMK55roWfMLccuizdHkWQTTOq2gU3BXMks5tJhYegaJpZM4Mvjzc
.

try installing these versions:

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

Hello ,
I had similar problem , after degrading to the above mentioned versions everything went smoothly ( python 3.6 )