Protocol plugin for Office 365/Lync/OCS / Bugs / #285 Office365 rejects RC4 in TLS-DSK

Bug reports against obsolete SIPE versions are ignored. Please provide a debug log from SIPE 1.19.1 that shows the same problem.

According to the log the Lync server no longer accepts any of the TLS-DSK data in the REGISTER messages send by SIPE. The server responds with no handshake data and does not provide any error message, which leads to a TLS-DSK failure:

(12:02:09) sipe: 
MESSAGE START >>>>>>>>>> SIP - 2015-08-21T18:02:09.518616Z
REGISTER sip:mycompany.com SIP/2.0
...
(12:02:09) sipe: 
MESSAGE START <<<<<<<<<< SIP - 2015-08-21T18:02:09.898687Z
SIP/2.0 401 Unauthorized
...
WWW-Authenticate: TLS-DSK realm="SIP Communications Service", targetname="BL20A09FES04.infra.lync.com", version=4, sts-uri="https://webpoolbl20a09.infra.lync.com:443/CertProv/CertProvisioningService.svc"
...
(12:02:09) sipe: process_register_response: Auth header: TLS-DSK realm="SIP Communications Service", targetname="BL20A09FES04.infra.lync.com", version=4, sts-uri="https://webpoolbl20a09.infra.lync.com:443/CertProv/CertProvisioningService.svc"
...
(12:02:09) sipe: initialize_auth_context: TLS-DSK certificate for target 'BL20A09FES04.infra.lync.com' found.
(12:02:09) sipe: sip_sec_create_context: type: 5, Single Sign-On: no, protocol: SIP
(12:02:09) sipe: sipe_tls_fill_random: 256 bits -> 32 bytes
(12:02:09) sipe: compile_handshake_msg: buffer size 108
(12:02:09) sipe: compile_handshake_msg: (1)Client Hello, size 45
(12:02:09) sipe: compile_tls_record: total size 49
(12:02:09) sipe: TLS MESSAGE OUTGOING
TLS 1.0 (RFC2246) record (54 bytes)
TLS handshake (45 bytes) (1)Client Hello
Client Protocol Version/INTEGER2 = 769
Random/ARRAY[32]
SessionID/VECTOR<0>
CipherSuite/VECTOR<6>
CompressionMethod/VECTOR<1>
...
MESSAGE START >>>>>>>>>> SIP - 2015-08-21T18:02:09.899282Z
REGISTER sip:mycompany.com SIP/2.0
...
Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", targetname="BL20A09FES04.infra.lync.com", gssapi-data="FgMBADEBAAAtAwFV12eh7OWeMkoNjo6zGxRnUopaYbuo4irNCqaOf4eKLwAABgAEAAUAAwEA", version=4
...
(12:02:10) sipe: 
MESSAGE START <<<<<<<<<< SIP - 2015-08-21T18:02:10.216657Z
SIP/2.0 401 Unauthorized
...
WWW-Authenticate: TLS-DSK realm="SIP Communications Service", targetname="BL20A09FES04.infra.lync.com", version=4, sts-uri="https://webpoolbl20a09.infra.lync.com:443/CertProv/CertProvisioningService.svc"
From: <sip:myusername@mycompany.com>;tag=4750130301;epid=465ba5f226c7
...
(12:02:10) sipe: process_register_response: Auth header: TLS-DSK realm="SIP Communications Service", targetname="BL20A09FES04.infra.lync.com", version=4, sts-uri="https://webpoolbl20a09.infra.lync.com:443/CertProv/CertProvisioningService.svc"
(12:02:10) stun: using server 
(12:02:10) stun: using server 
(12:02:10) sipe: TLS MESSAGE INCOMING

(12:02:10) sipe: compile_handshake_msg: buffer size 966
(12:02:10) sipe: compile_handshake_msg: (11)Certificate, size 949
(12:02:10) sipe: check_cipher_suite: server didn't specify the cipher suite
(12:02:10) sipe: initialize_auth_context: security context continuation failed
(12:02:10) connection: Connection error on 0x7f8f9dbf87a0 (reason: 2 description: Failed to authenticate to server)

I can't reproduce this with my Office 365 test account.

It could be that the underlying SChannel on the server was changed and no longer accepts the currently implemented SSL handshake data. If that is the case we can only provide a fix if Man-In-The-Middle Attack logs from the TLS encrypted SIP connection of a working Lync client session are provided.

Stefan Becker - 2015-08-21

Please apply the attached patch and recompile SIPE. It changes the TLS version from 1.0 to 1.1 in the TLS-DSK handshake messages.

