Menu

#285 Office365 rejects RC4 in TLS-DSK

OBSOLETE_(1.19.x)
closed-fixed
None
Pidgin
9
2016-04-23
2015-08-21
beeg
No

FYI: Discussion has been disabled for this bug as it generates too much noise

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:

  • Failed to authenticate to server
  • Incompatible authentication scheme chosen

We need to add (at least) AES-128/256-CBC stream cipher support in SIPE.

Original description follows:

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.

1 Attachments

Related

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

Discussion

<< < 1 2 (Page 2 of 2)
  • Stefan Becker

    Stefan Becker - 2015-08-25

    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.

     
    • Derek Atkins

      Derek Atkins - 2015-08-25

      Oh, awesome! So what's the current issue with OpenSSL? Maybe I can help? (longtime developer/crypto protocol expert here)
      Thanks!
      -d

       
      • Stefan Becker

        Stefan Becker - 2015-08-25

        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.

         
        • Derek Atkins

          Derek Atkins - 2015-08-25

          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) :)

           
  • Stefan Becker

    Stefan Becker - 2015-08-25

    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.

     
  • Jordão Vieira

    Jordão Vieira - 2015-08-25

    Sorry.

     
  • Stefan Becker

    Stefan Becker - 2015-08-25

    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.

     
    • John Zhang

      John Zhang - 2015-08-26

      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.

       
  • Stefan Becker

    Stefan Becker - 2015-08-26

    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!

     
  • Stefan Becker

    Stefan Becker - 2015-08-26

    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

     
    • Brett Meiggs

      Brett Meiggs - 2015-08-26

      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.

       
    • Petri Haikonen

      Petri Haikonen - 2015-08-26

      This fixed connection issues with my Office 365 account as well. Thank you for a quick fix.

       
  • Stefan Becker

    Stefan Becker - 2015-08-26

    FYI: latest git HEAD compiles on Mac and Adium can connect to my Office365 test account.

     
    • Marcus Sundberg

      Marcus Sundberg - 2015-08-26

      Tested and verified on CentOS 7 and Mint Linux. Nice and quick work!

       
  • Kambiz Darabi

    Kambiz Darabi - 2015-08-26

    I just built the mob branch and would like to confirm that the fix works on

    • Ubuntu 14.04 trusty
    • Pidgin 2.10.9
    • libpurple 2.10.9

    Thank you for your hard work!

     
  • Nikolaj Hansen

    Nikolaj Hansen - 2015-08-26

    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

     
    • Nikolaj Hansen

      Nikolaj Hansen - 2015-08-26

      .. and I am once I check out the right branch ..

      Sorry guys. Nice work!

       
  • Rob Shinn

    Rob Shinn - 2015-08-26

    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
  • Jordão Vieira

    Jordão Vieira - 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!

     
  • Mark Pawlikowski

    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

     
  • Jerry Kilpatrick

    Verified compiled and working on:
    Ubuntu 15.04
    libpurple (2.10.9)
    * pidgin (2.10.9

    Thank you very much for your quick fix!!!

     
  • Stefan Becker

    Stefan Becker - 2015-08-26
    • Description has changed:

    Diff:

    --- old
    +++ new
    @@ -1,3 +1,7 @@
    +FYI: Discussion has been disabled for this bug as it generates too much noise
    +-------------------------------------------------------
    +
    +
     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:
    
    • discussion: enabled --> disabled
     
  • Stefan Becker

    Stefan Becker - 2015-08-26

    FYI: verified git HEAD code that it also works with Windows Pidgin

     
  • Stefan Becker

    Stefan Becker - 2015-08-29

    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.

     
  • Stefan Becker

    Stefan Becker - 2015-08-29
    • status: open --> closed-fixed
     
<< < 1 2 (Page 2 of 2)