i need to do a script for imap backup but when i'm trying to connect to the imap server with my script i'm getting that error:
File "c:\Users\Lenovo\Desktop\python\progettoscuola.py", line 5, in <module>
imapSrc = imaplib.IMAP4_SSL('mail.safemail.it')
File "C:\Program Files\Python310\lib\imaplib.py", line 1323, in __init__
IMAP4.__init__(self, host, port, timeout)
File "C:\Program Files\Python310\lib\imaplib.py", line 202, in __init__
self.open(host, port, timeout)
File "C:\Program Files\Python310\lib\imaplib.py", line 1336, in open
IMAP4.open(self, host, port, timeout)
File "C:\Program Files\Python310\lib\imaplib.py", line 312, in open
self.sock = self._create_socket(timeout)
File "C:\Program Files\Python310\lib\imaplib.py", line 1327, in _create_socket
return self.ssl_context.wrap_socket(sock,
File "C:\Program Files\Python310\lib\ssl.py", line 512, in wrap_socket
return self.sslsocket_class._create(
File "C:\Program Files\Python310\lib\ssl.py", line 1070, in _create
self.do_handshake()
File "C:\Program Files\Python310\lib\ssl.py", line 1341, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] sslv3 alert handshake failure (_ssl.c:997)```
Python 3.10 increased the default security settings of the TLS stack by among other things prohibiting any ciphers which still use the RSA key exchange. RSA key exchange is long considered inferior since it does not provide forward secrecy and is therefore also no longer available in TLS 1.3. So in general the change in Python 3.10 can be considered an improvement.
But, some servers still require this obsolete key exchange and mail.safemail.it seems to be among these. Connecting to such servers with the newly hardened TLS settings will now fail, even if it succeeded with older versions of Python.
To make connections possible again it is necessary to use weaker security settings. For this specific server it can be done by falling back to the DEFAULT ciphers used by OpenSSL. The following code will create a new SSL context and use it for connecting to the host. The important part here is to use weaker settings using ctx.set_ciphers('DEFAULT') .
import imaplib
import ssl
ctx = ssl.create_default_context()
ctx.set_ciphers('DEFAULT')
imapSrc = imaplib.IMAP4_SSL('mail.safemail.it', ssl_context = ctx)
Related
I'm working on an implicit TLS connection program with Python ftplib. I tried the solution provided in question python-ftp-implicit-tls-connection-issue(including Rg Glpj's and Juan Moreno's answers) to make the connection. But when I call retrline or retrbinary after logging into the ftp server like this(FTP_ITLS is the subclass of FTP_TLS):
58 server = FTP_ITLS()
59 server.connect(host="x.x.x.x", port=990)
60 server.login(user="user", passwd="******")
61 server.prot_p()
62
63 server.cwd("doc")
64 print(server.retrlines('LIST'))
65 # server.retrbinary('RETR contents.7z', open('contents.7z', 'wb').write)
66 server.quit()
I got an EOF error:
Traceback (most recent call last):
File "D:/Coding/test/itls.py", line 64, in <module>
print(server.retrlines('LIST'))
File "D:\Python\Python27\lib\ftplib.py", line 735, in retrlines
conn = self.transfercmd(cmd)
File "D:\Python\Python27\lib\ftplib.py", line 376, in transfercmd
return self.ntransfercmd(cmd, rest)[0]
File "D:\Python\Python27\lib\ftplib.py", line 713, in ntransfercmd
server_hostname=self.host)
File "D:\Python\Python27\lib\ssl.py", line 352, in wrap_socket
_context=self)
File "D:\Python\Python27\lib\ssl.py", line 579, in __init__
self.do_handshake()
File "D:\Python\Python27\lib\ssl.py", line 808, in do_handshake
self._sslobj.do_handshake()
ssl.SSLEOFError: EOF occurred in violation of protocol (_ssl.c:590)
As it seems ftplib uses PROTOCOL_SSLv23 as the default protocol in Python 2.7, I tried
PROTOCOL_TLSv1, PROTOCOL_TLSv1_1 and PROTOCOL_TLSv1_2, but none of them worked. And I also tried overriding ntransfercmd and auth, or setting ctx = ssl._create_stdlib_context(ssl.PROTOCOL_TLSv1) as Steffen Ullrich said in question connect-to-ftp-tls-1-2-server-with-ftplib, but the error never disappeared. What can I do then? Thanks.
I ran into this trying to connect to a FileZilla FTP server. FileZilla has a setting in the "FTP over TLS settings" called "Require TLS session resumption on data connection when using PROT P". Disabling this option fixed this problem.
If you don't have control over the server, check out FTPS with Python ftplib - Session reuse required which goes over how to enable session reuse. This seems to require Python 3.6+, however.
How do you fix an SSL error caused by a CNAME DNS record?
I have an API hosted on AWS accessible from a URL like https://sd098fs0f98s9f0s.execute-api.us-east-1.amazonaws.com.
To shorten this and rebrand it a little, I setup a CNAME record to map myapi.mydomain.com to sd098fs0f98s9f0s.execute-api.us-east-1.amazonaws.com.
Using the original URL, this simple Python is able to access the API perfectly:
import requests
r = requests.get(url='https://sd098fs0f98s9f0s.execute-api.us-east-1.amazonaws.com')
However, using the new URL:
import requests
r = requests.get(url='https://myapi.mydomain.com')
results in the error:
Traceback (most recent call last):
File ".env/lib/python3.7/site-packages/urllib3/connectionpool.py", line 603, in urlopen
chunked=chunked)
File ".env/lib/python3.7/site-packages/urllib3/connectionpool.py", line 344, in _make_request
self._validate_conn(conn)
File ".env/lib/python3.7/site-packages/urllib3/connectionpool.py", line 843, in _validate_conn
conn.connect()
File ".env/lib/python3.7/site-packages/urllib3/connection.py", line 370, in connect
ssl_context=context)
File ".env/lib/python3.7/site-packages/urllib3/util/ssl_.py", line 355, in ssl_wrap_socket
return context.wrap_socket(sock, 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.SSLError: [SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:1076)
What's causing this and how do I fix it?
I see that you're using https. The server certificate is issued to specific hostname (Common name attribute). This name has to match the address you're trying to access with HTTPS. If you added DNS CNAME you have to update the certificate. If I recall correctly you have to add CNAME as Alternative Subject Name attribute, so you'll need a new certificate.
The error "WRONG_VERSION_NUMBER" might be somewhat misleading. It means that the server presented a wrong TLS version. In the TLS handshake, client and the server negotiate the TLS version. If the server supports only 1.0 and your client accept only 1.2+ then "WRONG_VERSION_NUMBER" will appear. But it might also happen if the client gets some unexpected data, like a plain HTTP instead of HTTPS. To check what exactly was the unexpected data, you'll have to capture wireshark / tcpdump network traffic logs. I wasted a lot of time debugging wrong_version_number recently. Only after looking at wireshark logs it became clear that it was the China firewall, because we got HTTP Forbidden to the initial Client Hello.
I'm working on an implicit TLS connection program with Python ftplib. I tried the solution provided in question python-ftp-implicit-tls-connection-issue(including Rg Glpj's and Juan Moreno's answers) to make the connection. But when I call retrline or retrbinary after logging into the ftp server like this(FTP_ITLS is the subclass of FTP_TLS):
58 server = FTP_ITLS()
59 server.connect(host="x.x.x.x", port=990)
60 server.login(user="user", passwd="******")
61 server.prot_p()
62
63 server.cwd("doc")
64 print(server.retrlines('LIST'))
65 # server.retrbinary('RETR contents.7z', open('contents.7z', 'wb').write)
66 server.quit()
I got an EOF error:
Traceback (most recent call last):
File "D:/Coding/test/itls.py", line 64, in <module>
print(server.retrlines('LIST'))
File "D:\Python\Python27\lib\ftplib.py", line 735, in retrlines
conn = self.transfercmd(cmd)
File "D:\Python\Python27\lib\ftplib.py", line 376, in transfercmd
return self.ntransfercmd(cmd, rest)[0]
File "D:\Python\Python27\lib\ftplib.py", line 713, in ntransfercmd
server_hostname=self.host)
File "D:\Python\Python27\lib\ssl.py", line 352, in wrap_socket
_context=self)
File "D:\Python\Python27\lib\ssl.py", line 579, in __init__
self.do_handshake()
File "D:\Python\Python27\lib\ssl.py", line 808, in do_handshake
self._sslobj.do_handshake()
ssl.SSLEOFError: EOF occurred in violation of protocol (_ssl.c:590)
As it seems ftplib uses PROTOCOL_SSLv23 as the default protocol in Python 2.7, I tried
PROTOCOL_TLSv1, PROTOCOL_TLSv1_1 and PROTOCOL_TLSv1_2, but none of them worked. And I also tried overriding ntransfercmd and auth, or setting ctx = ssl._create_stdlib_context(ssl.PROTOCOL_TLSv1) as Steffen Ullrich said in question connect-to-ftp-tls-1-2-server-with-ftplib, but the error never disappeared. What can I do then? Thanks.
I ran into this trying to connect to a FileZilla FTP server. FileZilla has a setting in the "FTP over TLS settings" called "Require TLS session resumption on data connection when using PROT P". Disabling this option fixed this problem.
If you don't have control over the server, check out FTPS with Python ftplib - Session reuse required which goes over how to enable session reuse. This seems to require Python 3.6+, however.
I have a Python SSL server that uses a self-signed certificate. I start my server like this:
httpd = BaseHTTPServer.HTTPServer(('', 443), MyHTTPHandler)
httpd.socket = ssl.wrap_socket (httpd.socket, certfile='server.pem', server_side=True, cert_reqs=0)
httpd.serve_forever()
I get the following error when I connect using Firefox:
----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 51194)
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 295, in _handle_request_noblock
self.process_request(request, client_address)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 321, in process_request
self.finish_request(request, client_address)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 334, in finish_request
self.RequestHandlerClass(request, client_address, self)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 655, in __init__
self.handle()
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/BaseHTTPServer.py", line 340, in handle
self.handle_one_request()
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/BaseHTTPServer.py", line 310, in handle_one_request
self.raw_requestline = self.rfile.readline(65537)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/socket.py", line 480, in readline
data = self._sock.recv(self._rbufsize)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ssl.py", line 734, in recv
return self.read(buflen)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ssl.py", line 621, in read
v = self._sslobj.read(len or 1024)
SSLError: [SSL: TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:1751)
----------------------------------------
I do not see this behavior with Chrome or another client. It only happens on the first connection (complaints about certificate) until I accept the certificate. The exception actually does not cause the program to quit.
Why am I getting an error on the server? How can I avoid the exception?
The TLv1 unknown CA alert is sent by some clients if they cannot verify the certificate of the server because it is signed by an unknown issuer CA. You can avoid this kind of exception if you use a certificate which is already trusted by the client or which can be validated against a root CA of the client (don't forget to include the chain certificates too).
If you cannot avoid this error (for instance because you are using a self-signed certificate) then you have to catch the exception and deal with it by closing the connection. You might need to do this by using handle_request to handle each request by itself and catch exceptions instead of using serve_forever.
I had the same error as you, even though I had a signed certificate from Sectigo. Turns out, you need a certificate chain rather than only your domain's certificate itself.
Source
While referring to this site, and the following video: https://www.youtube.com/watch?v=_YjX7rtiAsk
, I found that I need to create a new file called certificate-chain.pem, and manually/with the help of scripts concatenate (join) three certificates - domain certificate, CA certificate and the USERTrust certificate, one after the other.
Then, in the file you need, point to this certificate bundle/chain. This is a solution which I wept on for 7 hours.
I have been using django send_mail for a long while. however on a new project which use django 1.4 and I changed my dev machine I have a very strange problem.
when I call send_mail on the standard backend with all the settings (EMAIL_HOST='localhost' EMAIL_PORT=25,etc) I am getting the error :
File "c:\python27\lib\site-packages\django\core\mail\backends\smtp.py", line 4
8, in open local_hostname=DNS_NAME.get_fqdn())
File "c:\python27\lib\smtplib.py", line 249, in __init__
(code, msg) = self.connect(host, port)
File "c:\python27\lib\smtplib.py", line 309, in connect
self.sock = self._get_socket(host, port, self.timeout)
File "c:\python27\lib\smtplib.py", line 284, in _get_socket
return socket.create_connection((port, host), timeout)
File "c:\python27\lib\socket.py", line 571, in create_connection
raise err
socket.error: [Errno 10013] An attempt was made to access a socket in a way forb
idden by its access permissions
I have no clue what I am doing wrong, I have debugged it and it seems that the connect function recieve the right port and host however its getting forbidden. I suspected its maybe my antivirus but disabling it didnt help.
I am running on administrator privilages (UAC disabled) if anyone consider this to be the problem.
Strange. I changed my email server (python SMTPd) to port 1025 instead of 25 and everything back to normal....