M$ seems to be rolling out a server configuration change that disables RC4 stream cipher support in SChannel (== Windows crypto implementation). Therefore (some) Office365 servers no longer accept the SIPE ClientHello message in the TLS-DSK handshake. The server responds without sending any TLS-DSK GSSAPI data back, i.e. sipe-tls is called with an empty TLS record.
Depending on the authentication settings the end user sees one of the following error messages:
We need to add (at least) AES-128/256-CBC stream cipher support in SIPE.
Unable to authenticate for the last couple of days. Another user reported the same issue in the forums, so I don't believe this is just me. I'm on Sipe v. 1.18.4. The gui gives the error: "Failed to authenticate to server". I'm using "UCCAPI/15.0.4420.1017 OC/15.0.4420.1017 (Microsoft Lync)" as the user agent with auth scheme: TLS-DSK.
Thanks.
Bugs: #287
Forums: Sipe plugin stopped working 8/19/2015
Forums: Sipe plugin stopped working 8/19/2015
Forums: Sipe plugin stopped working 8/19/2015
Release Notes: 2015/08/pidgin-sipe-release-1200
I already came to the same conclusion after reading some more of TLS 1.2. Also the format of the TLS ciphered message is different for block ciphers.
I already fixed the crash on NSS with a workaround.
Oh, awesome! So what's the current issue with OpenSSL? Maybe I can help? (longtime developer/crypto protocol expert here)
Thanks!
-d
No issues, just missing implementation :-) The next steps are pretty clear now, I just need to find free cycles to get them done.
Please monitor git head and yell if you see a mistake.
Thanks. I'll keep an eye out. I admit that looking at your current changes it's not how I would have refactored it; I would have just sent the cipher, key, iv, etc. down into the sipe tls layer and let that layer decide whether to perform stream or block cipher processing. But then again this isn't my code so I don't have a lot of say into the "right way" of implementing it.
I'll look for the AES-CBC implementation, and I'll gladly test it (especially if you decide to form it into a patch against 1.19.1) :)
Please do not attach more (incorrect) logs. We know what is wrong and another log won't change that, just be a waste of time.
Sorry.
I've added block cipher support in sipe-tls, but unfortunately sipe_tls_tester still fails. It's too late in the evening for clear thoughts, so I pushed the current progress to HEAD.
Additionally OpenSSL compiled version crashes with some memory corruption, so I guess the AES-CBC implementation is still incorrect for that crypto backend.
Thanks Stefan for the work! From browsing through the code, it looks like the CBC IV is never initialized and the block encryption is not invoked at all. The latter could be the cause why sipe_tls_tester is failing.
Trying to generate a TLS 1.2 GenericBlockCipher is not a good idea when you announce that you are using TLS 1.0 :-(
sipe_tls_tester & Office365 login now passes with NSS cyrpto backend. Yeah!
OpenSSL AES_CBC crash fixed too. I'm able to login to my Office365 account with both crypto backends now.
Please make sure to test git HEAD
Hello. I recently began experiencing this exact problem and after applying this patch my issue has been resolved. My account now properly authenticates and Adium connects to Office365.
This fixed connection issues with my Office 365 account as well. Thank you for a quick fix.
FYI: latest git HEAD compiles on Mac and Adium can connect to my Office365 test account.
Tested and verified on CentOS 7 and Mint Linux. Nice and quick work!
I just built the mob branch and would like to confirm that the fix works on
Thank you for your hard work!
Should I not be able to run a :
./sipe_tls_tester sipdir.online.lync.com ?
commit 4f34ae0500d13c7b921a3243a7981b3cb96b1ac7
nikolaj@stevieray:~/workspace/libsipe/src/core$ uname -a
Linux stevieray 3.13.0-63-generic #103-Ubuntu SMP Fri Aug 14 21:42:59 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
.. and I am once I check out the right branch ..
Sorry guys. Nice work!
Excellent. The latest git snapshot works. Bravo, Stefan Becker! You rock!
Mint 17.2 x86-64
libpurple 2.10.9
Pidgin 2.10.9
libnss3 3.19.2
configure flags: --enable-nss=yes --enable-openssl=no --prefix=/usr
Last edit: Rob Shinn 2015-08-26
Hello.
Thanks Stefan Becker.
I compiled a pidgin new version and after applying this patch could connect with Office 365 again.
I'm using:
Fedora 20
Pidgin 2.10.11 (libpurple 2.10.11)
Thank you for hard and fast work!
Stefan,
I registered today to thank you for fixing this.
It stoped working for me yesterday.
Compiled it and now it works.
Ubuntu 14.04.3 LTS
Pidgin 2.10.11 (libpurple 2.10.11)
Thanks
Verified compiled and working on:
Ubuntu 15.04
libpurple (2.10.9)
* pidgin (2.10.9
Thank you very much for your quick fix!!!
Diff:
FYI: verified git HEAD code that it also works with Windows Pidgin
To help out package maintainers for distros that can't move to the upcoming release 1.20.0 I have backported the TLS-DSK AES-128/256-CBC support to 1.181.x/1.19.x and created the attached patch.
I have tested it with 1.18.5 & 1.19.1 and I'm able to login to my Office365 test account.