TLS handshake failure

[5huhulalu]

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 [nofollow]

So TLS 1.3 could be in play even though nmap reports 1.2??

[Kostya Vasilyev]

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.

[5huhulalu]

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.

[Kostya Vasilyev]

@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

[5huhulalu]

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

[Kostya Vasilyev]

Re: yes, this build works with both "SSL hardening" on and off.

Great, thanks for checking!

[Kostya Vasilyev]

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

[5huhulalu]

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.

[Kostya Vasilyev]

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).

[5huhulalu]

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...

[Kostya Vasilyev]

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!