AquaMail Forum
English - Android => Bug reports => Topic started by: 5huhulalu on September 16, 2018, 01:18:46 am
-
Dear Kosta,
I can not connect to my IMAP mailserver. My mailserver is dovecot. I had no problems in the past, but after the recent update of dovecot, I can no longer connect. I suspect that Aquamail tries to downgrade the TLS cipher and Dovecot no longer accepts this strategy.
I have no problems with other email clients (Mozilla Thunderbird)
I tried to change Dovecot settings (disable the ssl_cipher_list etc.) but the problem still remains.
Logs from Dovecot and from Aquamail are in the attachments.
-
SSL code is in Android not in our app.
The error has to be on your side.
This is the cipher list that we "ask" Android to use (the beginning of the list).
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_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_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
Hope this helps.
-
PS - if your phone runs 7.0 it cold be this:
https://github.com/k9mail/k-9/issues/3280
https://issuetracker.google.com/issues/37122132
-
Dear Kostya,
thanks a lot for your answer!
-
Dear Kostya,
sorry to bother you again. I did few tests:
I installed K-9 mail. I had no problems connecting to Dovecot using cipher ECDHE-ECDSA-AES256-GCM-SHA384. This is third cipher on your list...
I did some tcpdump using Wireshark iin order to compare your Hello and Hello from K-9.
This is Hello from K-9 (decoded by Wireshark, in the "tree structture"):
Secure Sockets Layer
TLSv1.2 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 148
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 144
Version: TLS 1.2 (0x0303)
Random: e05e8398a8ad4d0741de24217fb54a673a5fd0abee1e23dd...
Session ID Length: 0
Cipher Suites Length: 34
Cipher Suites (17 suites)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
Compression Methods Length: 1
Compression Methods (1 method)
Compression Method: null (0)
Extensions Length: 69
Extension: server_name (len=17)
Extension: extended_master_secret (len=0)
Extension: signature_algorithms (len=22)
Type: signature_algorithms (13)
Length: 22
Signature Hash Algorithms Length: 20
Signature Hash Algorithms (10 algorithms)
Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603)
Signature Algorithm: rsa_pkcs1_sha384 (0x0501)
Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503)
Signature Algorithm: rsa_pkcs1_sha256 (0x0401)
Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)
Signature Algorithm: SHA224 RSA (0x0301)
Signature Algorithm: SHA224 ECDSA (0x0303)
Signature Algorithm: rsa_pkcs1_sha1 (0x0201)
Signature Algorithm: ecdsa_sha1 (0x0203)
After Hello from K-9 (Client Hello), Dovecot continues with the communication (Server Hello, followed by certificate, key exchange etc.) and everything is OK.
And this is your Hello:
Secure Sockets Layer
TLSv1 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 176
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 172
Version: TLS 1.2 (0x0303)
Random: 2b7af5ba92040f081a5a3621e9d9cbab2d50b829b7fe755f...
Session ID Length: 0
Cipher Suites Length: 62
Cipher Suites (31 suites)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
Cipher Suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (0xc007)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
Cipher Suite: TLS_FALLBACK_SCSV (0x5600)
Compression Methods Length: 1
Compression Methods (1 method)
Extensions Length: 69
Extension: server_name (len=17)
Extension: extended_master_secret (len=0)
Extension: signature_algorithms (len=22)
Type: signature_algorithms (13)
Length: 22
Signature Hash Algorithms Length: 20
Signature Hash Algorithms (10 algorithms)
Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603)
Signature Algorithm: rsa_pkcs1_sha384 (0x0501)
Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503)
Signature Algorithm: rsa_pkcs1_sha256 (0x0401)
Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)
Signature Algorithm: SHA224 RSA (0x0301)
Signature Algorithm: SHA224 ECDSA (0x0303)
Signature Algorithm: rsa_pkcs1_sha1 (0x0201)
Signature Algorithm: ecdsa_sha1 (0x0203)
After Client Hello from Aquamail, communication is interrupted by the server and there is no response from the server.
As you can see, Client Hello from K-9 and Aquamail are very simmilar. The cipher list is very similar.
The only difference is this: K-9 sends its Client Hello over "TLSv1.2 Record Layer" but Aquamail sends the Client Hello over "TLSv1 Record Layer". This is also indicated in the "protocol" column in Wireshark. Client Hello by K-9 is sent over TLSv1.2 protocol (also the server sends all its communication over TLSv1.2) but the column "protocol" for Client Hello from Aquamail says TLSv1 protocol.
Thanks a lot.
P.S. I forgot to mention that I have Android 6.0.1 so the bug in 7.0 probably does not affect me.
-
Re: The only difference is this: K-9 sends its Client Hello over "TLSv1.2 Record Layer" but Aquamail sends the Client Hello over "TLSv1 Record Layer". This is also indicated in the "protocol" column in Wireshark.
I can't doubt your findings from WireShark etc, but - *we* don't send "client hello", Android's networking code does.
We just use a Java class called SSLSocket and we set options for protocols and ciphers.
Regarding TLS 1.2 vs. 1.0, this is Aqua connecting to Gmail (just an example):
protocol TLSv1.2, cipher TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
( this is actual protocol from *after* the connection is established )
This is Fastmail:
protocol TLSv1.2, cipher TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
This is Yandex:
protocol TLSv1.2, cipher TLS_RSA_WITH_AES_128_GCM_SHA256
This is Office 365 (EWS over https):
protocol TLSv1.2, cipher TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
-
Description: Debian GNU/Linux 9.5 (stretch)
Release: 9.5
ii dovecot-imapd 1:2.2.27-3+deb9u2 amd64 secure POP3/IMAP server - IMAP daemon
---
Test 1
10-ssl.conf
# SSL protocols to use
ssl_protocols = !SSLv3
# SSL ciphers to use
ssl_cipher_list = kRSA+AES:!LOW:!SSLv2:!EXP:!aNULL
# DH
ssl_dh_parameters_length = 2048
Aqua Mail connecting:
protocol TLSv1.2, cipher TLS_RSA_WITH_AES_128_GCM_SHA256
---
Test 2
# SSL protocols to use
ssl_protocols = !SSLv3
# SSL ciphers to use
ssl_cipher_list = ECDHE-ECDSA-AES256-GCM-SHA384
# DH
ssl_dh_parameters_length = 2048
Handshake errors, yes reproduced.
----
However:
https://security.stackexchange.com/questions/29314
Appendix E.1. (Compatibility with TLS 1.0/1.1 and SSL 3.0) from the TLS 1.2 RFC says:
Earlier versions of the TLS specification were not fully clear on
what the record layer version number (TLSPlaintext.version) should
contain when sending ClientHello (i.e., before it is known which
version of the protocol will be employed). Thus, TLS servers
compliant with this specification MUST accept any value {03,XX} as
the record layer version number for ClientHello.
Note the "MUST".
The ClientHello from the client is sent wrapped into one or several records, and each record contains the protocol version as well. The records are like the envelopes around letters. It is safe to use version 0x0300 (SSLv3) for these records, regardless of the maximum supported version indicated in the ClientHello; that's like sending a letter in an SSLv3 envelope, but the letter says "by the way, I also support TLS 1.0 and TLS 1.1". Using SSLv3 records maximizes interoperability with old and buggy implementations who know only of SSLv3 and would reject records with a higher version.
I assume the "envelope" here is exactly the "TLSv1.2 Record Layer" in your wire dump.
-
Follow up.
The "envelope"'s TLS version comes from Android code.
I just checked K9's SSL code it's here:
https://github.com/k9mail/k-9/blob/master/mail/common/src/main/java/com/fsck/k9/mail/ssl/DefaultTrustedSocketFactory.java
Ours is just like that, it's boilerplate:
SSLContext sslContext = SSLContext.getInstance("TLS");
sslContext.init(null, null, null);
return sslContext.getSocketFactory();
I don't see anything in K9 code that would force "envelope" to TLS 1.2.
Do you?
And then - is that even the right thing to do?
- It would prevent connecting to TLS 1.0 - 1.1 servers (a purist view is - those should not be used anymore by anyone, but this wouldn't work that well "in the real world").
- And then what I posted above - about how the envelope TLS version can be lower and the other side (server) MUST accept it even when clientHello is TLS 1.2 - indicates that there is a bug somewhere and I don't think it's us.
-
BTW when using
# SSL protocols to use
ssl_protocols = !SSLv3
# SSL ciphers to use
ssl_cipher_list = ECDHE-ECDSA-AES256-GCM-SHA384
or
# SSL protocols to use
ssl_protocols = TLSv1.2
# SSL ciphers to use
ssl_cipher_list = ECDHE-ECDSA-AES256-GCM-SHA384
this fails to detect any SSL protocols or ciphers:
$ nmap --script ssl-cert,ssl-enum-ciphers -p 993 aqua-mail.com
Starting Nmap 7.60 ( https://nmap.org ) at 2018-09-23 16:19 MSK
Nmap scan report for aqua-mail.com (176.58.105.125)
Host is up (0.047s latency).
PORT STATE SERVICE
993/tcp open imaps
Nmap done: 1 IP address (1 host up) scanned in 30.22 seconds
and this fails too:
$ openssl s_client -tls1_2 -crlf -connect aqua-mail.com:993
CONNECTED(00000003)
139871317656000:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:../ssl/record/rec_layer_s3.c:1399:SSL alert number 40
and even this fails:
$ openssl s_client -tls1_2 -cipher ECDHE-ECDSA-AES256-GCM-SHA384 -crlf -connect aqua-mail.com:993
CONNECTED(00000003)
140257266016704:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:../ssl/record/rec_layer_s3.c:1399:SSL alert number 40
Quite curious.
-
Speaking of K9 Mail.
Installed from Play.
Server config:
# SSL protocols to use
ssl_protocols = TLSv1.2
# SSL ciphers to use
ssl_cipher_list = ECDHE-ECDSA-AES256-GCM-SHA384
K9 gives account setup error, also SSL handshake:
09-23 17:02:04.581 E/AccountSetupCheckSettin( 5788): Error while testing settings
09-23 17:02:04.581 E/AccountSetupCheckSettin( 5788): com.fsck.k9.mail.MessagingException: Unable to connect
09-23 17:02:04.581 E/AccountSetupCheckSettin( 5788): at com.fsck.k9.mail.store.imap.ImapStore.checkSettings(ImapStore.java:317)
09-23 17:02:04.581 E/AccountSetupCheckSettin( 5788): at com.fsck.k9.activity.setup.AccountSetupCheckSettings$CheckAccountTask.checkIncoming(AccountSetupCheckSettings.java:497)
09-23 17:02:04.581 E/AccountSetupCheckSettin( 5788): at com.fsck.k9.activity.setup.AccountSetupCheckSettings$CheckAccountTask.checkServerSettings(AccountSetupCheckSettings.java:467)
09-23 17:02:04.581 E/AccountSetupCheckSettin( 5788): at com.fsck.k9.activity.setup.AccountSetupCheckSettings$CheckAccountTask.doInBackground(AccountSetupCheckSettings.java:424)
09-23 17:02:04.581 E/AccountSetupCheckSettin( 5788): at com.fsck.k9.activity.setup.AccountSetupCheckSettings$CheckAccountTask.doInBackground(AccountSetupCheckSettings.java:402)
09-23 17:02:04.581 E/AccountSetupCheckSettin( 5788): at android.os.AsyncTask$2.call(AsyncTask.java:333)
09-23 17:02:04.581 E/AccountSetupCheckSettin( 5788): at java.util.concurrent.FutureTask.run(FutureTask.java:266)
09-23 17:02:04.581 E/AccountSetupCheckSettin( 5788): at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:245)
09-23 17:02:04.581 E/AccountSetupCheckSettin( 5788): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
09-23 17:02:04.581 E/AccountSetupCheckSettin( 5788): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
09-23 17:02:04.581 E/AccountSetupCheckSettin( 5788): at java.lang.Thread.run(Thread.java:764)
09-23 17:02:04.581 E/AccountSetupCheckSettin( 5788): Caused by: javax.net.ssl.SSLHandshakeException: Handshake failed
09-23 17:02:04.581 E/AccountSetupCheckSettin( 5788): at com.fsck.k9.mail.store.imap.ImapConnection.open(ImapConnection.java:135)
09-23 17:02:04.581 E/AccountSetupCheckSettin( 5788): at com.fsck.k9.mail.store.imap.ImapStore.checkSettings(ImapStore.java:313)
09-23 17:02:04.581 E/AccountSetupCheckSettin( 5788): ... 10 more
09-23 17:02:04.581 E/AccountSetupCheckSettin( 5788): Caused by: javax.net.ssl.SSLProtocolException: SSL handshake aborted: ssl=0x7016099c00: Failure in SSL library, usually a protocol error
09-23 17:02:04.581 E/AccountSetupCheckSettin( 5788): error:10000410:SSL routines:OPENSSL_internal:SSLV3_ALERT_HANDSHAKE_FAILURE (external/boringssl/src/ssl/tls_record.c:522 0x701601a680:0x00000001)
09-23 17:02:04.581 E/AccountSetupCheckSettin( 5788): error:1000009a:SSL routines:OPENSSL_internal:HANDSHAKE_FAILURE_ON_CLIENT_HELLO (external/boringssl/src/ssl/handshake_client.c:889 0x7014732126:0x00000000)
09-23 17:02:04.581 E/AccountSetupCheckSettin( 5788): at com.android.org.conscrypt.NativeCrypto.SSL_do_handshake(Native Method)
09-23 17:02:04.581 E/AccountSetupCheckSettin( 5788): ... 15 more
-
Hi,
I am just advanced user, I have no programming skills. So it is difficult for me to find the source of the bug...
But it really seems that there is something wrong with Dovecot itself.
Good to know that you have reproduced the error.
Thanks a lot!
I wil send some bug report to Dovecot when I have more time.
-
Well what are your ssl_protocols and ssl_cipher_list (and any other ssl related settings) in Dovecot config?
And Dovecot and OpenSSL version on the server?
Based on my tests above, I'm guessing you've set ssl_protocols to TLSv1.2.
Setting it to "!SSLv3" or maybe "TLSv1, TLSv1.1, TLSv1.2" should make things work - and TLS 1.2 capable apps (such as Aqua) will still prefer TLS 1.2.
BTW - on Android 7.0 we also enable / prefer CHACHA20_POLY1305 which is secure and fast on mobile devices.
-
This works for me - in Aqua Mail and also using "openssl" and "nmap" to test:
# SSL protocols to use
ssl_protocols = !SSLv3
# SSL ciphers to use
ssl_cipher_list = AESGCM
nmap --script ssl-cert,ssl-enum-ciphers
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp384r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp384r1) - A
| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
| compressors:
| NULL
| cipher preference: client
|_ least strength: A
Note that your "favorite" cipher ECDHE-ECDSA-AES256-GCM-SHA384 is not enabled.
It is listed if use identical cipher spec with "openssl ciphers", it's in first place:
openssl ciphers AESGCM | tr ':' '\n'
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
DHE-DSS-AES256-GCM-SHA384
DHE-RSA-AES256-GCM-SHA384
ADH-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
DHE-DSS-AES128-GCM-SHA256
DHE-RSA-AES128-GCM-SHA256
ADH-AES128-GCM-SHA256
RSA-PSK-AES256-GCM-SHA384
DHE-PSK-AES256-GCM-SHA384
AES256-GCM-SHA384
PSK-AES256-GCM-SHA384
RSA-PSK-AES128-GCM-SHA256
DHE-PSK-AES128-GCM-SHA256
AES128-GCM-SHA256
PSK-AES128-GCM-SHA256
I *think* this has to do with server's certificate key being RSA.
Dovecot 2.3.31 has a mechanism where you can have multiple certificates (and keys) and they're picked based on ciphers (if I'm reading the docs correctly).
https://wiki.dovecot.org/SSL/DovecotConfiguration
---
Also note that only TLS 1.2 is enabled - because ciphers matching "AESGCM" are all specific to TLS 1.2.
-
Hi,
I have Dovecot 2.3.2.1
Openssl 1.1.1
ssl_cipher_list = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
This is ecommended cipher list from https://wiki.mozilla.org/Security/Server_Side_TLS. I also tried
ssl_cipher_list = ECDHE-ECDSA-AES256-GCM-SHA384
because I wanted K-9 and Aquamail to use the same cipher so that I can compare their behaviour.
Other settings:
ssl_min_protocol = TLSv1.2
ssl_prefer_server_ciphers = yes
My server's certificate key is ECDSA (ECC).
ssl_protocols has been replaced by ssl_min_protocol in Dovecot 2.3
I have tried
ssl_min_protocol = TLSv1
ssl_cipher_list = AESGCM
and
ssl_protocols = !SSLv3
ssl_cipher_list = AESGCM
(with warnings that ssl_protocols is obsolete)
nmap --script ssl-cert,ssl-enum-ciphers
Host is up (0.020s latency).
PORT STATE SERVICE
143/tcp filtered imap
Nmap done: 1 IP address (1 host up) scanned in 2.26 seconds
:(
Your workaround does not work for me. Which Dovecot version do you use?
EDIT
I have noticed that you have Dovecot 2.2.27. Could you please upgrade to 2.3? I have used Dovecot + Aquamail without any problems for years. But my problems started after upgrading Dovecot. I "think" that earlier versions of Dovecot (2.2) somehow avoided the problematic ciphers (ECDHE-ECDSA-AES256-GCM-SHA384 ??). But Dovecot 2.3.1 does not work at all.
-
My system info is this:
Description: Debian GNU/Linux 9.5 (stretch)
Release: 9.5
ii dovecot-imapd 1:2.2.27-3+deb9u2 amd64 secure POP3/IMAP server - IMAP daemon
I think maybe it's this?
My server's certificate key is ECDSA (ECC).
What did you do for "certificate key is ECDSA" ??? Any explicit setting?
When I run openssl s_client -crlf -connect aqua-mail.com:993 I see this among other output:
Peer signing digest: SHA512
Server Temp Key: ECDH, P-384, 384 bits
---
I think for your server, nmap should still be able to find "some" TLS protocols / ciphers, but it's not finding any.
Does this work at all? Do you actually get encryption?
openssl s_client -crlf -connect servername:993
---
Finally, sorry, I am not able to upgrade to Dovecot 2.3 because the server runs Debian 9.5 "stretch" and the latest Dovecot there (in "backports") is 2.2.34:
https://packages.debian.org/stretch-backports/dovecot-imapd
-
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
##
## 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 =
-
And now I made these edits to get rid of Dovecot's "obsolete setting name" warnings:
# 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.
-
PS:
openssl 1.1.0f-3+deb9u2
-
Dear Kostya,
I have reported my issue to Dovecot mailing list. This is the answer I got:
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
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):
| 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.
-
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 )
-
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.
-
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!
-
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.
-
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":
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.
-
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?
-
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.
-
OpenSSL 1.1.1 supports TLS 1.3. But Dovecot does not recognize TLSv1.3:
Could not find a minimum ssl_min_protocol setting from ssl_protocols = !SSLv3, !TLSv1.3: Unrecognized protocol 'TLSv1.3'
-
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.
-
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?
-
PS - what a horrible mess!
-
ssl_protocols = TLSv1.2
"SSL hardening" ON
gives me this:
Warning: Obsolete setting in /etc/dovecot/conf.d/10-ssl.conf:61: ssl_protocols has been replaced by ssl_min_protocol
and "inapproproate fallback"
It seems that Dovecot completely ignores the obsolete setting. It makes sense - they introduced "ssl_min_protocol" because they want to force the best protocol available.
But I am not sure whether Dovecot / OpenSSL really use TLS 1.3. The TLS 1.3 protocol would show up in nmap,, I believe... And my nmap only shows TLSv1.2.
But to make things more messy.....
During development of the TLSv1.3 standard it became apparent that in some cases, even if a client and server both support TLSv1.3, connections could sometimes still fail. This is because middleboxes on the network between the two peers do not understand the new protocol and prevent the connection from taking place. In order to work around this problem the TLSv1.3 specification introduced a “middlebox compatibility” mode. This made a few optional changes to the protocol to make it appear more like TLSv1.2 so that middleboxes would let it through.
https://wiki.openssl.org/index.php/TLS1.3#Middlebox_Compatibility_Mode
So TLS 1.3 could be in play even though nmap reports 1.2??
-
Re: And my nmap only shows TLSv1.2
That's assuming nmap supports TLS 1.3 :) which may not be the case.
I'm thinking that even though Dovecot doesn't know anything about TLS 1.3 - when it asks OpenSSL for "TLS 1.2 and higher", it gets 1.2 and 1.3.
And "ssl_protocols" doesn't help - in this newer Dovecot version - because it gets "mapped" to the new setting, ssl_min_protocol with 1.2 so it asks OpenSSL for "1.2 and newer" and not "just 1.2".
---
Re: middlebox compatibility
That doesn't make things any more clear :)
---
In about 1-2 hours I'll post a new build here that removes "tls fallback" from "enabled ciphers".
And then you could try if it fixes things for you - even with "SSL hardening" enabled.
-
That's assuming nmap supports TLS 1.3 :) which may not be the case.
I'm thinking that even though Dovecot doesn't know anything about TLS 1.3 - when it asks OpenSSL for "TLS 1.2 and higher", it gets 1.2 and 1.3.
Well, maybe we should wait few more days/weeks for nmap and dovecot to recognize TLS 1.3. Because at the moment we are left in the dark.
OK, I will wait for the new build.
-
@5huhulalu
This one should work with both "SSL hardening" on and off, can you please check?
https://www.aqua-mail.com/staging/AquaMail-market-1.17.0-1301-dev-c3adc96dd2a2.apk
-
Hi,
yes, this build works with both "SSL hardening" on and off.
Here is Client Hello from Wireshark dump. TLS_FALLBACK_SCSV is no longer in the cipher list:
Secure Sockets Layer
TLSv1.2 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 164
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 160
Version: TLS 1.2 (0x0303)
Random:
GMT Unix Time:
Random Bytes:
Session ID Length: 0
Cipher Suites Length: 50
Cipher Suites (25 suites)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
Compression Methods Length: 1
Compression Methods (1 method)
Compression Method: null (0)
Extensions Length: 69
Extension: server_name (len=17)
Extension: extended_master_secret (len=0)
Extension: signature_algorithms (len=22)
Type: signature_algorithms (13)
Length: 22
Signature Hash Algorithms Length: 20
Signature Hash Algorithms (10 algorithms)
Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603)
Signature Algorithm: rsa_pkcs1_sha384 (0x0501)
Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503)
Signature Algorithm: rsa_pkcs1_sha256 (0x0401)
Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)
Signature Algorithm: SHA224 RSA (0x0301)
Signature Algorithm: SHA224 ECDSA (0x0303)
Signature Algorithm: rsa_pkcs1_sha1 (0x0201)
Signature Algorithm: ecdsa_sha1 (0x0203)
I have the newest version of Wireshark which supports TLS 1.3. Communication between Aquamail and Dovecot is done through TLSv1.2 protocol.
EDIT: The Wireshark dump is for "SSL hardening" on
-
Re: yes, this build works with both "SSL hardening" on and off.
Great, thanks for checking!
-
Oh and this also fixed:
TLSv1 Record Layer: Handshake Protocol: Client Hello
seen in your earlier WireShark dump:
https://www.aqua-mail.com/forum/index.php?topic=6824.msg41188#msg41188
Now the "envelope" is 1.2
TLSv1.2 Record Layer: Handshake Protocol: Client Hello
-
Yes, the issue with the envelope is also solved. Good job.
BTW, I am thinking about client certificate authentication for additional security. Do you plan to implement the feature? At the moment client certificates are only supported for Exchange servers.
-
Re: client certificate authentication
Sorry we don't have any plans for it for "internet mail" -
Technology wise it would be pretty easy, but it's a very rare case (much more common with Exchange, also where it's not controlled by users, but rather by their employers).... and it would complicate the UI for adding internet mail accounts.
If you're concerned about your password being sent over the network - maybe consider using SASL CRAM-MD5. Pretty easy to set up with Dovecot.
Yeah it's "bad bad bad insecure and broken" MD5 but personally I think it's still good enough considering that the network connection is also encrypted.
For IMAP, Aqua Mail will use it if it's the only login method declared by the server (i.e. given CRAM-MD5 and PLAIN, Aqua will use PLAIN - too many broken servers out there).
-
If you're concerned about your password being sent over the network
It is not just about passwords being sent over the network. It is also about passwords being stored in so many places (not just Aquamail but other email clients like Thunderbird), passwords being stolen by keyloggers, passwords being "guessed" from my other passwords that may have leaked etc etc.
Yes, client cert for IMAP is a rare case. At the moment I saw only one request for this feature in Aquamail ( https://www.aqua-mail.com/forum/index.php?topic=6055.0 ). But it would be welcomed by more advanced users.
UI for adding client certificate would be similar to what you already have for Exchange...
-
It is not just about passwords being sent over the network. It is also about passwords being stored in so many places (not just Aquamail but other email clients like Thunderbird), passwords being stolen by keyloggers, passwords being "guessed" from my other passwords that may have leaked etc etc.
Yes it's true (about storage and entry).
But then with keys you have to deal with other things - like revocation (on the server), "hmm, which email app did I use this key in?" - and Android will require "secured" lock screen.
Yes the UI could be the same - but then it can get messy quickly, like separate certs for IMAP / SMTP - aliases (identities).
We only did it for Exchange because it's a "not unheard of" requirement for Exchange specifically.
So for Internet Mail - I'm still unsure if it's worth it *overall* (although you're completely right about the benefits).
---
Idle chatter:
I discovered WireShark for Linux last night, runs on command line (I've only used it on Windows before).
Decided to look at our "new and shiny" handshakes and almost had a heart attack.
Our code enables (or keeps enabled) the TLS_EMPTY_RENEGOTIATION_INFO_SCSV "pseudo-cipher" and I know it's important.
On a 5.0 device, I could see it in 1) logcat and 2) WireShark output.
On a 8.0 device, it was only visible in logcat but *not* in WireShark output.
Like I said, almost had a heart attack.
Well turns out 8.0 (maybe some earlier versions too) sends it like this:
Extension: renegotiation_info
Type: renegotiation_info (0xff01)
Length: 1
Renegotiation Info extension
Renegotiation info extension length: 0
and not as a "pseudo-cipher"!
See, I'm paranoid now!