With my Office 365 test account I now get a handshake failure, the same as shown in your log, in about 50% of the login attempts. This could indicate that M$ is currently rolling out SChannel updates to its Office365 servers in phases.

If 1.1 doesn't work for you either, then please try to change TLS_PROTOCOL_VERSION_CURRENT in src/core/sipe-tls.c from _1_1 to _1_2.

Last edit: Stefan Becker 2015-08-21

sipe-tls-1-1.patch

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

beeg - 2015-08-21

I applied the patch and tried it, and no luck. I then changed the TLS_PROTOCOL_VERSION_CURRENT as described above and still no luck. Attaching new debug log.

pidgin-debug2.log

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Stefan Becker - 2015-08-21

Unfortunately you didn't record a --debug log thus the information is useless.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

beeg - 2015-08-21

Sorry about that. I figured the debug window would show a debug log, but I was wrong. New log attached.

pidgin-debug3.log

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Stefan Becker - 2015-08-21

The updated patch automatically retries with a higher TLS version. I doubt that it helps though.

Now that I tried several times I have also seen this error on my test account. Even with the above code it can fail. So something is still missing, maybe some TLS 1.1 or TLS 1.2 addition.

For now I can only suggest to retry the connect multiple times. At least on my account I seem to get different servers and on most of them the original code still works.

If you can provide MITM attack logs from a Lync client that would be extremely helpful.

sipe-tls-dynamic-version.patch

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Stefan Becker - 2015-08-21

Stupid me, the MITM attack logs are only required if the problem lies in the HTTPS connections.

Please connect to your account with the Windows Lync client and provide the SIP log from that client (see FAQ).

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

beeg - 2015-08-21

Unfortunately, I'm running a linux machine, so I don't have a lync client to use. Also, you noted that I should keep trying to connect and see if I can get a server that has it working. So far that hasn't worked for me. It's possible that the servers my company has been assigned to have completed the upgrade, so no servers are left that are on the old version. But no worries. I don't rely on chat for that much, and the web portal offers me as many features as I need even if they are less convienent. I do appreciate the work you are doing, and thank you for looking into this bug. Hopefully other users with more information will pitch in soon and get you the logs you need.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Stefan Becker - 2015-08-21

I poked a bit around in the TLS 1.2 RFC. Maybe the problem is simply that one of our offered cipher suites (that emberassing RSA export with 40-bit key length) is no longer accepted. Can you please try the updated patch?

sipe-tls-dynamic-version-2.patch

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Zootal - 2015-08-21
  
  I tried the patch to the 1.19.1 source. It applied sucessfully, compiled, build, but I still get Failed to authenticate to server. I'm not an expert here, you might want to wait for someone else to try and report before assuming it didn't work...
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - Nikolaj Hansen - 2015-08-25
    
    tried the same on the master branch and I cannot login either.
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

beeg - 2015-08-21

Still no luck. I'm out for the day. Thanks for your help. Attached is my last debug log.

pidgin-debug4.log

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Bill Roehl - 2015-08-22

Same issues. Attached Adium log.

adiumlog.pdf

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

summary: Failed to Authenticate to Server --> Office365 TLS-DSK authentication failure
Description has changed:

Diff:

--- old
+++ new
@@ -1,3 +1,14 @@
+Some servers no longer accept 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
+
+It currently looks like M$ is rolling out some update to its servers, so it is likely that more an more users will be affected by it.
+
+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.

assigned_to: Stefan Becker

Description has changed:

Diff:

--- old
+++ new
@@ -5,7 +5,7 @@
 * Failed to authenticate to server
 * Incompatible authentication scheme chosen

-It currently looks like M$ is rolling out some update to its servers, so it is likely that more an more users will be affected by it.
+It currently looks like M$ is rolling out some update to its servers, so it is likely that more and more users will be affected by it.

 Original description follows:
 ---------------------

Stefan Becker - 2015-08-23

It seems the update has now reached also the servers for my Office365 test account.

I have now been able to record a SIP log from the Windows Lync client. I can now confirm that Lync servers now expect new CipherSuites in the TLS ClientHello message:

SIPE ClientHello #define TLS_RSA_WITH_RC4_128_MD5 0x0004 #define TLS_RSA_WITH_RC4_128_SHA 0x0005 #define TLS_RSA_EXPORT_WITH_RC4_40_MD5 0x0003 Latest Lync ClientHello #define TLS_RSA_WITH_AES_128_CBC_SHA 0x002F #define TLS_RSA_WITH_AES_256_CBC_SHA 0x0035 #define TLS_RSA_WITH_RC4_128_SHA 0x0005 #define TLS_RSA_WITH_3DES_EDE_CBC_SHA 0x000a #define TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 0xC013 #define TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 0xC014 #define TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA 0xC009 #define TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA 0xC00A #define TLS_DHE_DSS_WITH_AES_128_CBC_SHA 0x0032 #define TLS_DHE_DSS_WITH_AES_256_CBC_SHA 0x0038 #define TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA 0x0013 #define TLS_RSA_WITH_RC4_128_MD5 0x0004 Server responds with #define TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 0xC014

