0
Ich bin mit dem folgenden Fall fest: beim Aufruf eines HTTPS-Links von Python und requests, bekomme ich eine Zeitüberschreitung auf meinem Ubuntu Laptop, sowie auf Linuxes I ' Ich habe es in VirtualBox und einem anderen Laptop versucht. Derselbe Python-Code gibt jedoch eine gültige Antwort unter Windows 7, Mac OS X und dem neuesten FreeBSD-System zurück. Das Problem tauchte vor ungefähr zwei Wochen auf, und ich vermute, dass es wahrscheinlich daran lag, dass etwas auf dem Server geändert wurde, was sich nur auf den Linux-Netzwerk-Stack auswirkte. Irgendwelche Ideen, warum es tatsächlich passieren kann und wie man es beheben kann, sind willkommen.SSL-Timeout beim Aufruf einer URL über Python und Anfragen
Unten sind die Details.
- Python-Version die ich verwendet habe: neueste, 2.7.11
requestsVersion: 2.10- Betriebssysteme Ich habe versucht: Ubuntu 16.04, Ubuntu 15.10, 23 Fedora, CentOS 6, Windows 7, FreeBSD, Mac OS X
Hinweis: alle wesentlichen Daten unten wurde wegen NDA übersprungen.
Der eigentliche Python-Code, der fehlschlägt:
import requests
import logging
import httplib as http_client
import ssl
http_client.HTTPConnection.debuglevel = 1
logging.basicConfig()
logging.getLogger().setLevel(logging.DEBUG)
requests_log = logging.getLogger("requests.packages.urllib3")
requests_log.setLevel(logging.DEBUG)
requests_log.propagate = True
url = 'https://subdomain.example1.com/products/12345'
cert = ('example.pem', 'example.key')
response = requests.get(url=url,
params={'locale': 'en_US'},
headers={'Content-Type': 'application/x-www-form-urlencoded', 'Accept': 'application/json'},
timeout=10.0,
cert=cert,
verify=False,
cookies=None)
print response
Ergebnis den Code oben auf Linux-Versionen ausgeführt wird:
$ python req.py
INFO:requests.packages.urllib3.connectionpool:Starting new HTTPS connection (1): subdomain.example1.com
Traceback (most recent call last):
File "req.py", line 23, in <module>
cookies=None)
File "/usr/local/lib/python2.7/dist-packages/requests/api.py", line 67, in get
return request('get', url, params=params, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/requests/api.py", line 53, in request
return session.request(method=method, url=url, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 468, in request
resp = self.send(prep, **send_kwargs)
File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 576, in send
r = adapter.send(request, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/requests/adapters.py", line 449, in send
raise ReadTimeout(e, request=request)
requests.exceptions.ReadTimeout: HTTPSConnectionPool(host='subdomain.example1.com', port=443): Read timed out. (read timeout=10.0)
Ergebnis des gleichen Code auf Linux mit Timeout auf 300,0:
$ python req.py
INFO:requests.packages.urllib3.connectionpool:Starting new HTTPS connection (1): subdomain.example1.com
Traceback (most recent call last):
File "req.py", line 23, in <module>
cookies=None)
File "/usr/local/lib/python2.7/dist-packages/requests/api.py", line 67, in get
return request('get', url, params=params, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/requests/api.py", line 53, in request
return session.request(method=method, url=url, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 468, in request
resp = self.send(prep, **send_kwargs)
File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 576, in send
r = adapter.send(request, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/requests/adapters.py", line 447, in send
raise SSLError(e, request=request)
requests.exceptions.SSLError: ("bad handshake: Error([('SSL routines', 'ssl3_read_bytes', 'sslv3 alert unexpected message')],)",)
Ein korrektes Python-Code-Run-Ergebnis aus FreeBSD:
$ python req.py
INFO:requests.packages.urllib3.connectionpool:Starting new HTTPS connection (1): subdomain.example1.com
/usr/local/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py:821: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html
InsecureRequestWarning)
send: 'GET /products/12345?locale=en_US HTTP/1.1\r\nHost: subdomain.example1.com\r\nConnection: keep-alive\r\nAccept-Encoding: gzip, deflate\r\nAccept: application/json\r\nUser-Agent: python-requests/2.10.0\r\nContent-Type: application/x-www-form-urlencoded\r\n\r\n'
reply: 'HTTP/1.1 200 OK\r\n'
header: Server: Apache-Coyote/1.1
header: Cache-Control: private
header: Expires: Wed, 31 Dec 1969 17:00:00 MST
header: Content-Type: application/json;charset=UTF-8
header: Transfer-Encoding: chunked
header: Date: Thu, 09 Jun 2016 16:13:37 GMT
DEBUG:requests.packages.urllib3.connectionpool:"GET /products/12345?locale=en_US HTTP/1.1" 200 None
<Response [200]>
Ein Versuch von openssl:
$ openssl s_client -connect subdomain.example1.com:443 -cert example.pem -key example.key
CONNECTED(00000003)
depth=2 CN = Root.Example2.com
verify return:1
depth=1 DC = com, DC = example3, CN = ca-example3
verify return:1
depth=0 ST = Colorado, L = Boulder, O = Example4.com, OU = WebOps, CN = *.example1.com
verify return:1
139622025893528:error:140943F2:SSL routines:ssl3_read_bytes:sslv3 alert unexpected message:s3_pkt.c:1472:SSL alert number 10
139622025893528:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:
---
Certificate chain
0 s:/ST=Colorado/L=Boulder/O=Example4.com/OU=WebOps/CN=*.example1.com
i:/DC=com/DC=example3/CN=ca-example3
---
Server certificate
-----BEGIN CERTIFICATE-----
........ SKIPPED .........
-----END CERTIFICATE-----
subject=/ST=Colorado/L=Boulder/O=Example4.com/OU=WebOps/CN=*.example1.com
issuer=/DC=com/DC=example3/CN=ca-example3
---
Acceptable client certificate CA names
/O=Example4.com/OU=WebOps/CN=cl_ABCDEFGHI
/O=Example4.com/OU=WebOps/CN=cl_QWERTYUIO
/CN=Root.Example2.com
/DC=com/DC=example3/CN=ca-example3
/O=Example4.com/OU=WebOps/CN=cl_ASDFGHJKL
/O=Example4.com/OU=WebOps/CN=cl_ZXCVBNabc
/O=Example4.com/OU=WebOps/CN=cl_poiuytrew
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: ECDSA+SHA512:RSA+SHA512:ECDSA+SHA384:RSA+SHA384:ECDSA+SHA256:RSA+SHA256:ECDSA+SHA224:RSA+SHA224:ECDSA+SHA1:RSA+SHA1:DSA+SHA1:RSA+MD5
Shared Requested Signature Algorithms: ECDSA+SHA512:RSA+SHA512:ECDSA+SHA384:RSA+SHA384:ECDSA+SHA256:RSA+SHA256:ECDSA+SHA224:RSA+SHA224:ECDSA+SHA1:RSA+SHA1:DSA+SHA1
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2573 bytes and written 4570 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: 57591435C56B9FDFXXXBB896F8140E7B72EE07A2ACDB0446F0AB04C5D2928FD1
Session-ID-ctx:
Master-Key: F830C1F0330391B5XXX3E58F07C23D7A8C2020F824C0C4389D798CCA16A6AD5D556881671001A7DD6641AC4739BE2E28
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1465455669
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
Der Host gültig scheint, ich bin in der Lage, es pingen, openssl Anruf von jedem Betriebssystem, einschließlich Linux-Box zeigt es noch lebt und reagiert auf Anfragen.
Vielen Dank im Voraus.
Wenn ich Sie richtig verstehe, funktioniert openssl s_client von allen Maschinen, aber python/ssl nicht? Sind Sie sicher, dass Sie Python 2.7.11 auch unter FreeBSD verwenden, da die Warnung über InsecureRequest ... einen Unterschied zur Version unter Linux vermuten lässt? Funktioniert s_client noch, wenn Sie SNI mit dem Parameter '-servername' verwenden? –
openssl s_client funktioniert auf allen Maschinen korrekt, ja. Und Python/Anfragen funktioniert nur auf Nicht-Linux. –
Ja, es ist Python 2.7.11 unter FreeBSD, nur überprüft. –