Author Topic: TLS handshake failure  (Read 23259 times)

Kostya Vasilyev

  • Hero Member
  • *****
  • Posts: 12740
Re: TLS handshake failure
« Reply #15 on: September 28, 2018, 11:14:51 pm »
OK I found a server where I could update to

2:2.3.2.1-1~stretch

from

https://repo.dovecot.org/

---

This is Debian 9.5 "Stretch" again. I first installed the "bundled" Dovecot 2.2 and got it to work with Aqua Mail.

Then added 2.3-latest repository and updated to 2.3.2.

Restarted dovecot service.

Did not make any edits to 10-ssl or any other files.

Got these warnings in the log and ignored them.

Sep 28 23:09:15 kman.mobi dovecot[10191]: master: Dovecot v2.3.2.1 (0719df592) starting up for imap (core dumps disabled)
Sep 28 23:09:15 kman.mobi dovecot[10193]: config: Warning: NOTE: You can get a new clean config file with: doveconf -n > dovecot-new.conf
Sep 28 23:09:15 kman.mobi dovecot[10193]: config: Warning: Obsolete setting in /etc/dovecot/conf.d/10-ssl.conf:51: ssl_protocols has been replaced by ssl_min_protocol
Sep 28 23:09:15 kman.mobi dovecot[10193]: config: Warning: Obsolete setting in /etc/dovecot/conf.d/10-ssl.conf:57: ssl_dh_parameters_length is no longer needed
Sep 28 23:09:37 kman.mobi dovecot[10193]: config: Warning: please set ssl_dh=</etc/dovecot/dh.pem
Sep 28 23:09:37 kman.mobi dovecot[10193]: config: Warning: You can generate it with: dd if=/var/lib/dovecot/ssl-parameters.dat bs=1 skip=88 | openssl dhparam -inform der > /etc/dovecot/dh.pem


Aqua Mail? Works fine.

protocol TLSv1.2, cipher TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

Now:

My server certificate's key is RSA.

And:

This is my entire 10-ssl.conf

Quote
##
## SSL settings
##

# SSL/TLS support: yes, no, required. <doc/wiki/SSL.txt>
ssl = yes

# PEM encoded X.509 SSL/TLS certificate and private key. They're opened before
# dropping root privileges, so keep the key file unreadable by anyone but
# root. Included doc/mkcert.sh can be used to easily generate self-signed
# certificate, just make sure to update the domains in dovecot-openssl.cnf
#ssl_cert = </etc/dovecot/dovecot.pem
#ssl_key = </etc/dovecot/private/dovecot.pem
ssl_cert = </etc/.....crt
ssl_key = </etc/.....key

# If key file is password protected, give the password here. Alternatively
# give it when starting dovecot with -p parameter. Since this file is often
# world-readable, you may want to place this setting instead to a different
# root owned 0600 file by using ssl_key_password = <path.
#ssl_key_password =

# PEM encoded trusted certificate authority. Set this only if you intend to use
# ssl_verify_client_cert=yes. The file should contain the CA certificate(s)
# followed by the matching CRL(s). (e.g. ssl_ca = </etc/ssl/certs/ca.pem)
#ssl_ca =

# Require that CRL check succeeds for client certificates.
#ssl_require_crl = yes

# Directory and/or file for trusted SSL CA certificates. These are used only
# when Dovecot needs to act as an SSL client (e.g. imapc backend). The
# directory is usually /etc/ssl/certs in Debian-based systems and the file is
# /etc/pki/tls/cert.pem in RedHat-based systems.
#ssl_client_ca_dir =
#ssl_client_ca_file =

# Request client to send a certificate. If you also want to require it, set
# auth_ssl_require_client_cert=yes in auth section.
#ssl_verify_client_cert = no

# Which field from certificate to use for username. commonName and
# x500UniqueIdentifier are the usual choices. You'll also need to set
# auth_ssl_username_from_cert=yes.
#ssl_cert_username_field = commonName

# DH parameters length to use.
#ssl_dh_parameters_length = 1024

# SSL protocols to use
ssl_protocols = !SSLv3

# SSL ciphers to use
ssl_cipher_list = CHACHA20:AESGCM:!aNULL

