On a specific URL I am getting ssl.SSLError: [SSL: WRONG_SIGNATURE_TYPE] wrong signature type using Python's requests library.
I have tried the answers at python requests : SSL error during requests? but they do not help.
Not even verify=False from, e.g., Python Requests throwing SSLError, helps:
url = 'https://infoteka.bg.ac.rs/ojs/index.php/Infoteka/issue/view/20'
import requests
response = requests.get(url, verify=False)
gives
Traceback (most recent call last):
File "/usr/local/lib/python3.8/dist-packages/urllib3/connectionpool.py", line 699, in urlopen
...
File "/usr/lib/python3.8/ssl.py", line 1309, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: WRONG_SIGNATURE_TYPE] wrong signature type (_ssl.c:1131)
I have the most recent distribution package of openssl:
$ openssl version
OpenSSL 1.1.1f 31 Mar 2020
Though I note that upgrading to 1.1.1g stated at https://stackoverflow.com/a/63387377/589165 could perhaps solve the problem.
My webbrowsers do not have a problem with the particular page (as far as I can tell), while both wget and curl have the same problem as requests.
What are the options here? Would it be necessary to manually install a newer version of openssl? Or are there other possible workarounds?
Related
Running python version 3.9.1 on arch linux with OpenSSL version 1.1.1i and pyopenssl version 1.1.1i I get the following error when trying to use an https proxy with the requests module:
Traceback (most recent call last):
File "/usr/lib/python3.9/site-packages/urllib3/connectionpool.py", line 696, in urlopen
self._prepare_proxy(conn)
File "/usr/lib/python3.9/site-packages/urllib3/connectionpool.py", line 964, in _prepare_proxy
conn.connect()
File "/usr/lib/python3.9/site-packages/urllib3/connection.py", line 359, in connect
conn = self._connect_tls_proxy(hostname, conn)
File "/usr/lib/python3.9/site-packages/urllib3/connection.py", line 496, in _connect_tls_proxy
return ssl_wrap_socket(
File "/usr/lib/python3.9/site-packages/urllib3/util/ssl_.py", line 424, in ssl_wrap_socket
ssl_sock = _ssl_wrap_socket_impl(sock, context, tls_in_tls)
File "/usr/lib/python3.9/site-packages/urllib3/util/ssl_.py", line 466, in _ssl_wrap_socket_impl
return ssl_context.wrap_socket(sock)
File "/usr/lib/python3.9/ssl.py", line 500, in wrap_socket
return self.sslsocket_class._create(
File "/usr/lib/python3.9/ssl.py", line 1040, in _create
self.do_handshake()
File "/usr/lib/python3.9/ssl.py", line 1309, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:1123)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3.9/site-packages/requests/adapters.py", line 439, in send
resp = conn.urlopen(
File "/usr/lib/python3.9/site-packages/urllib3/connectionpool.py", line 755, in urlopen
retries = retries.increment(
File "/usr/lib/python3.9/site-packages/urllib3/util/retry.py", line 573, in increment
raise MaxRetryError(_pool, url, error or ResponseError(cause))
urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='google.com', port=443): Max retries exceeded with url: / (Caused by SSLError(SSLError(1, '[SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:1123)')))
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python3.9/site-packages/requests/api.py", line 76, in get
return request('get', url, params=params, **kwargs)
File "/usr/lib/python3.9/site-packages/requests/api.py", line 61, in request
return session.request(method=method, url=url, **kwargs)
File "/usr/lib/python3.9/site-packages/requests/sessions.py", line 542, in request
resp = self.send(prep, **send_kwargs)
File "/usr/lib/python3.9/site-packages/requests/sessions.py", line 655, in send
r = adapter.send(request, **kwargs)
File "/usr/lib/python3.9/site-packages/requests/adapters.py", line 514, in send
raise SSLError(e, request=request)
requests.exceptions.SSLError: HTTPSConnectionPool(host='google.com', port=443): Max retries exceeded with url: / (Caused by SSLError(SSLError(1, '[SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:1123)')))
The code I am running is:
import requests
proxy = {
'https' : 'https://proxyip:proxyport'
}
requests.get("https://google.com", proxies=proxy)
No matter what https proxy I try, I get the same error. I have also reinstalled both openssl and python with no change. Any suggestions?
... line 496, in _connect_tls_proxy
Your code is trying to use the (new) support for accessing the proxy itself over HTTPS. This is done because you've explicitly given that URL as the proxy as https://... and not http://...:
'https' : 'https://proxyip:proxyport'
^^^^^^
It is very likely that the proxy itself does not support TLS connections to the proxy. Commonly HTTP proxies have a plain HTTP connections to the proxy only. They still can proxy HTTPS traffic this way, since the client will simply issue a CONNECT request to the proxy to create a tunnel and then use end-to-end TLS between client and server.
Accessing a proxy by HTTPS will add an additional layer of TLS between client and proxy, which is not supported by most proxies. Therefore, you likely need plain HTTP proxy instead:
'https' : 'http://proxyip:proxyport'
^^^^^^
Note that in older versions of the requests library both access with http:// and https:// worked. These older versions had no support for HTTPS to the proxy and simply used plain HTTP even if https:// would be specified.
Add login.microsoftonline.com;management.azure.com as exceptions will work.
it was fixed with my case by this command:
python3 -m pip install urllib3==1.22
I am using meson build system, but this morning I have a problem with
wrapdb.mesonbuild.com.
With my computer and another one (for checking), when using a web browser like Chromium or Firefox, I get messages like:
Your connection is not private
Attackers might be trying to steal your information from wrapdb.mesonbuild.com
(for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_DATE_INVALID
(I have checked my computer time etc... with ntpdate... so I priori this is not the origin of the problem)
Also any attempt to use:
meson wrap list
fails, with output like:
SSL connection failed. Falling back to unencrypted connections.
Traceback (most recent call last):
File "/usr/lib/python3.7/urllib/request.py", line 1317, in do_open
encode_chunked=req.has_header('Transfer-encoding'))
File "/usr/lib/python3.7/http/client.py", line 1252, in request
self._send_request(method, url, body, headers, encode_chunked)
File "/usr/lib/python3.7/http/client.py", line 1298, in _send_request
self.endheaders(body, encode_chunked=encode_chunked)
File "/usr/lib/python3.7/http/client.py", line 1247, in endheaders
self._send_output(message_body, encode_chunked=encode_chunked)
File "/usr/lib/python3.7/http/client.py", line 1026, in _send_output
self.send(msg)
File "/usr/lib/python3.7/http/client.py", line 966, in send
self.connect()
File "/usr/lib/python3.7/http/client.py", line 1422, in connect
server_hostname=server_hostname)
File "/usr/lib/python3.7/ssl.py", line 423, in wrap_socket
session=session
File "/usr/lib/python3.7/ssl.py", line 870, in _create
self.do_handshake()
File "/usr/lib/python3.7/ssl.py", line 1139, in do_handshake
self._sslobj.do_handshake()
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: certificate has expired (_ssl.c:1076)
Can you reproduce? I cannot find the source of the problem.
update: it seems that wrapdb.mesonbuild.com has already been down in the past:
https://github.com/mesonbuild/meson/issues/3497
maybe this is my current problem.
update 2: I did not have the reflex but with
https://www.sslshopper.com/ssl-checker.html#hostname=wrapdb.mesonbuild.com
one can see that the site's certificate expired yesterday...
Also thanks to #TomEsposito for pointing out this.
It appears their SSL Certificate expired yesterday, but they are still using HTTPS. Until they update their certificate, or move to an HTTP connection, your browser will continue to warn you of this. All modern browsers now warn users when a site is using HTTPS but there is no certificate
Trying to get a working installation of the Google EarthExplorer. I am inside a robust corporate firewall, and had to examine the certificate used by Chrome to verify the server/address being verified (using Chrome's dev tools).
After some reading - it looks like the situation is that:
1) when calling Initialize method on ee object, ee uses requests to manage the connection.
2) To configure the VirtualEnv correctly, I had to configure my virtualenv to use the organization provided certificate. Based on this SE (SE Python SSL Requests...) I was clued in to the fact that the python stack was using requests, which along with certifi manage a cert bundle for SSL on python.
3) After configuring the supplied certificate (matching that used with Chrome), I can open a connection to google inside my VirtualEnv using requests. Great!
(earthengine) X:\_01_VirtualEnvs\earthengine>python
Python 2.7.10 (default, May 23 2015, 09:40:32) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import requests
>>> requests.get("https://earthengine.google.com/", verify = True)
<Response [200]>
>>>
I think this is 'working' now ... when I try the same outside of the VirtualEnv, I get failed SSL3_GET_SERVER_CERTIFICATE... message. This lets me know that I got my certificate in the right place, and it seems to be working correctly.
However, I'm still getting errors on the ee.Initialize():
>>> ee.Initialize()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "X:\_01_VirtualEnvs\earthengine\lib\site-packages\ee\__init__.py", line 9
3, in Initialize
ApiFunction.initialize()
File "X:\_01_VirtualEnvs\earthengine\lib\site-packages\ee\apifunction.py", lin
e 151, in initialize
signatures = data.getAlgorithms()
File "X:\_01_VirtualEnvs\earthengine\lib\site-packages\ee\data.py", line 410,
in getAlgorithms
return send_('/algorithms', {}, 'GET')
File "X:\_01_VirtualEnvs\earthengine\lib\site-packages\ee\data.py", line 738,
in send_
response, content = send_with_backoff()
File "X:\_01_VirtualEnvs\earthengine\lib\site-packages\ee\data.py", line 735,
in send_with_backoff
'Unexpected HTTP error: %s' % e.message)
ee.ee_exception.EEException: Unexpected HTTP error: [Errno 1] _ssl.c:510: error:
14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Anyone have any ideas on what is going wrong here? I thought that ee was using requests, therefore setting the python environments' requests properly.
From looking at the exception trace-back, it seems that ee has sub-class of requests based on the similarity of the trace-back signature... am I reading this right? The trace-back in both cases points towards the same _ssl.c:510 failure - failing on the same filename on the same line?
Is there a way to get more info from the exception? I'm really at a loss at this point.
So it looks like the EE stack is using httplib2 to handle the authentication. This gives a few options:
In data.py ~ line 700 Override the SSL check (the quick and dirty):
http = httplib2.Http(timeout=(_deadline_ms / 1000.0) or None,
disable_ssl_certificate_validation=True)
It looks like you should be able to explicitly direct httplib2 when instantiating the http connection object with:
HTTPLIB_CA_CERTS_PATH = os.environ.get('HTTPLIB_CA_CERTS_PATH')
http = httplib2.Http(timeout=(_deadline_ms / 1000.0) or None,
ca_certs=HTTPLIB_CA_CERTS_PATH)
I found this in the ca_certs_locator module, __init__.py. It is being sourced in the ee.Initialize() method (probably through something in data.py but I can't back track it. Regardless, the second option (explicitly passing the ca_certs path) doesn't solve the problem.
I'm rolling with the disable SSL validation, and using only earthengine.google.com endpoint.
In more recent versions, the ee.Initialize() method is accepting a http_transport argument, so we no longer need to modify its source code, but rather create it in our own:
_http_transport = httplib2.Http(disable_ssl_certificate_validation=True)
ee.Initialize(credentials, http_transport=_http_transport)
This way you can also control the ca_certs option, but I haven't tried that one.
I think my university recently changed a firewall or filtering protocol with regards to Twitter's streaming API. However, for me to provide them more information, I'm going to have to figure out the details.
Ok, below is the simplest possible program to collect data from Twitter's stream:
from tweepy import Stream
from tweepy import OAuthHandler
from tweepy.streaming import StreamListener
ckey="[OMITED]"
csecret="[OMITED]"
atoken="[OMITED]"
asecret="[OMITED]"
class listener(StreamListener):
def on_data(self, data):
print(data)
return(True)
def on_error(self, status):
print status
auth = OAuthHandler(ckey, csecret)
auth.set_access_token(atoken, asecret)
twitterStream = Stream(auth, listener())
twitterStream.filter(track=["car"])
When I run this program on my laptop/home desktop, it works fine. However, I have a university computer setup for data collection and it produces the following error:
Traceback (most recent call last):
File "test.py", line 25, in <module>
twitterStream.filter(track=["car"])
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/tweepy/streaming.py", line 228, in filter
self._start(async)
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/tweepy/streaming.py", line 172, in _start
self._run()
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/tweepy/streaming.py", line 106, in _run
conn.connect()
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 1278, in connect
server_hostname=server_hostname)
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ssl.py", line 352, in wrap_socket
_context=self)
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ssl.py", line 579, in __init__
self.do_handshake()
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ssl.py", line 808, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)
Now, the thing is, I can open up Safari and browse the web. Further, data collection like this use to work (as of a month ago). The error says the SSL cert is failing verification (but strangely the original OAuth seems to work -- it is the filter command kicking up the error). Is there a way to get it to spit out if that is because an intermediate cert has been put in place? Or maybe a port is being blocked? Basically, is there a way to get a lot more details so I can go the university and say: 'you are blocking X'?
Any suggestions?
I've resolved the situation. It was an error relating to SSL sites that were signed with Digicerts.
I encountered the following perculiar behaviour today.
The following code works on Python 3.3:
smtp = smtplib.SMTP()
smtp.connect(host="smtp.gmail.com", port=587)
smtp.ehlo()
smtp.starttls()
In Python 3.4 the above code doesn't work, instead the following error is encountered:
File "smtp_test.py", line 10, in <module>
smtp.starttls()
File "/usr/lib/python3.4/smtplib.py", line 676, in starttls
server_hostname=server_hostname)
File "/usr/lib/python3.4/ssl.py", line 344, in wrap_socket
_context=self)
File "/usr/lib/python3.4/ssl.py", line 540, in __init__
self.do_handshake()
File "/usr/lib/python3.4/ssl.py", line 767, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: TLSV1_ALERT_DECODE_ERROR] tlsv1 alert decode error (_ssl.c:598)
If the above code is modified to specify the host and port in the constructor and not use the connect method, as in the code below, then it works.
smtp = smtplib.SMTP(host="smtp.gmail.com", port=587)
smtp.ehlo()
smtp.starttls()
The above behaviour occurs with OpenSSL version 1.0.1f and OpenSSL 1.0.1g
Could someone explain this behaviour to me ?
According to a tcpdump the code in 3.4 sends in SNI extension with an empty target name. SNI (Server Name Indication) is used when having different certificates behind the same IP address. I consider this a bug: if it does not have a name it should not send the SNI extension instead of sending an extension with a zero-length name in it.