#275 TLS-DSK incoming MIC verification fails

[Mikhail T.]

I'm trying to configure Pidgin on my FreeBSD VM to talk to the corporate Lync/Office365. Using pidgin/libpurple-2.10.11 and pidgin-sipe 1.18.4.

I've overcome a number of initial hurdles, but remain stuck now... As the attached log-snippet shows, I am able to login -- the fact, that my full name and department are quoted in the log, confirms that (pidgin/sipe itself would never have guessed these data).

But then there is a message with a particular rspauth-signature which sipe is unable to verify... I have only a very vague idea, what that means.

If the problem is due to an error on my part, the message should be clearer. If it manifests a failure to negotiate an optional feature with the service, then full disconnect is, probably, not warranted.

(The full log is 4 times bigger and contains a lot of noise about my other accounts which I'd rather not have to sanitize...)

[Stefan Becker]

Your analysis is incorrect: your login fails.

The TLS-DSK handshake goes through successfully, but the resulting server key seems to be invalid, because it can't verify the first signed message sent by the server. The client key seems to be OK, because the server accepts our first signed REGISTER request.

As this is cryptography I can't really do anyhting, because from the log you can't determine what is correct or incorrect, unless you see everything from both sides.

Things I can suggest:

• can you login with Pidgin/SIPE successfully with the same account on another platform?
• try to run sipe-tls-tester on your platform against a SSL server (see source code). Does it work?

[Mikhail T.]

Thank you, Stefan, for the prompt response.

can you login with Pidgin/SIPE successfully with the same account on another platform?

My first attempts where from FreeBSD-9.3/i386 in the office. I just got home and tried this on FreeBSD-10.1/amd64 -- same result.

try to run sipe-tls-tester on your platform against a SSL server (see source code).

Uh, I wish the test-utility were built together with the plugin...

I built it by hand and it seems to work -- I ran it as:

% ./sipe-tls-tester fast.example.com

(using the server's name from the earlier logs). See attachment...

[Stefan Becker]

My first attempts where from FreeBSD-9.3/i386 in the office. I just got home and tried this on FreeBSD-10.1/amd64 -- same result.

Don't you have anything else, preferably something you didn't compile yourself? I will only accept this as SIPE bug once you have proven, with full logs, that "account X works with Y on Z, but not with SIPE on A".

• Try Lync on Windows
• Try SIPE on Linux, Mac or Windows
• Try another account that is known to work

I looked at the log again. At the very beginning it shows the successful REGISTER to the edge server using TLS-DSK, which results in a 301 redirect to your home server. So only the REGISTER to your home server fails. I start to doubt that SIPE is at fault.

Uh, I wish the test-utility were built together with the plugin...

Huh?

:::sh
 $ find -name "sipe*tls*t*"
 ./src/core/sipe_tls_tester-sipe-tls-tester.o
 ./src/core/.deps/sipe_tls_tester-sipe-tls-tester.Po
 ./src/core/sipe_tls_tester

[Stefan Becker]

You could try to hack src/core/sip-transport.c a bit to see if everything else works fine with your account. The modified code should look like this:

:::c
if (rspauth != NULL) {
  if (sip_sec_verify_signature(transport->registrar.gssapi_context, signature_input_str, rspauth)) {
    SIPE_DEBUG_INFO_NOFORMAT("sip_transport_input: signature of incoming message validated");
    process_input_message(sipe_private, msg);
    /* transport is invalid after redirect */
  } else {
    SIPE_DEBUG_INFO_NOFORMAT("sip_transport_input: signature of incoming message is invalid.");
    // sipe_backend_connection_error(SIPE_CORE_PUBLIC,
    //                               SIPE_CONNECTION_ERROR_NETWORK,
    //                               _("Invalid message signature received"));
    // transport->processing_input = FALSE;
    process_input_message(sipe_private, msg);
    /* transport is invalid after redirect */
  }
} else if ((msg->response == 401) ||

Then you could check the debug log if all incoming messages fail verification or only some of them.

It might also help to add some debugging output to src/core/sip-sec-tls-dsk.c:sip_sec_verify_signature__tls_dsk(), i.e. print out the calculated MAC in this piece of code:

:::c
if (mac.value) {
  // ... add debug output for mac.value here ...
  result = memcmp(signature.value, mac.value, mac.length) == 0;
  g_free(mac.value);
}

I doubt that the results will be similar at all, but you never know...

[Mikhail T.]

Ok, I followed your suggestions and changed the code as shown in the attached patch.

The signature-verifier reported:
Signature mismatch: told to expect `21581288FD3C5225BC42ABD7261DA8301AAC6744' (20 bytes), calculated `100B47BF9F71D775A3C26EB2C09D095C707F60FE' (20 bytes)

The expected string above matches the earlier-output one:
sipe: sip_sec_verify_signature: message is:<tls-dsk><4A8CB82E><8><sip communications="" service=""><bn11a02fes14.infra.lync.com><37D7g71D3a2A68i1319mEB5Bt97CBbB03Cx6F4Ex><1><service>mikhail_teterin@timeinc.com<242358621>sip:mteterin1271@timeinc.com<f808e001678446f7bc093b5e72d5d6a7><><><><200> signature to verify is:21581288fd3c5225bc42abd7261da8301aac6744</f808e001678446f7bc093b5e72d5d6a7></service></bn11a02fes14.infra.lync.com></sip></tls-dsk>

Trying to proceed with process_input_message() despite the signature-failure results in segmentation fault.

[Stefan Becker]

Trying to proceed with process_input_message() despite the signature-failure results in segmentation fault.

You changed the code incorrectly. Your patch shows that process_input_message() is now called twice in the case that message verification succeeds.

[Mikhail T.]

Argh, how embarrassing! You are absolutely right. Here is the updated patch.

Now the log says:
(17:22:13) sipe: sip_sec_verify_signature: message is:<tls-dsk><2250F512><8><sip communications="" service=""><bn11a02fes05.in ra.lync.com=""><d4b6g3d9faecdei0801m400ft533dba61ax454bx><1><service>mikhail_teterin@example.com<5054918172>sip:mteterin1271@example.com<f808e001678446f7bc093b5e72d5d6a7><><><><200> signature to verify is:7cb32c3dfdb3d7b15df17c0fd7f229c2301 4420
(17:22:13) sipe: Signature mismatch: told to expect 7CB32C3DFDB3D7B15DF17C0FD7F229C230194420' (20 bytes), calculatedF 7ACD08E5EA7AA23A54D3FC352A3B72B5F56EEA' (20 bytes)
(17:22:13) sipe: sip_transport_input: signature of incoming message is invalid, but processing the message anyway
(17:22:13) sipe: process_input_message: msg->response(200),msg->method(SERVICE)
(17:22:13) sipe: process_input_message: we have a transaction callback
(17:22:13) sipe: sipe_ocs2007_process_roaming_self
(17:22:13) sipe: sipe_ocs2007_process_roaming_self: category_names length=4
(17:22:13) sipe: sipe_ocs2007_process_roaming_self: dropping category: device
(17:22:13) sipe: sipe_ocs2007_process_roaming_self: dropping category: legacyInterop
(17:22:13) sipe: sipe_ocs2007_process_roaming_self: dropping category: services
(17:22:13) sipe: sipe_ocs2007_process_roaming_self: dropping category: state
(17:22:13) sipe: sipe_ocs2007_process_roaming_self: key=<state><1><2> version=1
(17:22:13) sipe: sipe_ocs2007_process_roaming_self: key=<state><268435456><2> version=1
(17:22:13) sipe: sipe_ocs2007_process_roaming_self: key=<state><1058033473><2> version=1
(17:22:13) sipe: sipe_ocs2007_process_roaming_self: added GHashTable cat=state
....</state></state></state></f808e001678446f7bc093b5e72d5d6a7></service></d4b6g3d9faecdei0801m400ft533dba61ax454bx></bn11a02fes05.in></sip></tls-dsk>

And the subsequent message validates fine (though not all of them):
(17:22:13) sipe: sip_sec_verify_signature: message is:<tls-dsk><6C07E3F3><9><sip communications="" service=""><bn11a02fes05.in ra.lync.com=""><b952g81b8a9dd9i5391mfb18t284cb27d4xac1ax><2><notify>sip:mteterin1271@example.com<1F5B0080>sip:mteterin1271@example.com<4070135742><><><> signature to verify is:268e747f407158bd645225304d2727678984f48a
(17:22:13) sipe: sip_transport_input: signature of incoming message validated
(17:22:13) sipe: process_input_message: msg->response(0),msg->method(NOTIFY)
(17:22:13) sipe: send->process_incoming_notify
(17:22:13) sipe: process_incoming_notify: subscription_state: active;expires=31846</notify></b952g81b8a9dd9i5391mfb18t284cb27d4xac1ax></bn11a02fes05.in></sip></tls-dsk>

I was able to even add a few colleagues to the list of "buddies" -- the process also caused some signature-invalid messages followed by normal ones. Haven't tried actually talking to anybody yet, because Friday after 5pm everyone is gone already...

So, NOTIFY-messages are validated, but REGISTER aren't?

[Mikhail T.]

Ok, just found someone to "talk" to here. They see me online, which is good. They sent me a test-message, which shows up in the log:

(17:39:26) sipe: sip_sec_verify_signature: message is:<tls-dsk><359A724D><27><sip communications="" service=""><bn11a02fes05.i fra.lync.com=""><f32e98578bc2234f8d782c1f1233156c><1><invite>marc_zxxxx@example.com<2abdb2dc16>sip:mteterin1271@example.com<><><><> signature to verify is:422ab154414b53c1b12b773aa8e785b0d5475be3
(17:39:26) sipe: Signature mismatch: told to expect 422AB154414B53C1B12B773AA8E785B0D5475BE3' (20 bytes), calculated0 803DBFDE57E06F9D9E7318FDD2149DAF0495BA' (20 bytes)
(17:39:26) sipe: sip_transport_input: signature of incoming message is invalid, but processing the message anyway
(17:39:26) sipe: process_input_message: msg->response(0),msg->method(INVITE)
(17:39:26) sipe: Adding a Tag to the To Header on Invite Request...
(17:39:26) sipe: parsing address out of "Zxxxxx, Marc - Technology & Product Engineering marc_zxxxxxx@timeinc.com"< ip:mzampetti0264@timeinc.com>;tag=2abdb2dc16;epid=79ccd34b6c
(17:39:26) sipe: got marc_zampetti@timeinc.com
(17:39:26) sipe: sipe_session_find_or_add_im: new session for marc_zampetti@timeinc.com
(17:39:26) sipe: sipe_dialog_parse_routes: route <sip:sippoolbn11a02.infra.lync.com:443;transport=tls;ms-fe=bn11a02fes05 infra.lync.com;opaque="state:Ci.R1c70a500:Ti.2kwKiqaLFU-9QX0vdai0ywAA;lr;ms-route-sig=fj3T01_KE4kEFFvW0LOszw8gw24_96H6BN4" ygb4wwjou6hiowjpnzjgaa="">;ms-rrsig=fjzVHviP058yTTzNz-K2YN9SZ78_qb4F4F_ttqqsqXIKc6HIoWJpNZJgAA;tag=9097CF8295138119B04780F5 77C4378</sip:sippoolbn11a02.infra.lync.com:443;transport=tls;ms-fe=bn11a02fes05></invite></f32e98578bc2234f8d782c1f1233156c></bn11a02fes05.i></sip></tls-dsk>

But I don't see their message in Pidgin...

[Stefan Becker]

Posting of partial log fragments don't really help, as they don't tell me anything.

Your problem is definitely weird. Some crazy ideas:

• compiler bug which only affects code at certain points
• bug in SIPE crypto backend (or affected by compiler bug). I assume you used the default NSS. Maybe try to compile with OpenSSL instead?
• compiler optimization bug. Try to disable optimization?

You should really try to use that account with another client/platform. If you can give me your credentials I could try myself. This remote debugging isn't really going anywhere.

[Stefan Becker]

No updates from reporter. Closing as WORKSFORME as SIPE code seems to work correctly.

Based on the available information my best guess is a compiler/platform problem which causes the HMAC(SHA-1) operation to return wrong results on some invocations.

[Mikhail T.]

Based on the available information my best guess is a compiler/platform problem which causes the HMAC(SHA-1) operation to return wrong results on some invocations.

Stefan, this is a bogus assessment. On your request I switched from using NSS to GnuTLS and all the symptoms remained exactly the same. Pidgin continues to work just fine here with Google (over SSL) and AIM. The rest of my computer is likewise perfectly functional -- I'm typing this over an SSL connection to SourceForge, for example, with an NSS-using Firefox. My Thunderbird has no problems connecting to several different IMAP-servers (with SSL) either.

There may indeed be something wrong with my company's server(s) -- we are only just deploying Lync here, but none of my colleagues are having these issues using the official Lync-clients for both Windows and Mac.

Whatever the problem is, it is not because my SSL-libraries are somehow miscompiled.

[Stefan Becker]

Based on the available information ...

Stefan, this is a bogus assessmen

Please read the first sentence carefully.

[Mikhail T.]

The patch, that allows the program to proceed regardless of signature-verification status, is what currently allows me to sign-in to the company's Lync service. My co-workers using the official Lync-client do not have any problems, of course.

The earlier used patch applies fine with 1.18.5, which I use on my office computer (FreeBSD/i386).

For 1.19.0, which I just installed at home (FreeBSD/amd64), I had to adjust it a little-bit (see attachment). Yes, I did try 1.19.0 straight -- without the patch -- to no avail.