# DH
ssl_dh_parameters_length = 2048

# Prefer the server's order of ciphers over client's.
#ssl_prefer_server_ciphers = no

# SSL crypto device to use, for valid values run "openssl engine"
#ssl_crypto_device =

# SSL extra options. Currently supported options are:
#   no_compression - Disable compression.
#ssl_options =

Creating debug logs for diagnostics: https://www.aqua-mail.com/troubleshooting/

The official FAQ: https://www.aqua-mail.com/faq/

Лог-файлы для диагностики: https://www.aqua-mail.com/ru/troubleshooting/

Вопросы и ответы: https://www.aqua-mail.com/ru/faq/

Kostya Vasilyev

  • Hero Member
  • *****
  • Posts: 12740
Re: TLS handshake failure
« Reply #16 on: September 28, 2018, 11:18:52 pm »
And now I made these edits to get rid of Dovecot's "obsolete setting name" warnings:

Quote
# DH parameters length to use.
#ssl_dh_parameters_length = 1024

# SSL protocols to use
#ssl_protocols = !SSLv3
ssl_min_protocol = TLSv1.2

# SSL ciphers to use
ssl_cipher_list = CHACHA20:AESGCM:!aNULL

# DH
ssl_dh = </etc/dovecot/dh.pem

Aqua Mail?

Still works:

protocol TLSv1.2, cipher TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

---

PS - Samsung S8 with 8.0, don't think it matters.
« Last Edit: September 29, 2018, 12:09:08 am by Kostya Vasilyev, Aqua Mail »
Creating debug logs for diagnostics: https://www.aqua-mail.com/troubleshooting/

The official FAQ: https://www.aqua-mail.com/faq/

Лог-файлы для диагностики: https://www.aqua-mail.com/ru/troubleshooting/

Вопросы и ответы: https://www.aqua-mail.com/ru/faq/

Kostya Vasilyev

  • Hero Member
  • *****
  • Posts: 12740
Re: TLS handshake failure
« Reply #17 on: September 28, 2018, 11:37:51 pm »
PS:

openssl                           1.1.0f-3+deb9u2
« Last Edit: September 29, 2018, 12:07:31 am by Kostya Vasilyev, Aqua Mail »
Creating debug logs for diagnostics: https://www.aqua-mail.com/troubleshooting/

The official FAQ: https://www.aqua-mail.com/faq/

Лог-файлы для диагностики: https://www.aqua-mail.com/ru/troubleshooting/

Вопросы и ответы: https://www.aqua-mail.com/ru/faq/

5huhulalu

  • Newbie
  • *
  • Posts: 16
Re: TLS handshake failure
« Reply #18 on: October 07, 2018, 10:51:53 pm »
Dear Kostya,

I have reported my issue to Dovecot mailing list. This is the answer I got:

Quote
It seems that the client has TLS_FALLBACK_SCSV cipher suite specified, which is causing the error.

See https://mta.openssl.org/pipermail/openssl-users/2017-June/005913.html [nofollow]

I only know that TLS_FALLBACK_SCSV cipher suite is meant to prevent POODLE attack. But I do not fully understand how it works and whether TLS_FALLBACK_SCSV should (or should not) be in your Cient Hello.

P.S.
nmap works for me (I do not know why it did not work earlier):


Quote
| ssl-cert: Subject: commonName=
| Subject Alternative Name: 
| Issuer: commonName=COMODO ECC Domain Validation Secure Server CA/organizationName=COMODO CA Limited/stateOrProvinceName=Greater Manchester/countryName=GB
| Public Key type: ec
| Public Key bits: 256
| Signature Algorithm: ecdsa-with-SHA256
| Not valid before: 
| Not valid after:   
| MD5:   
|_SHA-1: 
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (ecdh_x25519) - A
|     compressors:
|       NULL
|     cipher preference: server
|_  least strength: A

P.S.S. I have tried new certificate from Let's Encrypt (instead of my Comodo certificate) and nothing changed.

Kostya Vasilyev

  • Hero Member
  • *****
  • Posts: 12740
