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
<flatw...@users.sourceforge.net> wrote:
On Thu, 13 Oct 2016 10:35:14 -0500
Bryan Holloway <br...@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.
