kernelEx is outrageously outdated and doesnt run anything modern.
you are wrong
then how do i run firefox 52 (xp) in windows 98? kernelex doesnt let that.
the oldest version that runs firefox 45 is 2000, 45 still works with modern web
kernelex works in 98 ? cool
lmao, it works in 98 and ME only.
But the last version of Firefox supported by Windows 2000 was not 3.x?
No, it can run up to version 11.0.0 and some 12.x betas
and according to an user in the mozilla forums, it runs up to 28.0.
tl;dr - You’re stuck with 4.7.0106 and older.
The latest version that works with both Windows 98 and Escargot, as far as I’ve tested, is 4.7.0106.
Versions up to 7.0.0820 will run on Windows 98 but due to protocol requirements (TWN authentication used in newer protocols requires particular SSL compatibility) they cannot connect to Escargot. This is due to the way that Escargot handles SSL certificates across multiple domains, which is different to how Microsoft used to handle it.
Additional: According to my notes on the Escargot wiki, versions up to 5.0.0340 do still optionally support MD5 authentication, so if you were able to force them to log in using MSNP7 instead of the newer MSNP8 (which requires SSL) then you may be able to use those. Be aware that they’re pre-release versions, however, and if you’re concerned about security then they won’t help you fix that.
WINDOWS MESSENGER 4.7 DONT WORK IN WINDOWS 8 #ILOVECAPSLOCK Body seems unclear, is it a complete sentence?
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.
Out of curiosity, how did Microsoft emulate SSL for Win9X compatibility?
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 126.96.36.199 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.
Can't sign in with MSN versions 5 - 7 on Windows 2000
Next windows live messenger for xp
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).