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
Received on 2016-12-16