Menu

#295 Read Error back after company switches to Skype for Business

OBSOLETE_1.20.x
closed-invalid
None
Adium
5
2018-12-11
2015-11-05
No

Hi,

I've read the FAQ and reviewed the Closed Tickets. I apologize if I missed something.

I'm using 1.20.1 on Adium 1.5.10 on Mac 10.11.1.

I've previously overcome the Read Error with the SSL Beast Mitigation setting, but it seems to be back after my company upgraded from Lync to Skype for Business.

I do currently have it set. My attached log shows:

11:59:20: (Libpurple: cdsa) Explicitly disabling SSL BEAST mitigation for broken server implementations

but for some reason it still fails. Could it be NAT related? I see this in the attached log:

Via: SIP/2.0/tls 192.168.1.2

But my official Lync client (which does work) properly shows my local machine address, 192.168.2.13, in it's logs and not my router address, 192.168.1.2. I tried to change DMZ etc. to force all ports to go to 192.168.2.13, but still no luck.

Is that a wild goose chase? If not, how to configure it properly since I never had to previously? Everything worked fine until something was done on the server side due to Skype for Business.

Thanks,
Ken

1 Attachments

Discussion

  • Stefan Becker

    Stefan Becker - 2015-11-05

    As you have read the other discussions already you should know that SIPE can't do anything about this. Please do no missuse bug reports for something we can't fix.

    Things you might try:

    • try Adium 1.5.11.
    • Compile Adium & SIPE to make sure they match the Max OS X version you are running
    • verify with ssldump that your Mac OS X honors the request from Adium/cdsa plugin to disable SSL BEAST mitigations, i.e. ssldump should not show 1/N-1 split SSL data packets. (see [bugs:#216] for details)

    Closing as INVALID

     

    Related

    Bugs: #216

  • Stefan Becker

    Stefan Becker - 2015-11-05
    • status: open --> closed-invalid
     
  • Stefan Becker

    Stefan Becker - 2015-11-05

    Two more things I remembered:

    • when checking the network packages, e.g. with Wireshark, please make sure to check the TLS version. The SSL BEAST mitigation setting will only have an effect if the connection uses TLS 1.0. On my test Mac with OS X 10.11.1 TLS 1.2 seems to be the default.
    • As far as I remember only Lync 2010 servers where ever affected by the SSL BEAST mitigation issue. I would be really surprised if the problem turns up again with Skype for Business servers, which is either Lync 2013-renamed or the next version.
     

    Last edit: Stefan Becker 2015-11-05
  • Ken Botwinick

    Ken Botwinick - 2015-11-05

    I actually didn't see anything that said this popped back up when the server side changed from Lync to Skype for Business, with no changes on client side to Adium or Mac (I'm currently at 10.11.1, but this problem started when I was still at 10.10). I literally didn't change anything on my end. I'm not sure why my Mac would stop honoring the request to disable SSL BEAST mitigations when it had been doing so reliably for at least a year. Can you point me to a forum post or bug similar to this situation? I literally didn't see one. Thanks.

    [Edit - Our posts passed each other. I'll look into the TLS version you mention. Thanks for the direction.]

    [Second edit - It might have been the case that it was failing for a different reason back in 10.10. DNS issue where Lync also failed. So the TLS version might explain why it's still failing now that I've fixed Lync but am on 10.11.1]

     

    Last edit: Ken Botwinick 2015-11-05
  • Stefan Becker

    Stefan Becker - 2015-11-05

    Please also check the Lync connection with Wireshark.

     

Log in to post a comment.