MSN SSL problems again

[Stu Tomlinson]

On Wed, 2010-11-24 at 22:32 +0000, David Woolley wrote:
> Zacknafain Do'Urden wrote:
> > So what is it?  Has microsoft decided to make a play for propritary tech
> > or something?
> 
> In this case, it is probably a case of being reckless about Pidgin, 
> etc., but, if you actually read the terms of use you agree to when you 
> sign up to the MSN service, you will find that you agree not to use 
> Pidgin or any other client not in a short list of approved clients.

Please remember Hanlon's Razor:
"Never attribute to malice that which is adequately explained by
stupidity."

> Part of this will be for protection against misoperating clients, but
> a major factor will be protecting the business model on which the
> service is based.  For example, a recent comment was that Pidgin
> avoided the adverts that you get with Live Messenger, but one of the
> reasons Microsoft will operate that service free of charge to end
> users will be the advertising revenue that they obtain.

Part of what? A recent comment where? Can you actually point to anything
Microsoft have ever done that can be demonstrably proved to be done
solely with the intention of blocking 3rd party clients? (I hate to
sound defensive of Microsoft here, but FUD should not be allowed either
way).

> In this case, the change was probably made for valid security reasons, 
> but it seems to have taken short cuts which rely on an updated client 
> having information coded into it that the server would have to provide, 
> in other cases, such as accessing https URLs.  The Microsoft client will 
> have this update done, but until they make the change, unofficial 
> clients may have no reason to believe that the client has been prepared 
> for such a change.

The change was made because their SSL certificate was expiring, so they
renewed it, I guess that counts as "valid security reasons". The reason
they didn't detect (and so far don't seem too concerned about) the
mis-configuration of the server(s) is that their primary client already
recognizes the new intermediate certificates that signed the new SSL
certificate as trusted anyway, so they don't have a problem with the
fact that the server(s) are still providing the old intermediates in the
chain. But the reason their primary client trusts the new certificate is
simply because they ship & update their primary OS with their own
intermediate certificates too.

Regards,


Stu.