0

I am trying to connect Outlook 2019 to a Cyrus imapd server, using an SSL connection on port 993, and using ECDHE for key agreement. Whatever I do, this does not work although the imap server is set up correctly.

To debug the problem, I issued ssldump -a -A -H -i enp0s3 on the server and watched its output when Outlook tries to connect (I have left away the most part of the cipher suite list in the first C -> S handshake for brevity):

New TCP connection #1: odo.lab.example.de(58717) <-> morn.lab.example.de(993) 1 1 0.0019 (0.0019) C>S V3.3(178) Handshake ClientHello Version 3.3 random[32]= 65 b1 2e 3c bb 7c 4d 04 03 0e 34 49 62 48 e5 d9 22 c6 c9 c7 22 d4 e5 a0 76 44 64 9b a3 9d d5 bf cipher suites TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ... compression methods NULL extensions server_name host_name: imap.lab.example.de supported_groups ec_point_formats signature_algorithms session_ticket extended_master_secret renegotiation_info 1 2 0.1245 (0.1225) S>C V3.3(69) Handshake ServerHello Version 3.3 random[32]= 3c ef 0c 80 c8 c2 35 85 90 20 8e 6f f4 e0 93 fe 78 60 32 23 11 ec 56 df 3f f3 c6 e2 14 2f e5 2b session_id[0]= cipherSuite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 compressionMethod NULL extensions renegotiation_info server_name ec_point_formats session_ticket extended_master_secret 1 3 0.1245 (0.0000) S>C V3.3(1291) Handshake Certificate 1 4 0.1245 (0.0000) S>C V3.3(333) Handshake ServerKeyExchange params Not enough data. Found 327 bytes (expecting 32767) 1 5 0.1245 (0.0000) S>C V3.3(4) Handshake ServerHelloDone 1 0.1254 (0.0009) C>S TCP FIN 1 0.1257 (0.0002) S>C TCP FIN

As we can see, the client and the server agree on the desired cipher (TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384). Next, the server seems to send its certificate to the client (it is a self-signed certificate, but this is not the problem because I have added that certificate to the trusted root CAs in Windows).

But next, there seems to be a problem with the key exchange: Not enough data. Found 327 bytes (expecting 32767) For the life of me and despite having put nearly a day into it, I can't figure out what it means and how to solve it.

Originally, I thought that it might have to do with DH parameters that are missing in the certificate file. However, (EC)DHE doesn't need such parameters because it's just the purpose of the ephemeral version to compute them dynamically and replace them regularly.

Do I need to add additional info to the key or the certificate that the IMAP server uses? It wouldn't be a problem if I had to create new ones.

I have assigned the openssl tag to this question because Cyrus imapd uses OpenSSL for SSL / TLS encryption. The OpenSSL version on the server is 1.1.1w.

I also have made sure that Outlook (the Windows side) uses TLS 1.2. This is reflected in the console output shown above (Version 3.3 means TLS 1.2).

Improve this question
4
  • 2
    This error message seems to be pretty common when using ssldump (just google) and does not seem to indicate an actual problem with the TLS connection. Maybe you are also using an old version - see github.com/adulau/ssldump/issues/36 for a similar problem. Better do a packet capture and use wireshark to debug it before jumping to the wrong conclusions. Commented Jan 24, 2024 at 16:21
  • 1
    FYI: although version 3.3 (0x0303) was created for TLS1.2 and for quite a few years did definitively mean that, TLS1.3 kept the record level version at 3.3 and only made changes inside the records, so nowadays record version 3.3 can actually be either 1.2 or 1.3. Your dump however is 1.2: 1.3 has at least several hello extensions not in your dump, and does not have ServerKeyExchange which your dump has. And 327 is a reasonable length for ServerKX for ECDHE_RSA, whereas 32767 is absurd. I concur with Steffen: use wireshark, it decodes correctly. ... Commented Jan 25, 2024 at 0:47
  • 1
    ... Also, the keys (or keypairs) in DHE-now-called-FFDHE or ECDHE are ephemeral, but the parameters are not. For [FF]DHE the parameters must be supplied by the application where they are either hardcoded or configured (or both); for ECDHE the parameters, almost always called a 'curve' although technically that's not quite correct, are standardized and hardcoded in the TLS middleware such as OpenSSL or Schannel. Which reminds me, if you haven't already, look in the Windows event log on the client=Outlook machine for any relevant entries. Commented Jan 25, 2024 at 0:52
  • Thanks a lot to dave and Steffen for the explanations and clarifications regarding the version numbering and the DHE parameters, and +1. You are also right in that there actually is no problem with the key agreement; please see my own answer. I'll surely use Wireshark in the future and avoid ssldump. Commented Jan 25, 2024 at 11:20

1 Answer 1

Reset to default
0

The comments by @Steffen Ullrich and dave_thompson_085 are both right.

The message Not enough data. Found 327 bytes (expecting 32767) comes from ssldump, not from the server or client. Too sad that exactly the program we use to analyze SSL connection incorporates such bugs, putting us on the wrong track.

The problem was hard to analyze for several reasons.

First, schannel logging is normally not active in Windows, and even after I had it turned on, I couldn't see any entries regarding schannel in Event Viewer. But a few hours later, a lot of those messages suddenly showed up (I swear I didn't change anything in the meantime).

Second, there were a zillion of messages from all sorts of software components that called home (Windows components and other applications and services). No sooner than I had scrolled through about 1000 schannel entries, I noticed one entry with a TLS alert 43, event ID 36888. That alert means unsupported_certificate (see here on page 30).

Third, this wording made me think that I would need a special key usage field (eventually an extension) in the server certificate, and made me waste a lot of time on this.

But finally it turned out that Outlook (or schannel) simply didn't like that the server certificate had expired. That was no problem with Thunderbird, though. It is beyond my horizon why Windows can't tell what the problem actually is and instead emits useless and misleading error messages.

Summary:

There was no problem with the key agreement. Instead, ssldump in the version I used contains a bug that mislead me. The problem was that the server certificate had expired, and that Outlook and Windows didn't emit sensible error messages.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.