Relacionado con el #1083, quizás. requests.get()
estándar para este sitio/página en particular https://docs.apitools.com/2014/04/24/a-small-router-for-openresty.html
da como resultado:
>>> import requests
>>> requests.get('https://docs.apitools.com/2014/04/24/a-small-router-for-openresty.html')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Users/jaddison/.virtualenvs/techtown/lib/python2.7/site-packages/requests/api.py", line 55, in get
return request('get', url, **kwargs)
File "/Users/jaddison/.virtualenvs/techtown/lib/python2.7/site-packages/requests/api.py", line 44, in request
return session.request(method=method, url=url, **kwargs)
File "/Users/jaddison/.virtualenvs/techtown/lib/python2.7/site-packages/requests/sessions.py", line 383, in request
resp = self.send(prep, **send_kwargs)
File "/Users/jaddison/.virtualenvs/techtown/lib/python2.7/site-packages/requests/sessions.py", line 486, in send
r = adapter.send(request, **kwargs)
File "/Users/jaddison/.virtualenvs/techtown/lib/python2.7/site-packages/requests/adapters.py", line 385, in send
raise SSLError(e)
requests.exceptions.SSLError: [Errno 1] _ssl.c:504: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
Usando request-toolbelt
's SSLAdapter
para probar varias versiones de ssl, todas fallan, al parecer... vea los siguientes rastreos.
TLSv1:
>>> adapter = SSLAdapter('TLSv1')
>>> s = requests.Session()
>>> s.mount('https://', adapter)
>>> s.get('https://docs.apitools.com/2014/04/24/a-small-router-for-openresty.html')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Users/jaddison/.virtualenvs/techtown/lib/python2.7/site-packages/requests/sessions.py", line 395, in get
return self.request('GET', url, **kwargs)
File "/Users/jaddison/.virtualenvs/techtown/lib/python2.7/site-packages/requests/sessions.py", line 383, in request
resp = self.send(prep, **send_kwargs)
File "/Users/jaddison/.virtualenvs/techtown/lib/python2.7/site-packages/requests/sessions.py", line 486, in send
r = adapter.send(request, **kwargs)
File "/Users/jaddison/.virtualenvs/techtown/lib/python2.7/site-packages/requests/adapters.py", line 385, in send
raise SSLError(e)
requests.exceptions.SSLError: [Errno 1] _ssl.c:504: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
SSLv3:
>>> adapter = SSLAdapter('SSLv3')
>>> s = requests.Session()
>>> s.mount('https://', adapter)
>>> s.get('https://docs.apitools.com/2014/04/24/a-small-router-for-openresty.html')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Users/jaddison/.virtualenvs/techtown/lib/python2.7/site-packages/requests/sessions.py", line 395, in get
return self.request('GET', url, **kwargs)
File "/Users/jaddison/.virtualenvs/techtown/lib/python2.7/site-packages/requests/sessions.py", line 383, in request
resp = self.send(prep, **send_kwargs)
File "/Users/jaddison/.virtualenvs/techtown/lib/python2.7/site-packages/requests/sessions.py", line 486, in send
r = adapter.send(request, **kwargs)
File "/Users/jaddison/.virtualenvs/techtown/lib/python2.7/site-packages/requests/adapters.py", line 385, in send
raise SSLError(e)
requests.exceptions.SSLError: [Errno 1] _ssl.c:504: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
SSLv2:
>>> adapter = SSLAdapter('SSLv2')
>>> s = requests.Session()
>>> s.mount('https://', adapter)
>>> s.get('https://docs.apitools.com/2014/04/24/a-small-router-for-openresty.html')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Users/jaddison/.virtualenvs/techtown/lib/python2.7/site-packages/requests/sessions.py", line 395, in get
return self.request('GET', url, **kwargs)
File "/Users/jaddison/.virtualenvs/techtown/lib/python2.7/site-packages/requests/sessions.py", line 383, in request
resp = self.send(prep, **send_kwargs)
File "/Users/jaddison/.virtualenvs/techtown/lib/python2.7/site-packages/requests/sessions.py", line 486, in send
r = adapter.send(request, **kwargs)
File "/Users/jaddison/.virtualenvs/techtown/lib/python2.7/site-packages/requests/adapters.py", line 378, in send
raise ConnectionError(e)
requests.exceptions.ConnectionError: HTTPSConnectionPool(host='docs.apitools.com', port=443): Max retries exceeded with url: /2014/04/24/a-small-router-for-openresty.html (Caused by <class 'socket.error'>: [Errno 54] Connection reset by peer)
Tenga en cuenta que el último da un error Connection reset by peer
, que difiere de los demás, pero estoy bastante seguro de que SSLv2 no es compatible con el servidor de todos modos.
Por diversión, también traté de pasar algunos encabezados más apropiados en la última solicitud:
>>> headers = {
... 'Accept': u"text/html,application/xhtml+xml,application/xml",
... 'User-Agent': u"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.131 Safari/537.36",
... 'Accept-Encoding': u"gzip,deflate",
... 'Accept-Language': u"en-US,en;q=0.8"
... }
>>> adapter = SSLAdapter('SSLv2')
>>> s = requests.Session()
>>> s.mount('https://', adapter)
>>> s.get('https://docs.apitools.com/2014/04/24/a-small-router-for-openresty.html', headers=headers)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Users/jaddison/.virtualenvs/techtown/lib/python2.7/site-packages/requests/sessions.py", line 395, in get
return self.request('GET', url, **kwargs)
File "/Users/jaddison/.virtualenvs/techtown/lib/python2.7/site-packages/requests/sessions.py", line 383, in request
resp = self.send(prep, **send_kwargs)
File "/Users/jaddison/.virtualenvs/techtown/lib/python2.7/site-packages/requests/sessions.py", line 486, in send
r = adapter.send(request, **kwargs)
File "/Users/jaddison/.virtualenvs/techtown/lib/python2.7/site-packages/requests/adapters.py", line 378, in send
raise ConnectionError(e)
requests.exceptions.ConnectionError: HTTPSConnectionPool(host='docs.apitools.com', port=443): Max retries exceeded with url: /2014/04/24/a-small-router-for-openresty.html (Caused by <class 'socket.error'>: [Errno 54] Connection reset by peer)
No hay dados allí tampoco. Así es como se ve la información de conexión HTTPS en Chrome en Mac:
No estoy seguro, pero algunas búsquedas en Google indican que es probable que sea un problema de la lista de cifrado, que es más urllib3, creo.
Traté de modificar DEFAULT_CIPHER_LIST
en pyopenssl
, pero comencé a encontrar errores de importación. En este punto, parecía que las cosas simplemente estaban rotas, y todavía no había una forma adecuada de abordar la solución.
Información de versión:
OS X Mavericks
Pitón 2.7.5
OpenSSL 0.9.8y 5 de febrero de 2013 - (desde python -c "import ssl; print ssl.OPENSSL_VERSION"
)
solicitudes 2.2.1
solicitudes-cinturón de herramientas 0.2.0
urllib3 1.8
Lamentablemente, esto no está relacionado con el problema que identificó y se debe completamente al OpenSSL de mierda con el que OS X se envía de manera predeterminada. La versión 0.9.8y tiene algunos problemas reales con la realización de protocolos de enlace SSL, y algunos servidores no lo toleran bien. Usar Python 3 en mi caja OS X (por lo tanto, usar un OpenSSL más nuevo) revela que no hay problema.
Tienes dos opciones:
env ARCHFLAGS="-arch x86_64" LDFLAGS="-L/usr/local/opt/openssl/lib" CFLAGS="-I/usr/local/opt/openssl/include" pip install PyOpenSSL
.Ah, parece que estaba siguiendo una pista falsa en ese momento: de todos modos, no planeo implementar nada en OSX. Parece que trasladaré mis pruebas a una virtualbox de Linux. ¡Disculpas por este problema de largo aliento!
No hay necesidad de disculparse, hacer esa pregunta fue lo correcto: es un conocimiento extrañamente específico saber que OS X tiene este problema. =)
Ok, esto es un fastidio. Creé una imagen de Virtualbox de 32 bits del servidor Ubuntu 14.04 a través de Vagrant y todo esto sigue sucediendo excepto en el caso de SSLv2, donde falla porque el protocolo no está incluido en la versión OpenSSL en Ubuntu 14.04 (por diseño, creo - SSLv2 es antiguo y obsoleta).
Versiones:
Ubuntu 14.04 de 32 bits (a través del combo Vagrant/Virtualbox)
Pitón 2.7.6
solicitudes == 2.2.1
solicitudes-cinturón de herramientas==0.2.0
urllib3==1.8.2
EDITAR: olvidé la versión de OpenSSL...
python -c "importar ssl; imprimir ssl.OPENSSL_VERSION"
OpenSSL 1.0.1f 6 de enero de 2014
TLSv1:
>>> import requests
>>> from requests_toolbelt import SSLAdapter
>>> adapter = SSLAdapter('TLSv1')
>>> s = requests.Session()
>>> s.mount('https://', adapter)
>>> s.get('https://docs.apitools.com/2014/04/24/a-small-router-for-openresty.html')
Traceback (most recent call last):
File "<console>", line 1, in <module>
File "/home/vagrant/.virtualenvs/techtown/local/lib/python2.7/site-packages/requests/sessions.py", line 395, in get
return self.request('GET', url, **kwargs)
File "/home/vagrant/.virtualenvs/techtown/local/lib/python2.7/site-packages/requests/sessions.py", line 383, in request
resp = self.send(prep, **send_kwargs)
File "/home/vagrant/.virtualenvs/techtown/local/lib/python2.7/site-packages/requests/sessions.py", line 486, in send
r = adapter.send(request, **kwargs)
File "/home/vagrant/.virtualenvs/techtown/local/lib/python2.7/site-packages/requests/adapters.py", line 385, in send
raise SSLError(e)
SSLError: [Errno 1] _ssl.c:510: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
SSLv2:
>>> import requests
>>> from requests_toolbelt import SSLAdapter
>>> adapter = SSLAdapter('SSLv3')
>>> s = requests.Session()
>>> s.mount('https://', adapter)
>>> s.get('https://docs.apitools.com/2014/04/24/a-small-router-for-openresty.html')
Traceback (most recent call last):
File "<console>", line 1, in <module>
File "/home/vagrant/.virtualenvs/techtown/local/lib/python2.7/site-packages/requests/sessions.py", line 395, in get
return self.request('GET', url, **kwargs)
File "/home/vagrant/.virtualenvs/techtown/local/lib/python2.7/site-packages/requests/sessions.py", line 383, in request
resp = self.send(prep, **send_kwargs)
File "/home/vagrant/.virtualenvs/techtown/local/lib/python2.7/site-packages/requests/sessions.py", line 486, in send
r = adapter.send(request, **kwargs)
File "/home/vagrant/.virtualenvs/techtown/local/lib/python2.7/site-packages/requests/adapters.py", line 385, in send
raise SSLError(e)
SSLError: [Errno 1] _ssl.c:510: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
SSLv23:
>>> import requests
>>> from requests_toolbelt import SSLAdapter
>>> adapter = SSLAdapter('SSLv23')
>>> s = requests.Session()
>>> s.mount('https://', adapter)
>>> s.get('https://docs.apitools.com/2014/04/24/a-small-router-for-openresty.html')
Traceback (most recent call last):
File "<console>", line 1, in <module>
File "/home/vagrant/.virtualenvs/techtown/local/lib/python2.7/site-packages/requests/sessions.py", line 395, in get
return self.request('GET', url, **kwargs)
File "/home/vagrant/.virtualenvs/techtown/local/lib/python2.7/site-packages/requests/sessions.py", line 383, in request
resp = self.send(prep, **send_kwargs)
File "/home/vagrant/.virtualenvs/techtown/local/lib/python2.7/site-packages/requests/sessions.py", line 486, in send
r = adapter.send(request, **kwargs)
File "/home/vagrant/.virtualenvs/techtown/local/lib/python2.7/site-packages/requests/adapters.py", line 385, in send
raise SSLError(e)
SSLError: [Errno 1] _ssl.c:510: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
¿Quizás este es un problema de la lista de cifrado entonces? ¿O la versión de OpenSSL utilizada aquí sigue siendo problemática?
Estoy absolutamente dispuesto a dedicar algo de tiempo para ayudar a depurar esto si es necesario... siempre que me den alguna dirección.
La máquina virtual se está descargando. No puedo reproducir esto en ArchLinux.
Los stacktraces indican esto, pero me gustaría estar seguro: ¿usted _no_ está usando PyOpenSSL sino solo stdlib?
@t-8ch Gracias por echar un vistazo a esto, estoy un poco confundido. OpenSSL me hace la vida muy difícil =(
@ t-8ch No he instalado PyOpenSSL si eso es lo que estás preguntando.
Habría asumido (quizás incorrectamente) que pip install requests
debería darme todo lo que necesito para llamar con éxito a requests.get('...')
en una página HTTPS. Lo cual, por supuesto, funciona en su mayor parte, solo que no para este sitio por alguna razón.
@jaddison _principalmente_ lo hace. Desafortunadamente, la biblioteca estándar de Python 2.7 apesta y no es compatible con algunas funciones, como SNI.
Me pregunto si esto es SNI...
@jaddison Hay dos rutas de código diferentes detrás de escena. No debería tener que preocuparse por eso, pero es útil saberlo al depurar.
Sin embargo, ahora puedo reproducir esto en ubuntu. Pero solo o Py2. En Py3 todo está bien.
Sospecho que @Lukasa tiene razón y el servidor falla cuando el cliente no usa SNI.
Me molesta que la ausencia de SNI falle de varias maneras diferentes según el servidor en cuestión.
Noté este cambio entre OpenSSL 1.0.1f y 1.0.1g (https://www.openssl.org/news/openssl-1.0.1-notes.html):
Add TLS padding extension workaround for broken servers.
EDITAR: Ahh, no importa: el error no debería variar entre Py 2 y 3, creo.
@jaddison Para probar si se trata de SNI, deberá instalar los requisitos de SNI para Python 2.
@Lukasa tenía razón. Comparar:
$ openssl s_client -connect docs.apitools.com:443
CONNECTED(00000003)
139846853338768:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:762:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 517 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
$ openssl s_client -connect docs.apitools.com:443 -servername docs.apitools.com
... happy handshake here
Para elaborar: el segundo comando habilita la funcionalidad SNI de openssl s_client
.
Puede a) cambiar a python3 b) instalar dependencias adicionales.
El stdlib no tiene en este momento ninguna forma de hacer SNI.
Gracias por la rápida retroalimentación. Como no hay ningún error, cerraré esto... otra vez.
Hola, gracias chicos!! Instalé python3 en mi mac y boom, funciona.
Solo quiero intervenir y decir que experimenté este problema en OS X 10.9.5, Python 2.7.7 y OpenSSL 0.9.8zc.
Pude solucionar mi problema de apretón de manos:
brew install OpenSSL
cryptography
vinculado al nuevo OpenSSL ( env ARCHFLAGS="-arch x86_64" LDFLAGS="-L/usr/local/opt/openssl/lib" CFLAGS="-I/usr/local/opt/openssl/include" pip install cryptography
)pip install requests[security]
Gracias, @Microservidor. Prácticamente estoy ejecutando las mismas especificaciones (10.9.5, Python 2.7.6 instalado a través de Homebrew pero compilado con OpenSSL 0.9.8zg proporcionado por el sistema) y este fue todo mi proceso para poner en marcha requests
para Django :
brew install openssl
Instale requests
con un montón de cosas de SNI , compiladas contra nuestra nueva instalación de OpenSSL. La opción [security]
simplemente instala pyopenssl ndg-httpsclient pyasn1
env ARCHFLAGS="-arch x86_64" LDFLAGS="-L/usr/local/opt/openssl/lib" CFLAGS="-I/usr/local/opt/openssl/include" pip install requests[security] urllib3
Y estamos listos para irnos:
"""
This may or may not be needed. See:
https://urllib3.readthedocs.org/en/latest/security.html#openssl-pyopenssl
"""
# from urllib3.contrib import pyopenssl
# pyopenssl.inject_into_urllib3()
import requests
# r = requests.get(...)
¿Hay una respuesta definitiva sobre cómo hacer que esto funcione en ubuntu? Me encuentro con este problema, y parece que la única respuesta aquí se refiere a cómo hacer que esto funcione en una Mac. Actualizar todo nuestro código base a Python 3 no es una opción.
OK, puede que haya respondido mi propia pregunta. Lo que hice se reduce a:
sudo apt-get install libffi-dev
pip install pyOpenSSL ndg-httpsclient pyasn1
@lsemel gracias, eso me ahorró un montón de tiempo
@lsemel ¿Estás seguro? Lo probé en Ubuntu 15.10 y todavía no funciona con Python 2.7.10.
Funciona con Python 2.7 en Travis CI:
https://travis-ci.org/playing-se/swish-python
¡Lo tengo para trabajar ahora! Simplemente desinstalé pyOpenSSL:
pip uninstall pyOpenSSL
¿Quizás solo deberíamos pyopenssl.inject_into_urllib3() si la versión de Python es inferior a 2.7.9? pyOpenSSL parece romper cosas en Ubuntu y Windows si la versión de Python es 2.7.10.
PyOpenSSL no debería estar rompiendo nada. Si lo hace, es un error que debe informarse.
Tendré que investigar esto, pero ¿hay alguna buena razón para inyectar pyopenssl en urllib3 si la versión de Python es 2.7.9 o posterior?
Estoy pensando en algo como esto:
# Check if Modern SSL with SNI support
try:
from ssl import SSLContext
from ssl import HAS_SNI
except ImportError:
# Attempt to enable urllib3's SNI support, if possible
try:
from .packages.urllib3.contrib import pyopenssl
pyopenssl.inject_into_urllib3()
except ImportError:
pass
Sí, con frecuencia lo hay. Por ejemplo, en OS X, la mayoría de los Python se vinculan con el sistema OpenSSL, que es la versión 0.9.8zg. PyOpenSSL, sin embargo, se vinculará con un OpenSSL mucho más nuevo (1.0.2). Eso hace que el uso de PyOpenSSL sea una mejora sustancial de la seguridad.
Además, PyOpenSSL nos brinda un acceso mucho mejor a OpenSSL, lo que nos permite asegurarlo de manera más efectiva.
OK, he jugado un poco con esto ahora.
FUNCIONA con pyopenssl PERO no si ndg-httpsclient está instalado.
Sin embargo, puedo hacer que funcione con ndg-httpsclient si desinstalo pyasn1 y me da estas advertencias:
/usr/lib/python2.7/dist-packages/ndg/httpsclient/subj_alt_name.py:22: UserWarning: Error importing pyasn1, subjectAltName check for SSL peer verification will be disabled. Import error is: No module named pyasn1.type
warnings.warn(import_error_msg)
/usr/lib/python2.7/dist-packages/ndg/httpsclient/ssl_peer_verification.py:25: UserWarning: SubjectAltName support is disabled - check pyasn1 package installation to enable
warnings.warn(SUBJ_ALT_NAME_SUPPORT_MSG)
/usr/lib/python2.7/dist-packages/ndg/httpsclient/subj_alt_name.py:22: UserWarning: Error importing pyasn1, subjectAltName check for SSL peer verification will be disabled. Import error is: No module named pyasn1.type
warnings.warn(import_error_msg)
Mismo comportamiento en Ubuntu 15.10 y Windows 10 con Python 2.7.10 instalado.
Esto se debe a que sin ndg-httpsclient no se utiliza la compatibilidad con PyOpenSSL.
Sí, tendré que investigar por qué funciona si SubjectAltName está deshabilitado. ¿Alguna idea?
Es casi seguro que el problema es que está utilizando diferentes OpenSSL en cada caso.
Tuve el mismo problema en mi caja Ubuntu 14.04 y Python 2.7.11
es del SNI
Lo que funcionó para mí fue esto:
Creo que hubo una verificación en el momento de la instalación en urllib3 o solicitudes que impidieron que las cosas funcionaran sin la desinstalación.
@jvanasco , ¿qué estás usando para instalar esos paquetes? Supongo que pip. ¿Por qué está instalando urllib3 y las solicitudes por separado?
Bueno, necesitaba urllib3 en virtualenv... pero lo instalé para intentar que pip y easy_install instalaran los requisitos. (Usé ambos)
Tengo un indexador web y algunas URL se rompieron. Escribí un script rápido para probar los dañados y seguí reinstalando/eliminando+instalando los paquetes en las instrucciones de urllib3 sobre problemas de SSL hasta que funcionaron.
El 31 de mayo de 2016, a las 7:25 p. m., Ian Cordasco [email protected] escribió:
@jvanasco , ¿qué estás usando para instalar esos paquetes? Supongo que pip. ¿Por qué está instalando urllib3 y las solicitudes por separado?
—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub o silencie el hilo.
Sigo viendo este problema y probé las soluciones sugeridas.
Actualicé mi versión de python a 2.7.11
Instalé los 3 paquetes adicionales.
Probé la secuencia de desinstalación/instalación sugerida por @jvanasco y aún obtuve el SSLError
También usando Ubuntu 14.04, lamentablemente no hay una actualización de OpenSSL, así que tengo que usar las soluciones publicadas aquí y no tengo suerte.
¿Algún paso extra que ustedes posiblemente tomaron?
Gracias
@Lekinho Descubrí que hacer un breve script de prueba que probara el dominio con el que estaba teniendo problemas ayudó.
fue solo:
import requests
r = requests.get(bad_url)
print r.__dict__
@Lekinho Puede extraer pyopenssl de las solicitudes en su código:
try:
from requests.packages.urllib3.contrib import pyopenssl
pyopenssl.extract_from_urllib3()
except ImportError:
pass
@Lekinho Si todavía tiene este problema con Python 2.7.11, es muy probable que el servidor remoto no admita la configuración de TLS que utilizan las solicitudes. ¿El servidor en cuestión está disponible en la Internet pública? Si es así, ¿puede proporcionarme la URL?
Probé la importación de pyopenssl como se sugiere.
Desafortunadamente, esto no es accesible públicamente.
Sin embargo, tengo los detalles exactos de qué versión de openSSL tiene el servidor.
Básicamente, nos ejecutamos en una máquina virtual redhat, tenía este openSSL cuando todo funcionaba: openssl-1.0.1e-42.el6_7.4.x86_64
Luego hicimos una actualización de redhat y hubo una actualización para openssl: openssl-1.0.1e-48.el6_8.1.x86_64
Esta versión siempre tiene el problema del protocolo de enlace incorrecto cuando se usa openssl en ubuntu 14.04.
¿Tienen alguna URL pública con la que pueda probar, para ver si las soluciones alternativas ayudaron a resolver el problema y es solo esta combinación única que tengo ese es el problema?
La misma máquina está bien cuando las solicitudes REST se envían a través del navegador (es decir, sin ubuntu openssl)
Gracias
¿Puede proporcionar la salida de rpm -q --changelog openssl
, por favor?
[ admin@leke-2-2-8-11 ~]$ rpm -q --changelog abre SSL
¿Parece que @Lekinho eliminó su cuenta de github? Para la próxima persona que tenga problemas, es posible que su actualización de OpenSsl o Python rompa algunos enlaces c compilados. Cada vez que tengo una actualización como esa, descarto mi virtualenv o todos los paquetes y luego construyo uno nuevo.
@jvanasco todavía estoy aquí.
Me preguntaba, ¿tienes una URL pública con la que pueda probar esto? Quiero ver si la solución realmente resuelve el problema para los casos confirmados (esto significará que no arruiné nada al intentar hacerlo)
@Lukasa
subconjunto de conjunto de cambios entre la versión de trabajo y la versión actualizada :+1:
lun 02 de mayo de 2016 Tomáš Mráz [email protected] 1.0.1e-48.1
corregir CVE-2016-2105: posible desbordamiento en la codificación base64
corregir CVE-2016-2106 - posible desbordamiento en EVP_EncryptUpdate()
corregir CVE-2016-2107 - oráculo de relleno en AES-NI CBC-MAC cosido
corregir CVE-2016-2108: corrupción de memoria en el codificador ASN.1
corrige CVE-2016-2109: posible DoS al leer datos ASN.1 de BIO
corregir CVE-2016-0799 - problemas de memoria en BIO_printf
mié 24 de febrero de 2016 Tomáš Mráz [email protected] 1.0.1e-48
corrige CVE-2016-0702: ataque de canal lateral en exponenciación modular
corrige CVE-2016-0705 - doble libre en análisis de clave privada DSA
corregir CVE-2016-0797: corrupción de montón en BN_hex2bn y BN_dec2bn
martes, 16 de febrero de 2016 Tomáš Mráz [email protected] 1.0.1e-47
corregir CVE-2015-3197: aplicación de conjunto de cifrado SSLv2
deshabilite SSLv2 en el método TLS genérico
Vie 15 de enero de 2016 Tomáš Mráz [email protected] 1.0.1e-46
corrige la pérdida de memoria de 1 byte en el análisis de pkcs12 (# 1229871)
documentar algunas opciones del comando de velocidad (#1197095)
jue 14 ene 2016 Tomáš Mráz [email protected] 1.0.1e-45
corregir marcas de tiempo de alta precisión en la autoridad de sellado de tiempo
lun 21 dic 2015 Tomáš Mráz [email protected] 1.0.1e-44
corregir CVE-2015-7575: no permitir el uso de MD5 en TLS1.2
vie 04 dic 2015 Tomáš Mráz [email protected] 1.0.1e-43
corrección CVE-2015-3194: falla de verificación de certificado con parámetro PSS faltante
corregir CVE-2015-3195 - Pérdida de memoria X509_ATTRIBUTE
corrige CVE-2015-3196: condición de carrera al manejar la sugerencia de identidad de PSK
martes, 23 de junio de 2015 Tomáš Mráz [email protected] 1.0.1e-42
Actualizar :
Así que encontré una solución para esto.
Básicamente, un colega estaba leyendo sobre el problema y vio algunas publicaciones sobre la compatibilidad de RHEL con openssl para el cifrado ECC/ECDH que no era del 100 % por cualquier motivo.
Probamos la solicitud a la URL deshabilitando explícitamente los cifrados ECDH (agregando la negación del propio script openssl, es decir, openssl s_client -connect 10.85.103.218:8443 -cipher 'DEFAULT:!ECDH')
Pudimos conectarnos con éxito.
Aquí está la lista de cifrado predeterminada para openssl en ubuntu 14.04
ECDH+ AESGCM:DH+AESGCM :ECDH+AES256:DH+AES256:ECDH+AES128:DH+ AES:ECDH+ALTO :DH+ ALTO:ECDH+3DES :DH+3 DES:RSA+AESGCM :RSA+ AES:RSA+ALTO :RSA +3DES:!aNULO:!eNULO:!MD5
Entonces, con ese conocimiento, usé pyopenssl para imprimir mis cifrados SSL predeterminados y eliminé explícitamente todos los cifrados ECDH de la cadena. Hice esto justo en el bloque para importar urllib3 del paquete de solicitudes (es decir, antes de comenzar a realizar solicitudes reales), aquí hay algo similar:
https://github.com/kennethreitz/requests/issues/1308
Me doy cuenta de que puede haber riesgos de seguridad para esta acción, pero al menos esto nos pone en marcha y arroja más luz al respecto.
Por qué esos cifrados en particular parecen ser un problema para RHEL, no tengo idea.
Intentaré cuando tenga más tiempo para ver qué cambios particulares de RHEL pueden haber introducido esto y leeré más sobre el propósito.
¿Alguien sabe más sobre cifrados en general?
Tiene el mismo problema... ARG...
La frustración de @ lukas-gitl no te ayudará a resolver el problema. Proporcionarnos información sobre su entorno (preferiblemente parte, si no toda, de la información que le preguntamos a Lekinho anteriormente) ayudará.
@sigmavirus24 Disculpas. Tenía la intención de proporcionar más información y luego me desvié (ya que no tenía tiempo para esto). Estoy usando Ubuntu 14.04, Python 2.7.6 y la última versión de solicitudes en pip. Esto sucede cuando intento acceder como punto final de API Gateway (pueden ser bastante restrictivos).
Intenté eliminar virtualenv y regenerarlo, pero desafortunadamente eso no lo resolvió.
Dime qué más necesitas. Cambié a nodejs por el momento, pero estaría feliz de ayudar con una resolución.
@lukas-gitl Es muy probable que el servidor con el que se está comunicando requiera cifrados que no ofrece o versiones de TLS que no ofrece. Esto puede estar relacionado con el OpenSSL que ha instalado. También debe intentar ejecutar pip install requests[security]
: es posible que tenga problemas con SNI.
Sí, ya lo probé también. Permítanme armar un guión de prueba rápido aquí para que estemos en la misma página.
virtualenv -p /usr/bin/python2.7 env
origen env/bin/activar
solicitudes de instalación de pip
solicitudes de instalación de pip [seguridad]
echo 'solicitudes de importación' >> test.py
echo 'requests.get("https://API_ID.execute-api.us-west-2.amazonaws.com/ENV/ENPOINT")' >> test.py
prueba de python.py
¿Y qué error específico estás viendo?
.../env/local/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:318:
SNIMissingWarning: An HTTPS request has been made, but the SNI (Subject Name Indication) extension to TLS is not available on this platform. This may cause the server to present an incorrect TLS certificate, which can cause validation failures. You can upgrade to a newer version of Python to solve this. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#snimissingwarning.
SNIMissingWarning
.../env/local/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:122: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. You can upgrade to a newer version of Python to solve this. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
InsecurePlatformWarning
Traceback (most recent call last):
File "test.py", line 2, in <module>
requests.get("https://sbsz8eqowe.execute-api.us-west-2.amazonaws.com/dev/segment_to_s3_webhook")
File ".../env/local/lib/python2.7/site-packages/requests/api.py", line 71, in get
return request('get', url, params=params, **kwargs)
File ".../env/local/lib/python2.7/site-packages/requests/api.py", line 57, in request
return session.request(method=method, url=url, **kwargs)
File ".../env/local/lib/python2.7/site-packages/requests/sessions.py", line 475, in request
resp = self.send(prep, **send_kwargs)
File ".../env/local/lib/python2.7/site-packages/requests/sessions.py", line 585, in send
r = adapter.send(request, **kwargs)
File ".../env/local/lib/python2.7/site-packages/requests/adapters.py", line 477, in send
raise SSLError(e, request=request)
requests.exceptions.SSLError: [Errno 1] _ssl.c:510: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure```
Entonces, ¿básicamente debo actualizar a una versión posterior de python?
Ok, ambas advertencias sugieren que sus solicitudes en realidad no usan las extensiones de solicitudes [seguridad]. Sugiere enfáticamente que cualquier Python que esté ejecutando _no_ sea el que instaló en su entorno virtual: la extensión de solicitudes [seguridad] debería eliminar esas advertencias.
@lukas-gitl por favor vea mis notas arriba.
¿Tienes acceso al servidor? compare la lista de cifrados predeterminados para el servidor y el cliente.
Es muy probable que 1 de ellos no admita el primer conjunto de cifrados en el otro, de ahí el error.
Puede verificar los cifrados predeterminados con un script simple como el que usé aquí:
sistema de importación
importar sistema operativo
importar ssl
imprimir (ssl.OPENSSL_VERSION)
sys.path.insert(1, os.path.abspath(os.path.join(os.getcwd(), 'lib')))
sys.path.append('/usr/local/lib/python2.7/dist-packages')
solicitudes de importación
de solicitudes.paquetes.urllib3.contrib importar pyopenssl
pyopenssl.inject_into_urllib3()
imprimir pyopenssl.DEFAULT_SSL_CIPHER_LIST
Ok, ahora estoy realmente confundido. El mensaje de error proviene del entorno virtual. Entonces, ¿cómo podrían venir desde allí mientras ejecuto desde un entorno de Python diferente?
Así que probé pip install pyopenssl ndg-httpsclient pyasn1
en lugar de pip install requests[security]
y funcionó...
Ajá, sospecho que tu pepita es demasiado vieja para manejar los extras.
Maldita sea. Eso explica mucho. ¡Muchas gracias por su ayuda!
Encontré el mismo problema aquí, debía enviar una solicitud GET con el siguiente código:
requests.get('https://mdskip.taobao.com/core/initItemDetail.htm?itemId=530444505608&showShopProm=false&queryMemberRight=true&isRegionLevel=false&tmallBuySupport=true&addressLevel=2&sellerPreview=false&isForbidBuyItem=false&cachedTimestamp=1466835924196&offlineShop=false&household=false&tryBeforeBuy=false&isSecKill=false&service3C=false&isApparel=true&isUseInventoryCenter=false&cartEnable=true&isAreaSell=false&callback=setMdskip×tamp=1466841669969&isg=Al9faN3XWRpIf6UEoQ88UH/1b7np0rNm&ref=https%3A%2F%2Fs.taobao.com%2Fsearch%3Fq%3D%25E6%258B%2589%25E5%25A4%258F%25E8%25B4%259D%25E5%25B0%2594%26imgfile%3D%26commend%3Dall%26ssid%3Ds5-e%26search_type%3Ditem%26sourceId%3Dtb.index%26spm%3Da21bo.50862.201856-taobao-item.1%26ie%3Dutf8%26initiative_id%3Dtbindexz_20160625')
desafortunadamente me dieron la información del error:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Library/Python/2.7/site-packages/requests/api.py", line 71, in get
return request('get', url, params=params, **kwargs)
File "/Library/Python/2.7/site-packages/requests/api.py", line 57, in request
return session.request(method=method, url=url, **kwargs)
File "/Library/Python/2.7/site-packages/requests/sessions.py", line 475, in request
resp = self.send(prep, **send_kwargs)
File "/Library/Python/2.7/site-packages/requests/sessions.py", line 585, in send
r = adapter.send(request, **kwargs)
File "/Library/Python/2.7/site-packages/requests/adapters.py", line 477, in send
raise SSLError(e, request=request)
requests.exceptions.SSLError: ("bad handshake: Error([('SSL routines', 'SSL23_GET_SERVER_HELLO', 'sslv3 alert handshake failure')],)",)
Traté de instalar brew openssl, brew upgrade openssl, pip install --upgrade pip, pip install requestes, pip install request[security], pero no funcionaron.
Sin embargo, cuando escribo openssl version
obtengo OpenSSL 0.9.8zh 14 Jan 2016
, no sé si está bien.
¿Hay alguien que me pueda ayudar con eso?
@jschwinger23 ¿Puede ejecutar pip install pyopenssl ndg-httpsclient pyasn1
también, por favor?
@Lukasa Gracias por tu respuesta. Reconfirmé que los instalé:
$ pip install pyopenssl ndg-httpsclient pyasn1
Requirement already satisfied (use --upgrade to upgrade): pyopenssl in /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python
Requirement already satisfied (use --upgrade to upgrade): ndg-httpsclient in /Library/Python/2.7/site-packages
Requirement already satisfied (use --upgrade to upgrade): pyasn1 in /Library/Python/2.7/site-packages
pero el código sigue inactivo.
De todos modos, descubrí que todo va bien en Python3 y me alegro de poder codificar en python3.
Muchas gracias.
Seguí las instrucciones anteriores pero aún me encuentro con este problema
```
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Library/Python/2.7/site-packages/requests/api.py", line 71, in get
return request('get', url, params=params, **kwargs)
File "/Library/Python/2.7/site-packages/requests/api.py", line 57, in request
return session.request(method=method, url=url, **kwargs)
File "/Library/Python/2.7/site-packages/requests/sessions.py", line 475, in request
resp = self.send(prep, **send_kwargs)
File "/Library/Python/2.7/site-packages/requests/sessions.py", line 585, in send
r = adapter.send(request, **kwargs)
File "/Library/Python/2.7/site-packages/requests/adapters.py", line 477, in send
raise SSLError(e, request=request)
requests.exceptions.SSLError: ("bad handshake: Error([('SSL routines', 'SSL23_GET_SERVER_HELLO', 'sslv3 alert handshake failure')],)",)
¿algunas ideas?
``````
@rohanpai Es probable que no tenga una superposición de cifrado, o que el servidor remoto no esté satisfecho con las versiones que está ofreciendo, o que se espera que proporcione un certificado de cliente y no lo está. Es difícil dar consejos más específicos. Pruebe esto para investigar el problema.
En ubuntu 14.04LTS necesitaba hacer esto:
sudo pip install ndg-httpsclient pyasn1 --upgrade
Tenga en cuenta que en Ubuntu no es posible actualizar/eliminar pyopenssl
ya que es propiedad del sistema operativo.
la solución de markstrefford también me funcionó en mac os sierra
La solución de @markstrefford también funcionó para mí.
Solo un aviso para cualquiera que use OpenSSL 1.1:
También se encontrará con este problema, incluso cuando fuerce los adaptadores TLS, cuando el servidor remoto ofrece Elliptic Curves como primera opción.
La causa es: http://bugs.python.org/issue29697
¡Hola chicos! Tengo el mismo problema con el siguiente servidor https://34.200.105.231/SID/Service.svc?wsdl
. He probado de todo y salto de y a los mismos 2 errores:
requests.exceptions.SSLError: ("bad handshake: SysCallError(-1, 'Unexpected EOF')",)
requests.exceptions.SSLError: EOF occurred in violation of protocol (_ssl.c:661)
¿Algunas ideas? @Lukasa , veo algunos problemas con el Certificado, pero parece que no debería ser tan malo: https://sslanalyzer.comodoca.com/?url=34.200.105.231
El certificado generalmente no causará este problema: este problema es causado por el servidor que nos cuelga, por lo que generalmente es el resultado de una falta de coincidencia del conjunto de cifrado. En este caso, eso es exactamente lo que está pasando como puedes ver aquí .
Este es un servidor que, francamente, nunca debería estar expuesto a la Internet abierta. No hay métodos seguros de comunicación con este servidor: ninguno, cero. Esta es la razón por la que falla el protocolo de enlace: Requests solo acepta conjuntos de cifrado modernos y no hay conjuntos de cifrado modernos disponibles para este servidor. La mejor opción es TLS_RSA_WITH_3DES_EDE_CBC_SHA
, una opción que eliminamos porque es vulnerable a ataques prácticos en la transferencia de datos a gran escala.
Si este servidor es suyo, actualícelo a una mejor implementación de TLS o cambie la configuración. De lo contrario, mi primer consejo es reconsiderar la posibilidad de hablar con este servidor. Si es necesario, puede usar el código aquí , pero le recomiendo que presione al operador del servidor para solucionar este problema.
@Lukasa : ¡gracias por trabajar en esto con todos! He leído y probado la mayor parte de esto
Cuando se ejecuta el script en Windows, todo funciona.
Al ejecutar el script en OSX, reciba:
raise SSLError(e, request=request)
requests.exceptions.SSLError: ("bad handshake: SysCallError(-1, 'Unexpected EOF')",)
No estoy convencido de que no sea el servidor en sí, pero agradecería cualquier ayuda adicional para confirmar y/o sacarme de este agujero de conejo. Sería una gran victoria hacer que funcione.
env ARCHFLAGS="-arch x86_64" LDFLAGS="-L/usr/local/opt/openssl/lib" CFLAGS="-I/usr/local/opt/openssl/include" pip install --force-reinstall --no-cache-dir {PACKAGE}
No estoy 100% seguro de que la instalación contra el openssl realmente haya hecho algo, ya que parecía actuar igual que la instalación sin (por ejemplo, la velocidad y la mensajería parecían todas iguales)
Como se indica en otro hilo (arriba), ¿conectarse directamente a través de openSSL appears
para ser feliz?
openssl s_client -connect XXX.102.7.147:443
CONNECTED(00000003)
write:errno=0
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 198 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1493384325
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
---
Eh... OpenSSL está técnicamente bien, pero ese OpenSSL no negoció ningún cifrado (es decir, parece haber negociado SSL_NULL_WITH_NULL_NULL
. ¿Puedes ejecutar ssllabs en tu servidor y verificar qué suites de cifrado admite?
@Lukasa No está expuesto en Internet, ¿hay alguna sonda de línea de comandos que pueda activar y que pueda brindarle información adecuada?
Podrías probar con cipherscan .
@Lukasa lo instaló... está actuando raro (sin salida, observándolo)... lo publicaré si se me ocurre algo que pueda transmitirse. ¡Gracias por la guía!
@Lukasa muchas gracias por su ayuda, en realidad nunca funcionó el cipherscan, pero corrigió nuestros problemas. No tuvo nada que ver con nada de esto, y fue una discrepancia de IP tonta en nuestros entornos... ¡lecciones aprendidas! gracias ...
No hay problema, me alegro de que lo hayas solucionado.
streamlink -l debug h ttpstream://https :// www.arconaitv.us/stream.php?id=43 peor
¡[cli][info] streamlink se está ejecutando como root! ¡Ten cuidado!
[cli][depurar] SO: Linux-4.14.0-041400-generic-x86_64-with-Ubuntu-14.04-trusty
[cli][depurar] Python: 2.7.6
[cli][depuración] Streamlink: 0.13.0+27.g2ff314c
[cli][depuración] Solicitudes (2.19.1), Calcetines (1.6.7), Websocket (0.48.0)
[cli][info] Complemento coincidente encontrado http para URL h ttpstream://https :// www.arconaitv.us/stream.php?id=43
[plugin.http][depuración] URL= https://www.arconaitv.us/stream.php?id=43; parámetros={}
[cli][info] Transmisiones disponibles: en vivo (peor, mejor)
[cli][info] Transmisión de apertura: en vivo (http)
[cli][debug] Pre-buffering 8192 bytes
[cli][info] Jugador inicial: /usr/bin/vlc
[cli][debug] Escribiendo flujo a salida
[cli][info] Transmisión finalizada
[cli][info] Cerrando flujo actualmente abierto..
intentado pero sin suerte
atlast consiguió que funcione tvplayer en la pc local. Instalé tinyproxy en mi PC local pero en vps httpproxy xxxx no funciona.
¿Está bien tinyproxy o necesito algún otro servidor proxy para instalarlo en mi PC local?
Hola @maanich , esto no parece estar directamente relacionado con este problema, o ser un informe de defectos para las solicitudes, que es para lo que está reservado este rastreador de problemas. Si tiene preguntas sobre la configuración del sistema, se resolverán mejor en una plataforma como StackOverflow . ¡Gracias!
streamlink --https-proxy " http://8xxxx :8000/" --tvplayer-email [email protected] --tvplayer-password vcvdf3 --http-no-ssl-verify https://tvplayer.com/watch /itv mejor --player-no-close --stdout | /var/tmp/youtube/ffmpeg -y -i pipe:0 -vcodec copy -acodec copy -flags -global_header -hls_flags delete_segments -hls_time 10 -hls_list_size 6 /mnt/hls/arc.m3u8
ffmpeg versión 4.0-static https://johnvansickle.com/ffmpeg/ Copyright (c) 2000-2018 los desarrolladores de FFmpeg
construido con gcc 6.3.0 (Debian 6.3.0-18+deb9u1) 20170516
configuración: --enable-gpl --enable-version3 --enable-static --disable-debug --disable-ffplay --disable-indev=sndio --disable-outdev=sndio --cc=gcc-6 -- enable-libxml2 --enable-fontconfig --enable-frei0r --enable-gnutls --enable-gray --enable-libaom --enable-libfribidi --enable-libass --enable-libfreetype --enable-libmp3lame -- habilitar-libopencore-amrnb --habilitar-libopencore-amrwb --habilitar-libopenjpeg --habilitar-librubberband --habilitar-libsoxr --habilitar-libspeex --habilitar-libvorbis --habilitar-libopus --habilitar-libtheora --habilitar -libvidstab --enable-libvo-amrwbenc --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzimg
libavutil 56. 14.100 / 56. 14.100
libavcodec 58. 18.100 / 58. 18.100
formato libav 58. 12.100 / 58. 12.100
dispositivo libav 58. 3.100 / 58. 3.100
filtro libav 7. 16.100 / 7. 16.100
libswscale 5. 1.100 / 5. 1.100
libswresamp 3. 1.100 / 3. 1.100
libpostproc 55. 1.100 / 55. 1.100
¡[consola] [info] streamlink se está ejecutando como root! ¡Ten cuidado!
[consola][info] Se encontró el complemento tvplayer coincidente para la URL https://tvplayer.com/watch/itv
Error: No se puede abrir URL: https://live.tvplayer.com/stream.m3u8?id=204&Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cCo6XC9cL2xpdmUudHZwbGF5ZXIuY29tXC9zdHJlYW0ubTN1OD9pZD0yMDQiLCJDb25kaXRpb24iOnsiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjE1MjkwNTc0OTR9LCJJcEFkZHJlc3MiOnsiQVdTOlNvdXJjZUlwIjoiNjIuMjEwLjE0Mi42NlwvMzIifX19XX0_&Signature=mHOteYcUu4QsbGD n0e ~ 7meDUGT8VN7bVOBAHa-0Mk6ROA9XHYx3aIAZMAo3dFjOGuWk-3MszJzRFHdv ~ ~ -CCsmX3D8XQa2zvzfuIWfMAT yDshroXBN25iW6ZJ0-7lGla00jMTUpm5sW-uDy18OkiBWgGvDVas2Lz-EW ~ 5-LTw2YWvEpqkvRB9OpcsHJj9RRQLuDVjwYKXwKvHTJmB1J ~sGE3aigaL7AZyBaIAUMcpk-xYMPDuPV9BsBN9AT397lFfRPFt155u~yeBHZ4JlUN2GINUBt0-CzGuYVq3dsO kYYEZJo9cQTVhArpo7ek03VbDP5egtCM8obN63AEkA__&Key-Pair-Id=APKAJGWDVCU5SXAPJELQ (403 Prohibido) Error de cliente
pipe:0 : se encontraron datos no válidos al procesar la entrada
consejo, por favor, qué servidor proxy es bueno para streamlink, si lo hay
Comentario más útil
Lamentablemente, esto no está relacionado con el problema que identificó y se debe completamente al OpenSSL de mierda con el que OS X se envía de manera predeterminada. La versión 0.9.8y tiene algunos problemas reales con la realización de protocolos de enlace SSL, y algunos servidores no lo toleran bien. Usar Python 3 en mi caja OS X (por lo tanto, usar un OpenSSL más nuevo) revela que no hay problema.
Tienes dos opciones:
env ARCHFLAGS="-arch x86_64" LDFLAGS="-L/usr/local/opt/openssl/lib" CFLAGS="-I/usr/local/opt/openssl/include" pip install PyOpenSSL
.