tl;dr - Ignore this post if you just want stuff to work, you’re still stuck with version 4.7.0106 or lower.
Had a quick go at naively patching 5.0.xxxx to downgrade to MSNP7, it doesn’t appear to work. Version 5.0.0124 does log in, but cannot retrieve the contact list. Versions 5.0.03xx don’t seem to respond to being autopatched (the strings aren’t found). Versions 5.0.05xx attempt to authenticate via TWN regardless of the my MSNP8 -> MSNP7 patch, however this could be because I’ve also accidentally patched the string it uses to decide which method to use.
Edit: No luck, perhaps the MD5 authentication code might’ve been ripped entirely out of later versions of 5.0, I can’t tell at a glance. Not that it would’ve been super useful anyway, just to enable a couple of builds of Messenger 5 to run on 98/Escargot, but I figured it was worth a quick test. Version 4.7.0xxx it is then…
Edit 2: Doh, I forgot that 5.0 betas use internal testing domains, which probably has something to do with what autopatcher missed them. Doesn’t change anything, I just thought I’d mention that in case anyone reads this.
I have verified that 4.7.0106 works on Windows 98, however, so I’ll update my “tl;dr” above, which is one build behind.
MSN Messenger relies on Internet Explorer for its web connectivity, so it really comes down to what the version of IE installed supports. I don’t have specifics written down, but I believe MSN Messenger 7.0 requires IE6, and it won’t install without it. Not absolutely certain about MSN Messenger 5.x and 6.x, though my experiments just now with 5.x were with IE5.01 installed.
The problem, however, isn’t that Windows 98 or IE5/6 lack the necessary SSL support, MSN Messenger can absolutely use SSL with those configs. To the best of my knowledge, Microsoft’s servers all had SSL certificates and IPs specific to the (sub)domains with which they were associated, and my own development server does the same - and MSN is fully compatible with that, even on Windows 98.
The issue with Escargot is that it uses SNI (Server Name Identification) in order to use just one server to host everything, which is an extension to SSL which enables the client to specify which domain it’s expecting to receive an SSL certificate for. Without this, any SSL connection you make to the server could receive the wrong certificate and the connection would fail.
This works fine as long as the client (MSN, or IE) is modern enough to support that. This is why Windows XP and earlier have issues with, or simply cannot connect to, Escargot. Vista and later (or probably more specifically, IE7) support SNI, and that’s why it’s possible to use MSN/Live Messenger 5.x-8.x without issue.
From peeking at the GitLab, it seems that Escargot uses a “Caddyfile” for HTTPS stuff. I wonder if that’s what causing the problem (or if it’s just aiohttp, but who knows?).
EDIT: Just realized that the “Caddyfile” is for handling non-SNI requests. But I’m not really sure of that.
I’m not really sure if it could be properly fixed without using multiple IP addresses, I don’t remember how many domains 5.0 requires, but from memory it could be anything up to 4; nexus.passport.com, login.passport.com, gateway.login.live.com, and login.live.com. There are others, but I think those are the ones necessary for earlier versions which auth via TWN. Even if you could set the non-SNI default to one of them, it’d break when MSN tries to hit the next domain, because it’d receive the same certificate as the previous (different domain) connection. I’m no SSL expert though, so I might be missing something.
Edit: I wonder, maybe it’s possible to change the port number? Let’s say, for example, that MSN connects to “nexus.passport.com”, that’s 18 characters, what if MSN was to try to connect to (made up example) “nexus.log1p.xyz:81”? Then, if it requests “login.passport.com”, it could hit “login.log1p.xyz:82”, and so on? I don’t know if it’s possible, or where, to change all of those different domains, but perhaps that could be a workaround for older OSs? Maybe it’s too much of a pain to try, but just some food for thought I guess.
I’m a bit confused, I believe the SNI issue was dealt with quite some time ago by making the default site on 35.185.201.91 to be the m1.escargot.log1p.xyz certificate/site. You can use MSN Messenger 7.5/escargot on XP just fine, as long as IE8 is installed (for TLS), TLS is on, SSL 2 is off and the root certs are updated, per your troubleshooting tool. And XP’s http.sys has no SNI support, regardless of IE version.
Then the next issue became the lack of a modern cipher suites that XP supports, the “best” being TLS_RSA_WITH_3DES_EDE_CBC_SHA, which wasn’t being supported by escargot/caddy at the time, but I believe valtron dealt with that, at least that’s when it started working for me and others on XP.
So I believe getting the TLS 1.0 support and the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher working on 9x would be the real issue methinks. Unless, I’ve missed something here.
I’m not sure how Escargot could work on multiple IPs (the auth service would have to contact the main server somehow to set and get auth data, which I see as impossible with my limited knowledge on server-server connections), but if it is possible, cool.
Oh, really? Apologies then, seems I’m a little behind the times, I’ve been rather busy lately so I’ve been unable to follow the project fully. Having said that, since we can’t use IE7/8 on Win98, we’re still boned
Edit: Perhaps downgrading the SSL protocol would work for 9x/2K then? I mean, that’s not a perfect solution because it’s intentionally weakening the security, but… well, something’s gonna have to be traded off to make it work, if that’s a goal that Escargot wants to hit. (Having said that, I don’t think valtron is especially bothered by the lack of compatibility that far back, so I’m just thinking out loud.)
Edit 2: Disregarding the element of historical preservation, looking at the situation purely in terms of the practicalities of running an MSN server so people can chat, I’m sure 4.7.xxxx is quite sufficient for Windows 98. Let’s face it, Windows 98 comes with its own set of issues, and nobody’s seriously running it as their everyday OS.
Weirdly enough, valtron set up the “m1.escargot.log1p.xyz” domain, along with some others, to use TLS 1.0. But he hasn’t set them up to use the “TLS_RSA_WITH_3DES_EDE_CBC_SHA” cipher yet (whew, that was a mouthful). I wonder if that’s the issue here?
When I wrote my own server I had the SSL stuff (admittedly very hackily) divided across various IPs on the same machine, which worked, and would work even on a live server, you just need a server that listens on multiple IPs (or one server listening on each IP which can communicate with the others/the database). But it would require lots of public-facing IPs to do it that way, which is expensive, so that’s not ideal. I tested briefly on Amazon EC2, and it did function, but more IPs = more fees, so the cost would really add up over time - not great, given that Escargot already runs just fine on one server, except for the issues with older OSs).
AFAIK the 9x issue is that even somewhat-strong ciphers are not supported, although I didn’t have any luck finding a source for which ones are and aren’t supported in such old Windows versions. I guess no one has cared enough (yet) about this to share that information
Well, I just spent a while trying to answer that, but unfortunately IE5 and IE6 are too crap to be capable of telling me how crap they are. I tried a bunch of online tests to get a list of supported ciphers, but both browsers are too incompatible to be able to access the test sites. I even tried some local tests, like https://demo.a-sit.at/ssl-check-clientsserver-2/, just in case it was a hosting issue, but nope, IE5/6 can’t work with that locally either. I might have another crack at it, somewhere down the line, but it’s defeated me for today I think.
It’s for NT4 SP6, but presumably if NT4 supports those then so does Win98.
Edit: Actually, that’s inspired me to take a peek inside the registry on Win98 (with IE6 installed), wherein the following ciphers are listed (though they’re not very specific, and may not be super useful on their own, I dunno, this stuff is outside of my wheelhouse):
Win98SE + IE5.01 and Win98SE + IE6 (both have the same in the registry @ HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers)
Ah, yes. I tried the same thing with IE 5.5 on a Windows 98 virtual machine. Told me that “the domain wasn’t available,” which was nothing but a COMPLETE LIE!!
Windows XP seems to have the same (well, minus a few, it’s missing the DES 40/56). One difference is that instead of Fortezza in the KeyExchangeAlgorithms, it has Diffie-Hellman.
