Outlook 2010 woes

[Bryan Holloway]

So after several days of more troubleshooting, I have some things to 
report to the list.

First and foremost, I have discovered that the issue has nothing to do 
with SSL/TLS, which was my earlier suspicion because after doing some 
PCAPs I discovered that the transactions were negotiating TLS 1.2 on the 
new server, as opposed to 1.0 on the old.

Also thank you for the rawlog suggestion: that helped a lot in 
determining what was happening on the IMAP level.

That all said, this is what I've discovered:

There is a very curious and reproducible four-second delay during the 
negotiation between server and client which is not present in Dovecot 
2.1. This is what our customer is complaining about using Outlook 2010.

During a plaintext TCP stream, I'm seeing this:

1. Client connects (SYN) to server.

2. Server ACKs and throws back CAPABILITIES.

3. User attempts to auth with DIGEST-MD5.

4. Server says, "no thanks." (Not sure why, but I don't believe this is 
relevant.)

5. User attempts to auth with plaintext.

6. Server says, "Yup. You are you. You're logged in."

7. Client sends the following: ID ("name" "Microsoft Outlook" "version" 
"14.0")

8. Server sends an ACK

... and then there's this very curious four-second delay.

9. Server then sends out new CAPABILITIES, and everything proceeds 
thereafter as normal and zippy and fast.

Does this shed any light on the subject?


On 10/13/16 11:21 AM, Bryan Holloway wrote:
> On 10/13/16 11:01 AM, Aki Tuomi wrote:
>>
>>> On October 13, 2016 at 6:52 PM Konstantin Khomoutov
>>> <flatworm at users.sourceforge.net> wrote:
>>>
>>>
>>> On Thu, 13 Oct 2016 10:35:14 -0500
>>> Bryan Holloway <bryan at shout.net> wrote:
>>>
>>>>> [...]
>>>>>> Is there a way to see the IMAP commands coming from the client?
>>>>>> I've tried looking at PCAPs, but of course they're encrypted so I
>>>>>> can't see the actual dialog going on between the server and
>>>>>> client. I didn't see an obvious way to do this in the docs.
>>>>>
>>>>> If you have access to the SSL/TLS key (IOW, the private part of the
>>>>> cert) the server uses to secure IMAP connections you can dump the
>>>>> IMAP traffic using the `ssldump` utility (which builds on
>>>>> `tcpdump`).
>>>>
>>>> I do, but the client is using a DH key exchange so I only have the
>>>> server-side private key.
>>>>
>>>> Tried that using Wireshark's decoder features and ran into this
>>>> problem. I'm assuming I'd run into the same using ssldump, but I'll
>>>> give it a shot!
>>>
>>> I think DH is not the culprit: just to be able to actually decode SSL
>>> traffic, you must have the server private key when you're decoding the
>>> SSL handshake phase -- to be able to recover the session keys, which
>>> you then use to decode the actual tunneled data.
>>
>> You can also enable only non DH algorithms in ssl settings if rawlog
>> isn't working for you.
>>
>> Aki
>>
>
> Ah -- interesting tip. I hadn't thought of that. Thank you! I'll report
> my findings to the list.