On 12/16/2016 5:46 AM, Mariusz Gogulski wrote:
We are using cURL to handle SMTP sessions in our mail client. We are
using SSPI version of encryption (Schannel). Some of our users are
rarely experiencing problems during handshake. It happens every few
days once or twice a day (so it looks very random) but it occured only
for 3 smtp servers so far (out of 200 smtp servers that are currently
being used by our users). Below is log from such session with schannel
information. As you can see at some point InitializeSecurityContext
fails with error SEC_E_MESSAGE_ALTERED. It looks like offset in last
packet is not proper in step 2/3 comparing it with correct handshake:
Correct handshake:
schannel: encrypted data buffer: *offset 242* length 4218.
schannel: SSL/TLS handshake complete.
Incorrect handshake:
schannel: encrypted data buffer: *offset 7* length 4218.
schannel: next InitializeSecurityContext failed: SEC_E_MESSAGE_ALTERED
What could be the reason of this problem? Is it rather server side or
client side kind of problem? Is there anything we can do to fix it on
client side?
There were some bugs in how curl uses schannel that were fixed in 7.43.0
but it seems you are using at least that version, based on your output.
What is the version of curl / libcurl are you using? curl -V /
curl_version().
schannel performance and capability varies between different versions of
Windows. For example Windows XP Schannel doesn't support some now-common
encryption algorithms so it can't connect to some servers that only
accept those algorithms. If you are running on multiple versions of
Windows is there any version it does not happen on?
That it's random though has me concerned. Schannel doc is plenty vague
on this error code but from what I could gather it has to do with
message integrity. Also I found in a google search an MS employee said
this [1] about it:
"The usual reason that SEC_E_MESSAGE_ALTERED is returned is when the
passed in packet fails its MAC check after being decrypted. This happens
when the packet has been modified since it was encrypted. This can also
happen when the application is attempting to decrypt a packet using the
wrong context handle, or if packets are decrypted out of order."
So this could be a bug in curl or it could be your server is severing
the connection or corruption. If you have the ability to Wireshark the
connection and capture the packets maybe that can give you some idea by
comparing to the logs. And in the 'correct handshake' do you see
'schannel: a client certificate has been requested.' ?
[1]:
http://microsoft.public.platformsdk.security.narkive.com/4JAvlMvD/help-please-schannel-security-contexts-and-decryptmessage
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