Re: TLS handshake failure
« Reply #19 on: October 07, 2018, 11:16:53 pm »
Quote
I only know that TLS_FALLBACK_SCSV cipher suite is meant to prevent POODLE attack. But I do not fully understand how it works and whether TLS_FALLBACK_SCSV should (or should not) be in your Cient Hello.

Hmmm... I only know enough about crypto to be dangerous :)

Let's see.

Android 9.0 - emulator

A SSLSocket's "supported" cipher list includes TLS_FALLBACK_SCSV

But it's not in the "enabled" cipher list - i.e. it is not enabled by default

This matches the documentation:

https://developer.android.com/reference/javax/net/ssl/SSLSocket

There is a "similar sounding" TLS_EMPTY_RENEGOTIATION_INFO_SCSV ...

... which *is* enabled by default (i.e. before Aqua Mail tweaks what ciphers we want enabled on a particular socket).

*** When Aqua Mail's "SSL hardening" is OFF we end up enabling these ciphers:

[TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV, SSL_RSA_WITH_3DES_EDE_CBC_SHA]

which is the list of ciphers "enabled by default" (by Android SSL code) + the older RSA / 3DES for compatibility (which Android doesn't enable by default).

*** When Aqua Mail's "SSL hardening" is ON we end up with these:

[TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA, TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA, TLS_PSK_WITH_AES_128_CBC_SHA, TLS_PSK_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV, TLS_FALLBACK_SCSV]

As you can see, TLS_FALLBACK_SCSV is now included.

I'd have to track down where that comes from.

Meanwhile - can you try with Aqua Mail's Settings -> Network -> SSL Hardening TURNED OFF?

( I'm not shouting, I'm *emphasizing* so this doesn't get lost among all the text here )
« Last Edit: October 07, 2018, 11:29:44 pm by Kostya Vasilyev, Aqua Mail »
Creating debug logs for diagnostics: https://www.aqua-mail.com/troubleshooting/

The official FAQ: https://www.aqua-mail.com/faq/

Лог-файлы для диагностики: https://www.aqua-mail.com/ru/troubleshooting/

Вопросы и ответы: https://www.aqua-mail.com/ru/faq/

Kostya Vasilyev

  • Hero Member
  • *****
  • Posts: 12740
Re: TLS handshake failure
« Reply #20 on: October 07, 2018, 11:28:39 pm »
Oh I know where it comes from when "SSL hardening" is ON:

- Our code gets the list of *supported* ciphers (not enabled ciphers)

- Reorders this list to put "good" ciphers first

- Then all other supported ciphers - except the "blacklisted" (known to be insecure) ciphers

That's how we end up with TLS_FALLBACK_SCSV in client hello - but ONLY IF "SSL hardening" is on.

I checked K9 Mail's source code - which also reorders ciphers to improve security and I don't see any "special case" to exclude TLS_FALLBACK_SCSV

---

So I'd try these things:

1 - Try turning off Aqua Mail settings -> network -> SSL hardening to see if it makes a difference. It won't include TLS_FALLBACK_SCSV then.

2 - Try packet dump on K9 Hello - to see if that includes TLS_FALLBACK_SCSV.

---

Oh I see now that your Comodo certificate is ECC - that's why you have elliptic server key.

But Let's Encrypt is RSA - at least for me on my test server.

So if ECC is the problem - then it's strange that Let's Encrypt didn't help.

On Let's Encrypt - you are welcome to try my test server:

kman.mobi

Feel free to use https (to view the cert in a browser)

or feel free to try IMAP to port 993 / SMTP to port 465 - you don't have an account, so just use test / test as user name / password, it will fail to log in but before that you'll see if it was able to connect.

You may backlisted by fail2ban after a few attempts - but those few should be enough to see if you're able to connect or not.
Creating debug logs for diagnostics: https://www.aqua-mail.com/troubleshooting/

The official FAQ: https://www.aqua-mail.com/faq/

Лог-файлы для диагностики: https://www.aqua-mail.com/ru/troubleshooting/

Вопросы и ответы: https://www.aqua-mail.com/ru/faq/

5huhulalu

  • Newbie
  • *
  • Posts: 16
Re: TLS handshake failure
« Reply #21 on: October 08, 2018, 10:44:27 am »
Quote
Meanwhile - can you try with Aqua Mail's Settings -> Network -> SSL Hardening TURNED OFF?

Ohhh shit! It works. That was really simple. Sorry for wasting your time with such simple thing. I forgot that there is a setting like this.

So it really seems that TLS_FALLBACK_SCSV in Client Hello in combination with TLSv1 Record Layer of that Client Hello triggers "inappropriate fallback" on the server side.

I will use SSL Hardening OFF. There will be no security downgrade for me as long as I stick to strong ciphers on the server side.

Thank you very much for your help!

Kostya Vasilyev

  • Hero Member
  • *****
  • Posts: 12740
Re: TLS handshake failure
« Reply #22 on: October 08, 2018, 12:35:51 pm »
Re: Ohhh shit! It works. That was really simple. Sorry for wasting your time with such simple thing. I forgot that there is a setting like this.

Oh not at all - this has been very useful.

From my reading of that mailing list message - TLS_FALLBACK_SCSV should not be enabled / sent, because:

it's not an actual cipher, rather its presence is used as a simple boolean (yes/no) flag - client telling the server that it already tried connecting and is trying again, with lower TLS version in client hello.

But - I still don't see anything in K9 Mail source code

https://github.com/k9mail/k-9/blob/master/mail/common/src/main/java/com/fsck/k9/mail/ssl/DefaultTrustedSocketFactory.java

that would:

- Remove TLS_FALLBACK_SCSV from the list of ciphers it enables

- Somehow force TLS 1.2 in client hello

If you still have K9 installed - could you please

2 - Try packet dump on K9 Hello - to see if that includes TLS_FALLBACK_SCSV.

???

Meanwhile I'll file a task to investigate / learn more about this.
Creating debug logs for diagnostics: https://www.aqua-mail.com/troubleshooting/

The official FAQ: https://www.aqua-mail.com/faq/

Лог-файлы для диагностики: https://www.aqua-mail.com/ru/troubleshooting/

Вопросы и ответы: https://www.aqua-mail.com/ru/faq/

Kostya Vasilyev

  • Hero Member
  • *****
  • Posts: 12740
Re: TLS handshake failure
« Reply #23 on: October 08, 2018, 12:42:22 pm »
Quote
But - I still don't see anything in K9 Mail source code

https://github.com/k9mail/k-9/blob/master/mail/common/src/main/java/com/fsck/k9/mail/ssl/DefaultTrustedSocketFactory.java

that would:

- Remove TLS_FALLBACK_SCSV from the list of ciphers it enables

- Somehow force TLS 1.2 in client hello

Hmm... Think I see it now.

hasWeakSslImplementation() returns TRUE is Android version is BELOW 5.0

And returns FALSE on Android 5.0 and newer.

When it's FALSE - the code only removes blacklisted ciphers and does not "reorder":

Quote
            ENABLED_CIPHERS = (enabledCiphers == null) ? null :
                    remove(enabledCiphers, BLACKLISTED_CIPHERS);

And this in turn will NOT mark TLS_FALLBACK_SCSV as enabled by default.

Hmmm.... But TLS_FALLBACK_SCSV  is supported since Android 3.0 - which probably means that K9 will have handshake failures on Android 4.0 - 4.4 (not 5.0 or newer) where it enable the fallback cipher.

-----

Still it would be very useful if you could

2 - Try packet dump on K9 Hello - to see if that includes TLS_FALLBACK_SCSV.
« Last Edit: October 08, 2018, 12:46:08 pm by Kostya Vasilyev, Aqua Mail »
Creating debug logs for diagnostics: https://www.aqua-mail.com/troubleshooting/

The official FAQ: https://www.aqua-mail.com/faq/

Лог-файлы для диагностики: https://www.aqua-mail.com/ru/troubleshooting/

Вопросы и ответы: https://www.aqua-mail.com/ru/faq/

Kostya Vasilyev

  • Hero Member
  • *****
  • Posts: 12740
Re: TLS handshake failure
« Reply #24 on: October 08, 2018, 01:08:28 pm »
One more thing to try please.

You're running OpenSSL 1.1.1 - which has TLS 1.3 right?

I think it means we're running into this:

https://github.com/nabla-c0d3/sslyze/issues/154#issuecomment-226265529

  If TLS_FALLBACK_SCSV appears in ClientHello.cipher_suites and the
  highest protocol version supported by the server is higher than
  the version indicated in ClientHello.client_version, the server
  MUST respond with a fatal inappropriate_fallback alert


Because "the highest protocol version supported by server" is - with OpenSSL 1.1.1 - TLS 1.3

And

ssl_min_protocol = TLSv1.2

Leaves TLS 1.3 enabled?

Can you perhaps try changing

ssl_min_protocol = TLSv1.2

to

ssl_protocols = !SSLv3, !TLSv1.3

or

ssl_protocols = TLSv1.2

if "ssl_protocols" is still supported (although deprecated) by Dovecot?
Creating debug logs for diagnostics: https://www.aqua-mail.com/troubleshooting/

The official FAQ: https://www.aqua-mail.com/faq/

Лог-файлы для диагностики: https://www.aqua-mail.com/ru/troubleshooting/

Вопросы и ответы: https://www.aqua-mail.com/ru/faq/

5huhulalu

  • Newbie
  • *
  • Posts: 16
Re: TLS handshake failure
« Reply #25 on: October 08, 2018, 01:11:46 pm »
Hi,
Dump of K9 Hello is already in my earlier post
https://www.aqua-mail.com/forum/index.php?topic=6824.msg41188#msg41188

No, Client Hello from K9 does not include TLS_FALLBACK_SCSV.

5huhulalu

  • Newbie
  • *
  • Posts: 16
Re: TLS handshake failure
« Reply #26 on: October 08, 2018, 01:18:17 pm »
OpenSSL 1.1.1 supports TLS 1.3. But Dovecot does not recognize TLSv1.3:

Quote
Could not find a minimum ssl_min_protocol setting from ssl_protocols = !SSLv3, !TLSv1.3: Unrecognized protocol 'TLSv1.3'

Kostya Vasilyev

  • Hero Member
  • *****
  • Posts: 12740
Re: TLS handshake failure
« Reply #27 on: October 08, 2018, 01:18:58 pm »
Re: No, Client Hello from K9 does not include TLS_FALLBACK_SCSV.

OK thanks (and I can see from their code why this is so - when running on Android 5.0 and newer).

Can you please try turning off TLS 1.3 on the server (if it's possible) - and then try Aqua Mail with SSL hardening ON?

---

I've got OpenSSL 1.1.0f and no easy way to upgrade to 1.1.1.
Creating debug logs for diagnostics: https://www.aqua-mail.com/troubleshooting/

The official FAQ: https://www.aqua-mail.com/faq/

Лог-файлы для диагностики: https://www.aqua-mail.com/ru/troubleshooting/

Вопросы и ответы: https://www.aqua-mail.com/ru/faq/

Kostya Vasilyev

  • Hero Member
  • *****
  • Posts: 12740
Re: TLS handshake failure
« Reply #28 on: October 08, 2018, 01:20:10 pm »
Re: But Dovecot does not recognize TLSv1.3

Hmmm, and if you try

ssl_protocols = TLSv1.2

then I suppose Dovecot will "translate" that into

ssl_min_protocol = TLSv1.2

which again will have TLS v1.3 enabled - and mandatory "abort handshake" if "fallback" is set !!!!!

Can you try it anyway please?

ssl_protocols = TLSv1.2

+ Aqua Mail's "SSL hardening" ON again?
Creating debug logs for diagnostics: https://www.aqua-mail.com/troubleshooting/

The official FAQ: https://www.aqua-mail.com/faq/

Лог-файлы для диагностики: https://www.aqua-mail.com/ru/troubleshooting/

Вопросы и ответы: https://www.aqua-mail.com/ru/faq/

Kostya Vasilyev

  • Hero Member
  • *****
  • Posts: 12740
Re: TLS handshake failure
« Reply #29 on: October 08, 2018, 01:22:16 pm »
PS - what a horrible mess!
Creating debug logs for diagnostics: https://www.aqua-mail.com/troubleshooting/

The official FAQ: https://www.aqua-mail.com/faq/

Лог-файлы для диагностики: https://www.aqua-mail.com/ru/troubleshooting/

Вопросы и ответы: https://www.aqua-mail.com/ru/faq/