SSL: no shared cipher #457
Comments
|
You should try this, and report back: |
|
@maximiliankaul Same error? Different error? |
|
The |
|
@chris001 same error. @nicolas33 I’m not sure I understand. Should I set it in To clearify, this is the config I’m using to test your suggestion: And this is the error: |
Github-ref: OfflineIMAP#457 Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
|
Please try above version so we get a bit more info while in debug mode. This will help understanding what's going on. |
|
The error looks to be different with your branch: Adding parantheses in offlineimap/imapserver.py line 531 I get: |
|
My patch was wrong and you correctly fixed it. Now, it looks like the ssl negociation is ok. My best guess is that something changed at server side. However, I don't get why this new error, yet. What gives |
Github-ref: #457 Tested-by: Maximilian Kaul <https://github.com/maximiliankaul> Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
|
I wonder the above error is with Py3. Could you stick to Py2, please? |
|
I think this may be a problem with pyopenssl on python 2.7 and latest openssl (I tested using the same versions as @maximiliankaul), I've pasted below an attempt to manually make a TLS1.2 connection - FWIW the server is Dovecot 2.2.28 also on Arch: In [1]: import socket
In [2]: import ssl
In [3]: ssl.OPENSSL_VERSION
Out[3]: 'OpenSSL 1.1.0e 16 Feb 2017'
In [4]: sor = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
In [5]: sw = ssl.wrap_socket(sor, ssl_version=ssl.PROTOCOL_TLSv1_2)
In [6]: sw.connect(('server', 993))
SSLError Traceback (most recent call last)
<ipython-input-6-89c46c317283> in <module>()
----> 1 sw.connect(('server', 993))
/usr/lib64/python2.7/ssl.pyc in connect(self, addr)
874 """Connects to remote ADDR, and then wraps the connection in
875 an SSL channel."""
--> 876 self._real_connect(addr, False)
877
878 def connect_ex(self, addr):
/usr/lib64/python2.7/ssl.pyc in _real_connect(self, addr, connect_ex)
865 self._connected = True
866 if self.do_handshake_on_connect:
--> 867 self.do_handshake()
868 return rc
869 except (OSError, ValueError):
/usr/lib64/python2.7/ssl.pyc in do_handshake(self, block)
838 if timeout == 0.0 and block:
839 self.settimeout(None)
--> 840 self._sslobj.do_handshake()
841 finally:
842 self.settimeout(timeout)
SSLError: [SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] sslv3 alert handshake failure (_ssl.c:661) |
|
@GeorgeBrooke which versions of pyopenssl and openssl work for you? |
|
@nicolas33 I have not tried downgrading yet, but I believe the last working version was openssl-1.0.2.k and python2-pyopenssl-16.2.0 However looking at the server logs I believe this is a cipher mismatch with a confusing error message - I was using Mozilla's modern ssl cipherlist from https://wiki.mozilla.org/Security/Server_Side_TLS and switching back to the default dovecot setting or Mozilla's intermediate I can connect again. |
|
@nicolas33 Yes, I just executed I saw you included the debug info also in the official repository “next” branch which is what I’m using below: And the output of @GeorgeBrooke: yes, I think you are correct with your assumption. Here is a log from my server (dovecot): |
So, you get your answer. I have no idea how to configure the client or the server so they can share a cipher, though. |
|
Probably it's caused by imaplib2 not using the modern ssl cipher suite. https://wiki.mozilla.org/Security/Server_Side_TLS
|
|
Good point. I don't know what the python ssl module does when we pass pre-defined ciphers. Is it required they are all supported? What if ssl is not provided by openssl? We should check this and likely update imaplib2. We might like to expose a new configuration option up to the user if the ssl module is very strict on the ciphers passed to it. |
|
The selection of SSL ciphers in python was a very controversial topic in this 2014 bug: Recent bugs related to the python's ssl cipher selection: |
|
This tends to convince me that our best alternative is to have the users configure the ciphers by their own. This is a quite rare issue, though. This is the first cipher issue I'm aware, at least. OTOH, I wonder most users would use the feature wrong. Especially since we have very poor error messages from the IMAP servers. Also, I would not be surprised that IMAP servers silently change of SSL ciphers without notification to the users. We would not have found the issue if @maximiliankaul did'n't have access to the server logs. We might need to add a big warning if we do this. @maximiliankaul What about configuring your server with new ciphers? |
|
@GeorgeBrooke Good job at finding the culprit! This was far from easy! |
Any suggestions which ciphers to use? Currently my dovecot uses This is based on the aforementioned modern cipher list from Mozilla. I think the configuration works as indendet: For what it’s worth: offlineimap was fine with this configuration for months. I last changes this setting October 2016 and have been successfully using offlineimap until recently. |
Try these: |
nicolas33
changed the title
|
@chris001 your cipher list works. |
|
@maximiliankaul |
|
Just to clarify @maximiliankaul you set that cipher list in dovecot so it was necessary to make server-side changes to work around this? I think this is a python/ssl regression and therefore not an offlineimap bug, but it is a regression there as the ciphers were working correctly before. |
That’s correct. |
|
@GeorgeBrooke It's possible also to change of cipher list, on the python (IMAP client) side. @nicolas33 The relevant line of code is here: offlineimap/offlineimap/bundled_imaplib2.py Line 548 in c883160 Only six of the 10 parameters are passed: self.sock = ssl.wrap_socket(self.sock, self.keyfile, self.certfile, ca_certs=self.ca_certs, cert_reqs=cert_reqs, ssl_version=ssl_version)
This is the python 2.7 function prototype for Or, the SSLContext object can be called directly, to set the cipher list: |
|
@chris001 Are you saying that specifying Gives the following error (note: I only changed the server cipher list to test the ones you suggested earlier, but reverted back to my old cipher list): |
|
@maximiliankaul You picked one specific cipher. Probably this cipher is not shared between python client and your dovecot imap server. Could you try it with the string: |
|
I think exposing the ciphers to our users is an interesting feature. However, this issue is rare enough and I won't implement it myself at this time. Changes into imaplib2 must be sent upstream. |
|
You can run this command on your python client system to see which ciphers are available to it. |
|
I did some more wireshark debugging and everything seems to be fine on the offlineimap end. I still don’t understand why it did not use @nicolas33 Should I close this issue, or do you want to keep it open until the ciphers are exposed to the users? |
|
I think we'd better keep this issue open. |
|
IMO the sensible thing is to have |
|
I have this issue with a mail-in-a-box-like configuration, but on Debian latest stable (with libssl version 1.0.2l-2) https://github.com/mail-in-a-box/mailinabox/blob/master/setup/mail-dovecot.sh#L88 If I revert to a weaker configuration it works: |
|
Best is to make our |
|
I know, as a matter of fact I didn't do it :-) I'm looking for a patch to apply to imaplib2 to workaround this. |
|
The line of code to modify is here: |
General informations
Arch Linux
offlineimap version (
offlineimap -V):offlineimap v7.1.0, imaplib2 v2.57 (bundled), Python v2.7.13Python version:
Python 2.7.13andPython 3.6.1server name or domain:
mail.maximiliankaul.de
CLI options:
-dALLConfiguration file offlineimaprc
pythonfile (if any)
Logs, error
Steps to reproduce the error
offlineimapwith the above config.Notes
TLS 1.2ssl_versionin config file did not help.s_client:The text was updated successfully, but these errors were encountered: