-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello
I recently upgraded to dovecot 2.1.7 (as supplied with Debian Weezy). All clients work as expected except for Outlook (2013 &2010) on Win8 with a SSL/TLS connection. (Thunderbird on Win8 and Outlook 2013 on Win 7 works fine. On my previous dovecot version 1.2.13 all clients worked.) As far as I understand, one difference is the support for TLS1.2 and SSL3. And on the client side Win8 is now connecting through the Microsoft Unified Security Protocol Provider.
My logs show these issues:
Dovecot: May 06 21:05:43 imap-login: Warning: SSL: where=0x2002, ret=-1: SSLv3 read client certificate A [78.42.x.x] May 06 21:05:43 imap-login: Warning: SSL: where=0x2002, ret=-1: SSLv3 read client certificate A [78.42.x.x] May 06 21:05:43 imap-login: Warning: SSL failed: where=0x2002: SSLv3 read client certificate A [78.42.x.x] May 06 21:05:43 imap-login: Info: Disconnected (no auth attempts in 0 secs): user=<>, rip=78.42.x.x, lip=144.76.x.x, TLS handshaking: Disconnect
Outlook 2013 (contains German, translation in []): IMAP: 12:30:02 [db] Mit 'mail.xxx.de' wird eine Verbindung an Port 143 hergestellt. [A connection to port 143 is established with 'mail.xxx.de'] [snip] IMAP: 12:30:02 [rx] * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5] Welcome at mail.xxx.de [snip] IMAP: 12:30:02 [rx] hmpc OK Pre-login capabilities listed, post-login capabilities have more.IMAP: 12:30:02 [tx] ekum STARTTLS IMAP: 12:30:02 [db] OnNotify: asOld = 5, asNew = 5, ae = 3 IMAP: 12:30:02 [rx] ekum OK Begin TLS negotiation now. IMAP: 12:30:02 [db] Mit 'Microsoft Unified Security Protocol Provider' wird eine sichere Verbindung ausgehandelt. [A secure connection is negotiated with 'Microsoft Unified Security Protocol Provider'] IMAP: 12:30:02 [db] OnNotify: asOld = 5, asNew = 6, ae = 2 IMAP: 12:30:03 [db] Die Verbindung mit 'mail.xxx.de' wurde geschlossen. [Connection to 'mail.xxx.de' has been closed.] IMAP: 12:30:03 [db] OnNotify: asOld = 6, asNew = 0, ae = 5 IMAP: 12:30:03 [db] ERROR: "Es kann keine sichere Verbindung mit dem Server hergestellt werden.", hr=2148322330 [Can't establish a secure connection with the server.]
My settings for ssl_protocols and ssl_cipher_list are empty. Since it works with most clients, I assume no broken certificates or my dovecot configuration. The connection fails at the TLS/SSL handshake. Has anyone seen this behaviour, too? Is there a setting (for ssl_protocols and ssl_cipher_list) to support Outlook on Win8?
Thanks, Sebastian
Am 07.05.2014 21:15, schrieb Sebastian Goodrick:
Hello
I recently upgraded to dovecot 2.1.7 (as supplied with Debian Weezy). All clients work as expected except for Outlook (2013 &2010) on Win8 with a SSL/TLS connection. (Thunderbird on Win8 and Outlook 2013 on Win 7 works fine. On my previous dovecot version 1.2.13 all clients worked.) As far as I understand, one difference is the support for TLS1.2 and SSL3. And on the client side Win8 is now connecting through the Microsoft Unified Security Protocol Provider.
My logs show these issues:
Dovecot: May 06 21:05:43 imap-login: Warning: SSL: where=0x2002, ret=-1: SSLv3 read client certificate A [78.42.x.x] May 06 21:05:43 imap-login: Warning: SSL: where=0x2002, ret=-1: SSLv3 read client certificate A [78.42.x.x] May 06 21:05:43 imap-login: Warning: SSL failed: where=0x2002: SSLv3 read client certificate A [78.42.x.x] May 06 21:05:43 imap-login: Info: Disconnected (no auth attempts in 0 secs): user=<>, rip=78.42.x.x, lip=144.76.x.x, TLS handshaking: Disconnect
Outlook 2013 (contains German, translation in []): IMAP: 12:30:02 [db] Mit 'mail.xxx.de' wird eine Verbindung an Port 143 hergestellt. [A connection to port 143 is established with 'mail.xxx.de'] [snip] IMAP: 12:30:02 [rx] * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5] Welcome at mail.xxx.de [snip] IMAP: 12:30:02 [rx] hmpc OK Pre-login capabilities listed, post-login capabilities have more.IMAP: 12:30:02 [tx] ekum STARTTLS IMAP: 12:30:02 [db] OnNotify: asOld = 5, asNew = 5, ae = 3 IMAP: 12:30:02 [rx] ekum OK Begin TLS negotiation now. IMAP: 12:30:02 [db] Mit 'Microsoft Unified Security Protocol Provider' wird eine sichere Verbindung ausgehandelt. [A secure connection is negotiated with 'Microsoft Unified Security Protocol Provider'] IMAP: 12:30:02 [db] OnNotify: asOld = 5, asNew = 6, ae = 2 IMAP: 12:30:03 [db] Die Verbindung mit 'mail.xxx.de' wurde geschlossen. [Connection to 'mail.xxx.de' has been closed.] IMAP: 12:30:03 [db] OnNotify: asOld = 6, asNew = 0, ae = 5 IMAP: 12:30:03 [db] ERROR: "Es kann keine sichere Verbindung mit dem Server hergestellt werden.", hr=2148322330 [Can't establish a secure connection with the server.]
My settings for ssl_protocols and ssl_cipher_list are empty. Since it works with most clients, I assume no broken certificates or my dovecot configuration. The connection fails at the TLS/SSL handshake. Has anyone seen this behaviour, too? Is there a setting (for ssl_protocols and ssl_cipher_list) to support Outlook on Win8?
Thanks, Sebastian
Before do more analysis, trible check there are no auth problems with your setup your log does not look like this, but dont ever trust microsoft logs and its mysticals, check dove log too for auth problems, as ever shut down any antivirus imap proxies firewalls too for testing
set dove debug ssl max verbose perhaps use wireshark etc too
from http://forum.mailtraq.com/viewtopic.php?f=7&t=1913
... I have been diagnosing the problem with Windows 8 and we think it has been identified, although we are still waiting for confirmation from Microsoft. It appears that Microsoft have changed the TLS security protocol requirements in the Unified Security Protocol Provider that ships with Windows 8. ...
some other stuff
http://technet.microsoft.com/de-de/office/aa374757%28v=vs.71%29 http://technet.microsoft.com/de-de/office/bb870930%28v=vs.71%29 http://support.microsoft.com/kb/245030
perhaps i will run my own tests tommorow and report again
Best Regards MfG Robert Schetterer
Am 07.05.2014 21:59, schrieb Robert Schetterer:
perhaps i will run my own tests tommorow and report again
meanwhile
check this too
http://www.lynclog.com/2013_04_01_archive.html
... At this point, just for fun, I decided to disable TLS v1.2 on Windows OS level ...
for dove
also test settings from
https://bettercrypto.org/static/applied-crypto-hardening.pdf
ssl_cipher_list = ' EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+ aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL: !LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMEL LIA128-SHA:AES128-SHA ' note dove 2.1.7 is old, you should use latest 2.1.17/2.2.12
Best Regards MfG Robert Schetterer
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Robert
The logs I supplied were derived from "verbose_ssl = yes". I supplied the lines where it differs from regular requests and suppressed a ton of SSL output. I don't trust the Outlook logs, too, but supplied them for completeness. There are no auth issues in the dovecot log, since the TLS/SSL handshake isn't successful. (Auth works without TLS/SSL which is also an indication.) The Win8 machine was a fresh install, no firewall or antivirus, just Win8.1 from scratch + Outlook 2013.
I've seen the mailtraq forum post, too. Unfortunately the registry patch isn't available for download. I haven't seen the other (lynclog) link and will try the registry patch as soon as I have access to my win8 test machine tomorrow. Thanks for this link. I will also give the ssl_cipher_list a try, thanks. I will post my results here.
(2.1.7 is old, however since it ships with Debian Weezy I guess I'm in good company :) )
Thanks for your input Sebastian
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Disabling TLS1.2 in Win8 provides a workaround for the issue. This is done with this registry entry. [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client] "DisabledByDefault"=dword:00000001 "Enabled"=dword:00000000
Setting the ssl_cipher_list to what Robert suggested didn't change the behaviour.
I've tried disabling TLS1.2 in dovecot, however I've had no success. Is there a way to disable TLS1.2?
Sebastian
Am 08.05.2014 18:59, schrieb Sebastian Goodrick:
Disabling TLS1.2 in Win8 provides a workaround for the issue. This is done with this registry entry. [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client] "DisabledByDefault"=dword:00000001 "Enabled"=dword:00000000
thx for report, so its a workaround
Setting the ssl_cipher_list to what Robert suggested didn't change the behaviour.
hm....
I've tried disabling TLS1.2 in dovecot, however I've had no success. Is there a way to disable TLS1.2?
isolate the real nature of the problem should be the way to go
Sebastian
Best Regards MfG Robert Schetterer
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I've tried disabling TLS1.2 in dovecot, however I've had no success. Is there a way to disable TLS1.2?
isolate the real nature of the problem should be the way to go
Yes, you're right. Disabling TLS1.2 is a workaround, not a solution. Postfix is affected by the same issue which indicates an issue with OpenSSL. There is a certain chance that this behaviour might be triggered from a closed source library. If someone from Microsoft volunteers to work on this issue, I'd be happy to join in.
Regards, Sebastian
Am 08.05.2014 19:50, schrieb Sebastian Goodrick:
I've tried disabling TLS1.2 in dovecot, however I've had no success. Is there a way to disable TLS1.2?
isolate the real nature of the problem should be the way to go
Yes, you're right. Disabling TLS1.2 is a workaround, not a solution. Postfix is affected by the same issue which indicates an issue with OpenSSL. There is a certain chance that this behaviour might be triggered from a closed source library. If someone from Microsoft volunteers to work on this issue, I'd be happy to join in.
Regards, Sebastian
perhaps this has impact...just an idea
http://blogs.technet.com/b/secguide/archive/2014/04/07/why-we-re-not-recomme...
so my specutlation, on win 8 fips mode enabled ,is default currently, ( please verify this ) , but it should be disabled be causing too much trouble...
Best Regards MfG Robert Schetterer
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
perhaps this has impact...just an idea
http://blogs.technet.com/b/secguide/archive/2014/04/07/why-we-re-not-recomme...
so my specutlation, on win 8 fips mode enabled ,is default currently, ( please verify this ) , but it should be disabled be causing too much trouble...
On my fresh install of Win8.1:
HKLM\System\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy Enabled=0
Indicating that FIPS mode is disabled. As far as I understand FIPS it disables certain ciphers / protocols. However, my new dovecot/OpenSSL version provides more and stronger ciphers, so FIPS shouldn't be an issue (well, in theory).
Regards Sebastian
Am 08.05.2014 21:29, schrieb Sebastian Goodrick:
perhaps this has impact...just an idea
http://blogs.technet.com/b/secguide/archive/2014/04/07/why-we-re-not-recomme...
so my specutlation, on win 8 fips mode enabled ,is default currently, ( please verify this ) , but it should be disabled be causing too much trouble...
On my fresh install of Win8.1:
HKLM\System\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy Enabled=0
hm..
Indicating that FIPS mode is disabled. As far as I understand FIPS it disables certain ciphers / protocols. However, my new dovecot/OpenSSL version provides more and stronger ciphers, so FIPS shouldn't be an issue (well, in theory).
definiton of "strong" maybe variable my speculate was, it leaves too less ciphers left
Regards Sebastian
i will test this now with my win8 and new dove installation, but it will take time doing endless win upgrades in the vm first
Best Regards MfG Robert Schetterer
Am 08.05.2014 22:25, schrieb Robert Schetterer:
Am 08.05.2014 21:29, schrieb Sebastian Goodrick:
perhaps this has impact...just an idea
http://blogs.technet.com/b/secguide/archive/2014/04/07/why-we-re-not-recomme...
so my specutlation, on win 8 fips mode enabled ,is default currently, ( please verify this ) , but it should be disabled be causing too much trouble...
On my fresh install of Win8.1:
HKLM\System\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy Enabled=0
hm..
Indicating that FIPS mode is disabled. As far as I understand FIPS it disables certain ciphers / protocols. However, my new dovecot/OpenSSL version provides more and stronger ciphers, so FIPS shouldn't be an issue (well, in theory).
definiton of "strong" maybe variable my speculate was, it leaves too less ciphers left
Regards Sebastian
i will test this now with my win8 and new dove installation, but it will take time doing endless win upgrades in the vm first
Best Regards MfG Robert Schetterer
meanwhile from
http://social.technet.microsoft.com/Forums/office/en-US/5a8df31b-ef3a-4f42-9...
... System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing"
as found in
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
which as per description does
This policy setting determines whether the Transport Layer Security/Secure Sockets Layer (TLS/SSL) Security Provider supports only the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher suite.
that needs to be disabled for Outlook.com's SMTP TLS to work.
or, looking at the registry: FIPSAlgorithmPolicy
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SecEdit\Reg Values\MACHINE/System/CurrentControlSet/Control/Lsa/FIPSAlgorithmPolicy/Enabled ...
any thoughts about that ?
Best Regards MfG Robert Schetterer
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
my speculate was, it leaves too less ciphers left
OK, but does the old dovecot/openssl version provide less ciphers than the new install? I'm not too familiar with what ciphers ship with OpenSSL in what version. My naive assumption is, a new version ships with more ciphers, hence this shouldn't be an issue. (Unless there is a new bug in a cipher.)
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
I just learned, there is a tool called gpedit.msc on win8 :) "Use FIPS compliant algorithms for encryption, hashing, and signing" is disabled on my machine. From what I understand this indicates, that it can use more/all available ciphers.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SecEdit\Reg
Values\MACHINE/System/CurrentControlSet/Control/Lsa/FIPSAlgorithmPolicy/Enabled I can find this key (it is set to DisplayType=0 and ValueType=4) but I don't understand what I can change there and what this setting indicates. Needless to say that my windows administration knowledge is limited.
Regards, Sebastian
Am 09.05.2014 08:29, schrieb Sebastian Goodrick:
my speculate was, it leaves too less ciphers left
OK, but does the old dovecot/openssl version provide less ciphers than the new install?
sorry i am short in time
dovecot hast setup options for ciphers related to your openssl version
please read
http://www.michaelboman.org/books/sslscan
http://www.unixwitch.de/de/sysadmin/tools/imap-mit-ssl-testen
https://sys4.de/de/blog/2013/08/15/dovecot-tls-perfect-forward-secrecy/
http://wiki2.dovecot.org/SSL/DovecotConfiguration
http://www.heise.de/security/artikel/Forward-Secrecy-testen-und-einrichten-1...
I'm not too familiar with what ciphers ship with
OpenSSL in what version.
type
openssl ciphers
to see ciphers on your server with your openssl version
and
openssl s_client -connect imap.example.com:143 -starttls imap
for general testing
My naive assumption is, a new version ships
with more ciphers, hence this shouldn't be an issue. (Unless there is a new bug in a cipher.)
there must be matching ciphers
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
I just learned, there is a tool called gpedit.msc on win8 :) "Use FIPS compliant algorithms for encryption, hashing, and signing" is disabled on my machine. From what I understand this indicates, that it can use more/all available ciphers.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SecEdit\Reg
Values\MACHINE/System/CurrentControlSet/Control/Lsa/FIPSAlgorithmPolicy/Enabled I can find this key (it is set to DisplayType=0 and ValueType=4) but I don't understand what I can change there and what this setting indicates. Needless to say that my windows administration knowledge is limited.
as written i will test it, but it will take time
Regards, Sebastian
Best Regards MfG Robert Schetterer
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I will go through the links later today, thanks.
openssl ciphers
The new OpenSSL supports many additional ciphers. Three ciphers are not supported anymore: DES-CBC-MD5, DES-CBC3-MD5, RC2-CBC-MD5 For any reason I don't understand, there are ciphers listed twice in the old OpenSSL version but also once in the new version: EXP-RC2-CBC-MD5, EXP-RC4-MD5, RC4-MD5
openssl s_client -connect imap.example.com:143 -starttls imap
dovecot 2.1.7, OpenSSL 1.0.1 e (both as shipped with Debian Weezy): New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-GCM-SHA384
dovecot 1.2.13, OpenSSL 0.9.8 g (call me outdated, I say heartbleed!): New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
However, that's talking OpenSSL to OpenSSL.
there must be matching ciphers
Indeed. According to this http://msdn.microsoft.com/en-us/library/windows/desktop/aa374757(v=vs.85).as... there should be matching ciphers if I'm not completely mistaken. (I don't know what P256 indicates in TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256.
Is there a similar way to OpenSSL to check on the box, what is really supported? Or to perform a handshake like the -connect -starttls imap option of OpenSSL?
as written i will test it, but it will take time
Thanks, Robert. I really appreciate it. Your comments have been really helpful to me so far.
Regards Sebastian
Am 09.05.2014 14:28, schrieb Sebastian Goodrick:
For any reason I don't understand, there are ciphers listed twice in the old OpenSSL version but also once in the new version: EXP-RC2-CBC-MD5, EXP-RC4-MD5, RC4-MD5
EXP-RC4-MD5 != RC4-MD5
however, with a recent dovecot setup and openssl >= 1.0.1 you can and should order the ciphers on the serverside
the configuration belows disables as most important thing the broken RC4 and supports even Outlook 2003 on WinXP which uses DES-CBC3-SHA proven by dovecot logs
because it does not list any crap it is short enough that compatible ciphers are always in the first 64 ones, you may use google to find out why that is important if it comes to handshakes with older software especially from Microsoft
these 21 ciphers are ordered by best possible encryption and are passing serious security audits
ssl_prefer_server_ciphers = yes ssl_cipher_list = ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-RSA-CAMELLIA256-SHA:CAMELLIA128-SHA:CAMELLIA256-SHA:ECDHE-RSA-DES-CBC3-SHA:DES-CBC3-SHA:!SSLv2
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09.05.2014 14:40, Reindl Harald wrote:
For any reason I don't understand, there are ciphers listed twice in the old OpenSSL version but also once in the new version: EXP-RC2-CBC-MD5, EXP-RC4-MD5, RC4-MD5
EXP-RC4-MD5 != RC4-MD5
Obviously. But what is the point of listing both of them twice in OpenSSL 0.9.8g?
ssl_prefer_server_ciphers = yes
This setting is not supported in 2.1.7 (as shipped with Debian Weezy)
ssl_cipher_list = ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-RSA-CAMELLIA256-SHA:CAMELLIA128-SHA:CAMELLIA256-SHA:ECDHE-RSA-DES-CBC3-SHA:DES-CBC3-SHA:!SSLv2
I
just gave this cipher list a try, but it didn't change the behaviour for Win8/Outlook 2013.
Am 09.05.2014 21:57, schrieb Sebastian Goodrick:
On 09.05.2014 14:40, Reindl Harald wrote:
For any reason I don't understand, there are ciphers listed twice in the old OpenSSL version but also once in the new version: EXP-RC2-CBC-MD5, EXP-RC4-MD5, RC4-MD5
EXP-RC4-MD5 != RC4-MD5
Obviously. But what is the point of listing both of them twice in OpenSSL 0.9.8g?
ssl_prefer_server_ciphers = yes
This setting is not supported in 2.1.7 (as shipped with Debian Weezy)
ssl_cipher_list = ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-RSA-CAMELLIA256-SHA:CAMELLIA128-SHA:CAMELLIA256-SHA:ECDHE-RSA-DES-CBC3-SHA:DES-CBC3-SHA:!SSLv2
I
just gave this cipher list a try, but it didn't change the behaviour for Win8/Outlook 2013.
Am 09.05.2014 10:33, schrieb Robert Schetterer:
Am 09.05.2014 08:29, schrieb Sebastian Goodrick:
my speculate was, it leaves too less ciphers left
OK, but does the old dovecot/openssl version provide less ciphers than the new install?
sorry i am short in time
dovecot hast setup options for ciphers related to your openssl version
please read
http://www.michaelboman.org/books/sslscan
http://www.unixwitch.de/de/sysadmin/tools/imap-mit-ssl-testen
https://sys4.de/de/blog/2013/08/15/dovecot-tls-perfect-forward-secrecy/
http://wiki2.dovecot.org/SSL/DovecotConfiguration
http://www.heise.de/security/artikel/Forward-Secrecy-testen-und-einrichten-1...
I'm not too familiar with what ciphers ship with
OpenSSL in what version.
type
openssl ciphers
to see ciphers on your server with your openssl version
and
openssl s_client -connect imap.example.com:143 -starttls imap
for general testing
My naive assumption is, a new version ships
with more ciphers, hence this shouldn't be an issue. (Unless there is a new bug in a cipher.)
there must be matching ciphers
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
I just learned, there is a tool called gpedit.msc on win8 :) "Use FIPS compliant algorithms for encryption, hashing, and signing" is disabled on my machine. From what I understand this indicates, that it can use more/all available ciphers.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SecEdit\Reg
Values\MACHINE/System/CurrentControlSet/Control/Lsa/FIPSAlgorithmPolicy/Enabled I can find this key (it is set to DisplayType=0 and ValueType=4) but I don't understand what I can change there and what this setting indicates. Needless to say that my windows administration knowledge is limited.
as written i will test it, but it will take time
Regards, Sebastian
Best Regards MfG Robert Schetterer
Hi Sebastian, sorry for the delay ,i could not reproduce your problem, speculate you have wrong settings in your server/client setup and/or you have firewall loadbalancers, proxies between server and client which fail with some ciphers
as written i did a test setup
brand new win 8.1 pro german 32 install all updates
brand new outlook 2013 german 32 all updates
as vm in vmware player
no other special settings done beside install classicshell and firefox
server ubuntu trusty latest dovecot 2.2.13 patchlevel yesterday
test openssl server
OpenSSL 1.0.1f 6 Jan 2014
openssl s_client -starttls imap -cipher 'ECDH:DH' -connect localhost:143
... New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 ....
ssl crt from rapidssl
login method ( for testing ) plain login
2014-05-17T19:22:20.901285+02:00 mail dovecot: imap-login: Debug: SSL: elliptic curve secp384r1 will be used for ECDH and ECDHE key exchanges 2014-05-17T19:22:20.901800+02:00 mail dovecot: imap-login: Debug: SSL: elliptic curve secp384r1 will be used for ECDH and ECDHE key exchanges 2014-05-17T19:22:20.907542+02:00 mail dovecot: auth: Debug: Loading modules from directory: /usr/lib/dovecot/modules/auth 2014-05-17T19:22:20.908615+02:00 mail dovecot: auth: Debug: Module loaded: /usr/lib/dovecot/modules/auth/libdriver_mysql.so 2014-05-17T19:22:20.913605+02:00 mail dovecot: auth: Debug: Module loaded: /usr/lib/dovecot/modules/auth/libdriver_pgsql.so 2014-05-17T19:22:20.913635+02:00 mail dovecot: auth: Debug: Module loaded: /usr/lib/dovecot/modules/auth/libdriver_sqlite.so 2014-05-17T19:22:20.913770+02:00 mail dovecot: auth: Debug: Read auth token secret from /var/run/dovecot/auth-token-secret.dat 2014-05-17T19:22:20.914136+02:00 mail dovecot: auth: Debug: passwd-file /etc/dovecot/users: Read 1 users in 0 secs 2014-05-17T19:22:20.914161+02:00 mail dovecot: auth: Debug: auth client connected (pid=30359) 2014-05-17T19:22:20.997162+02:00 mail dovecot: imap-login: Debug: SSL: where=0x10, ret=1: before/accept initialization [1.2.3.4] 2014-05-17T19:22:20.997190+02:00 mail dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: before/accept initialization [1.2.3.4] 2014-05-17T19:22:20.997210+02:00 mail dovecot: imap-login: Debug: SSL: where=0x2002, ret=-1: unknown state [1.2.3.4] 2014-05-17T19:22:21.037845+02:00 mail dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read client hello A [1.2.3.4] 2014-05-17T19:22:21.037873+02:00 mail dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write server hello A [1.2.3.4] 2014-05-17T19:22:21.038062+02:00 mail dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write certificate A [1.2.3.4] 2014-05-17T19:22:21.043376+02:00 mail dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write key exchange A [1.2.3.4] 2014-05-17T19:22:21.043395+02:00 mail dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write server done A [1.2.3.4] 2014-05-17T19:22:21.043416+02:00 mail dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 flush data [1.2.3.4] 2014-05-17T19:22:21.043436+02:00 mail dovecot: imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv3 read client certificate A [1.2.3.4] 2014-05-17T19:22:21.043447+02:00 mail dovecot: imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv3 read client certificate A [1.2.3.4] 2014-05-17T19:22:21.400072+02:00 mail dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read client key exchange A [1.2.3.4] 2014-05-17T19:22:21.400274+02:00 mail dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read finished A [1.2.3.4] 2014-05-17T19:22:21.400363+02:00 mail dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write session ticket A [1.2.3.4] 2014-05-17T19:22:21.400388+02:00 mail dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write change cipher spec A [1.2.3.4] 2014-05-17T19:22:21.400451+02:00 mail dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write finished A [1.2.3.4] 2014-05-17T19:22:21.400477+02:00 mail dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 flush data [1.2.3.4] 2014-05-17T19:22:21.400497+02:00 mail dovecot: imap-login: Debug: SSL: where=0x20, ret=1: SSL negotiation finished successfully [1.2.3.4] 2014-05-17T19:22:21.400513+02:00 mail dovecot: imap-login: Debug: SSL: where=0x2002, ret=1: SSL negotiation finished successfully [1.2.3.4] 2014-05-17T19:22:21.530462+02:00 mail dovecot: auth: Debug: client in: AUTH#0111#011PLAIN#011service=imap#011secured#011session=vqTaxZv5+QBY2Ym1#011lip=88.198.69.105#011rip=1.2.3.4#011lport=143#011rport=34041#011resp=AHVzZXIxAHBhc3M= (previous base64 data may contain sensitive data) 2014-05-17T19:22:21.530657+02:00 mail dovecot: auth: Debug: passwd-file(user1,1.2.3.4,<vqTaxZv5+QBY2Ym1>): lookup: user=user1 file=/etc/dovecot/users 2014-05-17T19:22:21.530691+02:00 mail dovecot: auth: Debug: client passdb out: OK#0111#011user=user1 2014-05-17T19:22:21.532921+02:00 mail dovecot: auth: Debug: master in: REQUEST#0112559311873#01130359#0111#01105dec904a2d70034ed3208c9f0b9030e#011session_pid=30362#011request_auth_token 2014-05-17T19:22:21.532939+02:00 mail dovecot: auth: Debug: passwd-file(user1,1.2.3.4,<vqTaxZv5+QBY2Ym1>): lookup: user=user1 file=/etc/dovecot/users 2014-05-17T19:22:21.532954+02:00 mail dovecot: auth: Debug: master userdb out: USER#0112559311873#011user1#011mail=maildir:~/maildir#011uid=1001#011gid=1001#011home=/mnt/user1#011auth_token=d2209447f66ca5732086c5dac94732cd613a538d 2014-05-17T19:22:21.533157+02:00 mail dovecot: imap-login: Login: user=<user1>, method=PLAIN, rip=1.2.3.4, lip=2.3.4.5, mpid=30362, TLS, session=<vqTaxZv5+QBY2Ym1>
settings mostly default
10-ssl.conf
# DH parameters length to use. ssl_dh_parameters_length = 1024
# SSL protocols to use ssl_protocols = !SSLv2
# SSL ciphers to use ssl_cipher_list = ALL:!LOW:!SSLv2:!EXP:!aNULL
# Prefer the server's order of ciphers over client's. ssl_prefer_server_ciphers = yes
Best Regards MfG Robert Schetterer
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Sebastian, sorry for the delay ,i could not reproduce your problem, speculate you have wrong settings in your server/client setup and/or you have firewall loadbalancers, proxies between server and client which fail with some ciphers
Thank you once more, Robert. I can exclude firewalls, loadbalancers and proxies. The client is set up from scratch plus there are seven existing Win8 installations, so I should say, it's not the client.
I upgraded to dovecot 2.2.12 and openssl 1.0.1h (as shipped with Debian Jessie but installed on Wheezy). I'm using your settings for the ssl config. Openssl connect shows the same output as on your system. Still the same problem with Win8 though.
I have just bought a rapidssl cert and will report back once I have received and installed it.
Regards, Sebastian
Am 18.05.2014 20:04, schrieb Sebastian Goodrick:
Hi Sebastian, sorry for the delay ,i could not reproduce your problem, speculate you have wrong settings in your server/client setup and/or you have firewall loadbalancers, proxies between server and client which fail with some ciphers
Thank you once more, Robert. I can exclude firewalls, loadbalancers and proxies. The client is set up from scratch plus there are seven existing Win8 installations, so I should say, it's not the client.
please double check this i.e your dove server is hosted elsewhere and the hoster hast some firewall/loadbalancer you dont know, use wireshark etc to trace traffic, or just use only virtual client and server on the same virtual private network for testing
I upgraded to dovecot 2.2.12 and openssl 1.0.1h (as shipped with Debian Jessie but installed on Wheezy). I'm using your settings for the ssl config. Openssl connect shows the same output as on your system. Still the same problem with Win8 though.
as written no problem here, i dont know if debian does something else with openssl then ubuntu, but i guess not only for testing i advice using plain mech at login dove, double check your outlook settings
I have just bought a rapidssl cert and will report back once I have received and installed it.
every "official" up2date ssl crt should work, also dont forget to include intermediate crt/pem in your ssl dove chain
Regards, Sebastian
Best Regards MfG Robert Schetterer
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
every "official" up2date ssl crt should work, also dont forget to include intermediate crt/pem in your ssl dove chain
I just installed the (rapid-ssl) certificate and it works now. Needless to say that I don't understand it. The old certificate worked with all other clients but win8/outlook, plus the old dovecot install worked with win8/outlook as well.
Regards, Sebastian
Am 21.05.2014 19:47, schrieb Sebastian Goodrick:
every "official" up2date ssl crt should work, also dont forget to include intermediate crt/pem in your ssl dove chain
I just installed the (rapid-ssl) certificate and it works now. Needless to say that I don't understand it. The old certificate worked with all other clients but win8/outlook, plus the old dovecot install worked with win8/outlook as well.
Regards, Sebastian
endless speculation is now possible
there where some bugfixes with certificates ( windows ) but that should not impact brand new installs with full recent patch level
however good to hear you got it work
Best Regards MfG Robert Schetterer
On Wed, May 21, 2014 at 09:14:26PM +0200, Robert Schetterer wrote:
Am 21.05.2014 19:47, schrieb Sebastian Goodrick:
I just installed the (rapid-ssl) certificate and it works now. Needless to say that I don't understand it. The old certificate worked with all other clients but win8/outlook, plus the old dovecot install worked with win8/outlook as well.
I am struggling with the same issue for some time now: win8/outlook isn't able to connect to dovecot 2.2.9 (from Debian/backports); the error on the outlook side of things is 0x800CCC0E which is really helpful.
The suggestion to disable TLSv1.2 on the windows side is dangerous: win8/8.1 requires TLSv1.2 for downloading updates -- no TLSv1.2, no updates. If absolutely necessary, disable TLSv1.2 on the dovecot side of things!
I decided to do some additional debugging by running 'openssl s_server' on the imap server with the very same certificates and settings (as far as it is possible with s_server) on a different port, changed the port in outlook and manually proxied the imap requests through: That way outlook works just fine:
openssl s_server -tls1_2 -accept 8993 -cert /etc/dovecot/my.crt
-key /etc/dovecot/private/my.key -serverpref -cipher '...(*)'
-dhparam /root/group16.pem
(group16.pem contains 4096bit DH params that are standardized; on the dovecot side, the dhparam length is set to 4096bit as well)
The very same thing happens with two different classes of ciphers: ECDHE-RSA-AES256-SHA (which is what win8/outlook used to use before the last update) and with DHE-RSA-AES256-GCM-SHA384 (which was just recently added by the last update by Microsoft). So neither EC nor DHE cause any changes in the behavior (as I was suspecting dovecot's dh params for some time).
I think something in the handshake doesn't work the way it should and causes ms crypto api (v6.3 and v6.2) to just close the connection after handshake (a paket capture just shows the client sends a RST after key exchange).
there where some bugfixes with certificates ( windows ) but that should not impact brand new installs with full recent patch level
AFAIK new (pretty cool) ciphers were introduced and I don't see how the issue can be solved by changing the certificate: I used a cert from CACert and a Cert signed by my own CA -- both resulting in a non-working connection between dovecot and outlook on win8(.1). However using the very same certificate with OpenSSL's s_server, the connection worked just fine (as did disabling TLSv1.2) -- both indicators that the certificates are just fine.
The only thing I can imagine that EC and DHE have in common are some SSL extensions like session tickets (which outlook tried to use). Here are the details of the session outlook established with s_server: openssl sess_id -text -in param SSL-Session: Protocol : TLSv1.2 Cipher : C014 ## this is ECDHE-RSA-AES256-SHA or: Cipher : 009F ## this is with DHE-RSA-AES256-GCM-SHA384 Session-ID: Session-ID-ctx: 01000000 Master-Key: (...) Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1403774959 Timeout : 7200 (sec) Verify return code: 0 (ok)
I hope someone can help me/us out here!
Thanks!
-- Adi
(*) see https://bettercrypto.org for a usable cipher string...
On Thu, 26 Jun 2014 11:53:49 +0200, Adi Kriegisch stated:
On Wed, May 21, 2014 at 09:14:26PM +0200, Robert Schetterer wrote:
Am 21.05.2014 19:47, schrieb Sebastian Goodrick:
I just installed the (rapid-ssl) certificate and it works now. Needless to say that I don't understand it. The old certificate worked with all other clients but win8/outlook, plus the old dovecot install worked with win8/outlook as well.
I am struggling with the same issue for some time now: win8/outlook isn't able to connect to dovecot 2.2.9 (from Debian/backports); the error on the outlook side of things is 0x800CCC0E which is really helpful.
The suggestion to disable TLSv1.2 on the windows side is dangerous: win8/8.1 requires TLSv1.2 for downloading updates -- no TLSv1.2, no updates. If absolutely necessary, disable TLSv1.2 on the dovecot side of things!
I decided to do some additional debugging by running 'openssl s_server' on the imap server with the very same certificates and settings (as far as it is possible with s_server) on a different port, changed the port in outlook and manually proxied the imap requests through: That way outlook works just fine:
openssl s_server -tls1_2 -accept 8993 -cert /etc/dovecot/my.crt
-key /etc/dovecot/private/my.key -serverpref -cipher '...(*)'
-dhparam /root/group16.pem(group16.pem contains 4096bit DH params that are standardized; on the dovecot side, the dhparam length is set to 4096bit as well)
The very same thing happens with two different classes of ciphers: ECDHE-RSA-AES256-SHA (which is what win8/outlook used to use before the last update) and with DHE-RSA-AES256-GCM-SHA384 (which was just recently added by the last update by Microsoft). So neither EC nor DHE cause any changes in the behavior (as I was suspecting dovecot's dh params for some time).
I think something in the handshake doesn't work the way it should and causes ms crypto api (v6.3 and v6.2) to just close the connection after handshake (a paket capture just shows the client sends a RST after key exchange).
there where some bugfixes with certificates ( windows ) but that should not impact brand new installs with full recent patch level
AFAIK new (pretty cool) ciphers were introduced and I don't see how the issue can be solved by changing the certificate: I used a cert from CACert and a Cert signed by my own CA -- both resulting in a non-working connection between dovecot and outlook on win8(.1). However using the very same certificate with OpenSSL's s_server, the connection worked just fine (as did disabling TLSv1.2) -- both indicators that the certificates are just fine.
The only thing I can imagine that EC and DHE have in common are some SSL extensions like session tickets (which outlook tried to use). Here are the details of the session outlook established with s_server: openssl sess_id -text -in param SSL-Session: Protocol : TLSv1.2 Cipher : C014 ## this is ECDHE-RSA-AES256-SHA or: Cipher : 009F ## this is with DHE-RSA-AES256-GCM-SHA384 Session-ID: Session-ID-ctx: 01000000 Master-Key: (...) Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1403774959 Timeout : 7200 (sec) Verify return code: 0 (ok)
I hope someone can help me/us out here!
Thanks!
-- Adi
(*) see https://bettercrypto.org for a usable cipher string...
I did some checking on MS forums for this problem.
SMTP, Port: 25, Secure(SSL): No, Socket Error: 10060, Error Number: 0x800CCC0E
According to many of the posters, the problem is often causes by the AV program blocking or messing with port 25.
What version of Outlook are you using anyway?
On Thu, 26 Jun 2014 11:53:49 +0200, Adi Kriegisch stated:
I am struggling with the same issue for some time now: win8/outlook isn't able to connect to dovecot 2.2.9 (from Debian/backports); the error on the outlook side of things is 0x800CCC0E which is really helpful.
A listing of all of Window's error codes:
http://support.microsoft.com/kb/942495
Hi!
I am struggling with the same issue for some time now: win8/outlook isn't able to connect to dovecot 2.2.9 (from Debian/backports); the error on the outlook side of things is 0x800CCC0E which is really helpful.
A listing of all of Window's error codes:
Yeah: 0x800CCC0E IXP_E_FAILED_TO_CONNECT Cannot connect to server Pretty helpful error message after all... ;-)
Seriously, Outlook (tried 2007 and 2013) use the MS Crypto API for establishing the SSL connection. This works with openssl s_server but does not with dovecot.
-- Adi
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 26 Jun 2014, Adi Kriegisch wrote:
I am struggling with the same issue for some time now: win8/outlook isn't able to connect to dovecot 2.2.9 (from Debian/backports); the error on the outlook side of things is 0x800CCC0E which is really helpful.
A listing of all of Window's error codes:
Yeah: 0x800CCC0E IXP_E_FAILED_TO_CONNECT Cannot connect to server Pretty helpful error message after all... ;-)
Well, _did_ you've verified that the connection is started at all?
I mean: http://support.microsoft.com/kb/302339/EN-US
"If you are connected to the Internet through MSN, the Microsoft Network, and you attempt to send messages by using an account other than your MSN e-mail account, you may receive an error message that is similar to the following error message:
The connection to the server has failed. Account: '<account name>', Server: '<SMTP server name>', Protocol: SMTP, Port: 25, Secure (SSL): No, Socket Error: 10051, Error Number: 0x800CCC0E
Cause This behavior can occur because MSN does not allow messages to be sent to another Simple Mail Transfer Protocol (SMTP) server while you are connected to their network."
- From that description I would first check if this error means the basic
TCP connection. No SSL stuff or something.
Seriously, Outlook (tried 2007 and 2013) use the MS Crypto API for establishing the SSL connection. This works with openssl s_server but does not with dovecot.
Actually, as Jerry already wrote, some other program may interfere, e.g. an antivirus program that stalls the connection as soon as the connection changes from text to binary after the STARTTLS command. That's what we had problems with.
Did you checked the connection with wireshark / tcpdump on the server side? What side sents the last packet, does one side terminates the connection, ... ?
Steffen Kaiser
Hey!
0x800CCC0E IXP_E_FAILED_TO_CONNECT Cannot connect to server Pretty helpful error message after all... ;-)
Well, _did_ you've verified that the connection is started at all?
Yup. As written in my first mail, the client tears down the connection after the ssl key exchange with a FIN,ACK.
I mean: http://support.microsoft.com/kb/302339/EN-US
"If you are connected to the Internet through MSN, the Microsoft Network, and you attempt to send messages by using an account other
(...)
(SSL): No, Socket Error: 10051, Error Number: 0x800CCC0E
The windows machine is a vm on my machine. No antivirus, no nothing inbetween -- just win8.1 (at the latest patch level) and outlook.
Did you checked the connection with wireshark / tcpdump on the server side? What side sents the last packet, does one side terminates the connection, ... ?
Yes. And as I said already: the connection with s_server works from the very same setup.
Here is a log extract from just right now with 'verbose_ssl': Jun 26 13:56:36 mail dovecot: imap-login: Debug: SSL: elliptic curve secp384r1 will be used for ECDH and ECDHE key exchanges Jun 26 13:56:36 mail dovecot: imap-login: Debug: SSL: where=0x10, ret=1: before/accept initialization [10.10.10.20] Jun 26 13:56:36 mail dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read client hello A [10.10.10.20] Jun 26 13:56:36 mail dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write server hello A [10.10.10.20] Jun 26 13:56:36 mail dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write certificate A [10.10.10.20] Jun 26 13:56:36 mail dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write key exchange A [10.10.10.20] Jun 26 13:56:36 mail dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write server done A [10.10.10.20] Jun 26 13:56:36 mail dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 flush data [10.10.10.20] Jun 26 13:56:36 mail dovecot: imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv3 read client certificate A [10.10.10.20] Jun 26 13:56:36 mail dovecot: imap-login: Warning: SSL failed: where=0x2002: SSLv3 read client certificate A [10.10.10.20] Jun 26 13:56:36 mail dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=10.10.10.20, lip=10.10.10.10, TLS handshaking: Disconnected So, yes, I guess outlook talks to dovecot...
-- Adi
Am 26.06.2014 11:53, schrieb Adi Kriegisch:
On Wed, May 21, 2014 at 09:14:26PM +0200, Robert Schetterer wrote:
Am 21.05.2014 19:47, schrieb Sebastian Goodrick:
I just installed the (rapid-ssl) certificate and it works now. Needless to say that I don't understand it. The old certificate worked with all other clients but win8/outlook, plus the old dovecot install worked with win8/outlook as well.
I am struggling with the same issue for some time now: win8/outlook isn't able to connect to dovecot 2.2.9 (from Debian/backports); the error on the outlook side of things is 0x800CCC0E which is really helpful.
read again orig thread, i ve tested brand new win 8.1 outlook 2013 install all latest patchlevel with dovecot 2.2.13 tls, no problem, the orig problem had gone using another crt from rapid-ssl by unknown reason, needless to say that there may tons of other reasons why it fails at your site, however im nearly sure tha tthere is no default bug in dovecot
The suggestion to disable TLSv1.2 on the windows side is dangerous: win8/8.1 requires TLSv1.2 for downloading updates -- no TLSv1.2, no updates. If absolutely necessary, disable TLSv1.2 on the dovecot side of things!
I decided to do some additional debugging by running 'openssl s_server' on the imap server with the very same certificates and settings (as far as it is possible with s_server) on a different port, changed the port in outlook and manually proxied the imap requests through: That way outlook works just fine:
openssl s_server -tls1_2 -accept 8993 -cert /etc/dovecot/my.crt
-key /etc/dovecot/private/my.key -serverpref -cipher '...(*)'
-dhparam /root/group16.pem(group16.pem contains 4096bit DH params that are standardized; on the dovecot side, the dhparam length is set to 4096bit as well)
The very same thing happens with two different classes of ciphers: ECDHE-RSA-AES256-SHA (which is what win8/outlook used to use before the last update) and with DHE-RSA-AES256-GCM-SHA384 (which was just recently added by the last update by Microsoft). So neither EC nor DHE cause any changes in the behavior (as I was suspecting dovecot's dh params for some time).
I think something in the handshake doesn't work the way it should and causes ms crypto api (v6.3 and v6.2) to just close the connection after handshake (a paket capture just shows the client sends a RST after key exchange).
there where some bugfixes with certificates ( windows ) but that should not impact brand new installs with full recent patch level
AFAIK new (pretty cool) ciphers were introduced and I don't see how the issue can be solved by changing the certificate: I used a cert from CACert and a Cert signed by my own CA -- both resulting in a non-working connection between dovecot and outlook on win8(.1). However using the very same certificate with OpenSSL's s_server, the connection worked just fine (as did disabling TLSv1.2) -- both indicators that the certificates are just fine.
The only thing I can imagine that EC and DHE have in common are some SSL extensions like session tickets (which outlook tried to use). Here are the details of the session outlook established with s_server: openssl sess_id -text -in param SSL-Session: Protocol : TLSv1.2 Cipher : C014 ## this is ECDHE-RSA-AES256-SHA or: Cipher : 009F ## this is with DHE-RSA-AES256-GCM-SHA384 Session-ID: Session-ID-ctx: 01000000 Master-Key: (...) Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1403774959 Timeout : 7200 (sec) Verify return code: 0 (ok)
I hope someone can help me/us out here!
Thanks!
-- Adi
(*) see https://bettercrypto.org for a usable cipher string...
Best Regards MfG Robert Schetterer
On Thu, Jun 26, 2014 at 05:13:20PM +0200, Robert Schetterer wrote:
Am 26.06.2014 11:53, schrieb Adi Kriegisch:
On Wed, May 21, 2014 at 09:14:26PM +0200, Robert Schetterer wrote:
Am 21.05.2014 19:47, schrieb Sebastian Goodrick:
I just installed the (rapid-ssl) certificate and it works now. Needless to say that I don't understand it. The old certificate worked with all other clients but win8/outlook, plus the old dovecot install worked with win8/outlook as well.
I am struggling with the same issue for some time now: win8/outlook isn't able to connect to dovecot 2.2.9 (from Debian/backports); the error on the outlook side of things is 0x800CCC0E which is really helpful.
read again orig thread, i ve tested brand new win 8.1 outlook 2013 install all latest patchlevel with dovecot 2.2.13 tls, no problem, the orig problem had gone using another crt from rapid-ssl by unknown reason, needless to say that there may tons of other reasons why it fails at your site, however im nearly sure tha tthere is no default bug in dovecot
Right. The "bug" is in Windows: SHA512 isn't configured as a valid hash for a certificate (SHA256 and SHA384 are) and Windows is unable to provide a reasonable error message. (**) To solve this, adding "RSA/SHA512" to the following registry entry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010003\Functions solves the issue. (This affects CACert as well as their default signature algorithm is SHA512 by now) Do not forget to reboot after adding this registry entry.
-- Adi
(**) In Windows 8, certificate validation seems to behave quite different for TLSv1.2 than for older protocol incarnations. So there might be other pitfalls as well (like for example self signed certificates including the CA flag set to true will not be considered valid)... PS: This hinted me in the right direction: http://www.michaelm.info/blog/?p=1273
participants (6)
-
Adi Kriegisch
-
Jerry
-
Reindl Harald
-
Robert Schetterer
-
Sebastian Goodrick
-
Steffen Kaiser