Merry Christmas and Happy Holidays

Greetings,

Just a quick note to wish my readers and users a very Merry Christmas and Happy Holidays (whichever applies to you!).

Wishing you all the best!
Jonathan

Messenger Service now requiring HTTPS (and error code 80072efd)

In the last fortnight, Microsoft restricted previously revived or third-party Messenger clients to use HTTP access.  Yesterday, they improved security by requiring TLS instead of SSL.  Today, they’ve gone a step further and now require HTTPS, therefore making Messenger conversations encrypted to the Microsoft server.  Presently, the only non-modified desktop Messenger client to support this is Windows Live Messenger 2012.

For versions of Windows Live Messenger 2011, 2009 or 2008, you will get error code 80072efd and you will need to re-revive with Messenger Reviver 2.4.0 for Messenger to work.  For all other clients (Pidgin, Adium, other libpurple clients), where the option allows, you can continue to sign in by changing the Messenger server from messenger.hotmail.com to msn.messengergeek.com.

If you wish to still use the major Windows Messenger 4 or 5 versions, Messenger Reviver 2.4.0 will patch those too.  In Reviver, choose the Advanced button and then Patch Messenger option to revive these older Windows Messenger clients.

At the moment, Messenger:mac will not be working.  Future versions of Messenger Reviver 2:mac should be able to fix it.

Error code 80048820 and Windows XP

In the last 48 hours Microsoft has improved the security of Microsoft Account/Windows Live ID/.NET Passport authentication by requiring you to use Transport Layer Security (TLS) to sign in.  TLS is the “next version” of what you might know as SSL, commonly shown as a padlock icon in the address bar of a web browser.

The problem with this change is that by default, Windows XP has TLS support disabled.  This also means that Messenger will fail to sign in and you’ll see the following message with error code 80048820:

To solve the problem, you will need to turn on TLS in Windows.  You can either download and run the latest version of Reviver to enable this, or follow the three steps below:

1. Click Start, then Run, type inetcpl.cpl and click OK.
   
2. Click the Advanced tab, scroll down to the Security section at the bottom and select Use TLS 1.0 so that it’s checked.
   
3. Then choose OK and try Messenger again.

The change should take effect immediately and you should now be able to sign in as normal.

Microsoft appears to be pushing the .NET Messenger Service to HTTP

The changes to Messenger have continued this week with Microsoft blocking access to port 1863 (that’s the defacto port for Messenger) firstly with the servers known as messenger.hotmail.com (bay.*) on December 1st and then the bn1.gateway.messenger.live.com (bn.*) server(s) on December 3rd.

The ever ingenious dx put together a status page listing the various types of servers in the network and their current status.

In practical terms, this means that instead of using the MSN protocol directly, the protocol is now being funneled over an HTTP connection, just like a web page. The Microsoft Messenger clients will automatically give up on port 1863 and use HTTP without any prompting, so if you’re a Messenger Reviver user, you shouldn’t have to do anything.  However, third-party clients may require triggering their HTTP mode options manually, and some don’t support the HTTP mode.

You’ll note that on dx’s status page, only the servers that are directly called using hostnames have port 1863 blocked.  The more technically interested can force Messenger into using 1863 by using their local hosts file or setting up their own DNS server to redirect messenger.hotmail.com to one of the working bay servers, and bn1.gateway.messenger.live.com to one of the bn.* servers.