When I manually add 0xC014 to sipe-tls.c the TLS-DSK handshake proceeds further. I'll check what additional crypto functionality will be required for the new CipherSuites.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Derek Atkins - 2015-08-24
  
  When I manually add 0xC014 to sipe-tls.c the TLS-DSK handshake proceeds further. I'll check what additional crypto functionality will be required for the new CipherSuites.
  
  This is ECDHE+RSA with AES_256_CBC SHA, which means you'll need Ephemeral ECDH (ECC) Key agreement, RSA certificate verification, AES-256-CBC block data encryption, and SHA(1) hash. Current OpenSSL should supply all these, although I don't know what libnss provides.
  
  Honestly, I find it absolutely scary that the only ciphersuites we had before were ALL RC4 based and gasp weak (export grade) crypto!! YIKES! Im also surprised that MS didn't include SHA256 hashes, but whatever.
  
  I'll gladly test any patches you create; let me know if there's anything else I do to help.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - Derek Atkins - 2015-08-24
    
    Looking more closely at the list, the current Lync client still includes 0x0004 and 0x0005, which are the two RC4 ciphersuites supported by sipe. Clearly the new MS servers don't accept RC4 anymore. So you're definitely going to need to implement something else. You could implement 0xC014, or you could iterate over each entry in the list (send the single entry in the ClientHello) and see which ones are acceptable to the server and then decide which of them to implement.
    
    Looking at sipe-tls.c you'll need to not only update tls_client_hello() but you'll also need to update check_cipher_suite(), and possibly add more code to support e.g. AES (unless you can just offload that completely to the crypto library, which is what I'd suggest). For example you'll need to change sipe_crypt_tls_start() to take a block cipher instead of assuming RC4.
    
    Again, let me know how I can help.
    
    Last edit: Derek Atkins 2015-08-24
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
    - Stefan Becker - 2015-08-25
      
      TLS-DSK does not protect the whole communcation channel, just a few authentication bits exchanged in the REGISTER SIP messages. So EHDCE-RSA vs. plain RSA really doesn't add anything to the security.
      
      But realizing this the shoe finally dropped and I tried TLS_RSA_WITH_AES_xxx cipher suites. Voilá, Lync server accepts those two.
      
      Now I only have to get AES-CBC working. With OpenSSL the TLS handshake fails, with NSS the code crashes.
      
      If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Stefan Becker - 2015-08-23

Group: 1.18.x --> 1.19.x
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Radu Pop - 2015-08-24

Hello,

Same problem here. Should I attach a log?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Stefan Becker - 2015-08-25

summary: Office365 TLS-DSK authentication failure --> Office365 rejects RC4 for TLS-DSK authentication failure
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Jordão Vieira - 2015-08-25

Hello!
As I can see, I'm not the only one with conection problems.
My error description in English: "Server authentication failed"
My debug log is attached.
Agent : UCCAPI/4.0.7577.314 OC/4.0.7577.314 (Microsoft Lync 2010)
Using TLS-DSK
Is there something else I can do to help us ?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Stefan Becker - 2015-08-25

summary: Office365 rejects RC4 for TLS-DSK authentication failure --> Office365 rejects RC4 in TLS-DSK

Description has changed:

Diff:

--- old +++ new @@ -1,11 +1,11 @@ -Some servers no longer accept 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. +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 -It currently looks like M$ is rolling out some update to its servers, so it is likely that more and more users will be affected by it. +We need to add (at least) AES-128/256-CBC stream cipher support in SIPE. Original description follows: ---------------------
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Derek Atkins - 2015-08-25
  
  Stefan,
  
  Just a minor correction here: AES-XXX-CBC is not a stream cipher, it's a block cipher in a chaining block mode. I suspect your crash/non-working code with OpenSSL/NSS is the assumption that output length == input length when you encrypt. That was true with RC4 (which is a true stream cipher) but with AES-CBC that is NOT true. The output message will be padded up to the next block (16 bytes long).
  
  You will need to take that into account in your processing.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Office365 rejects RC4 in TLS-DSK

for Adium, Pidgin, Miranda and Telepathy IM Framework

Group

Searches

Help

#285 Office365 rejects RC4 in TLS-DSK

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

Original description follows:

Related

Discussion