webone
webone copied to clipboard
atauenis
HTTPS to HTTP redirection issues in MSN Messenger
Hi,
I'm not sure if this is something that can be fixed in WebOne. I'm also sure how many other apps are affected by this issue
The app I'm trying to run makes several calls out over HTTPS, proxied through WebOne as Windows 98 is too old to support the TLS version the server is now running
However the application sees the HTTP:// response from WebOne and appends HTTPS:// to it again. Turning it into https://http://SomeWebAddress
Is there anything I can do in WebOne itself to disable this behaviour? Or am I going to need to look into patching the application itself for it
Seems that there is an incompatibility with remote server. Probably an redirection is not well fixed. Or the application don't like raw HTTP at all (like modern browsers or "HttpsAnywhere"-like plugins).
What the application is? What is writing in WebOne log? Can you give URL examples?
The application is MSN Messenger 7.0, using the "EscargotChat" server https://escargot.chat/
I'll have to set up a 98 VM and WebOne to capture the exact output it gives again.
I believe WebOne isn't the problem, as it successfully offers a HTTP version of the site MSN requests, but MSN then tries to revert it to HTTPS which causes the problem
I was able to circumvent the problem using the "oldssl-proxy" version of Squid after installing its own SSL root CA, so downgraded HTTPS connections still work
Thanks! By description it looks like a bug of MSN Messenger which probably don't support any unencrypted connections. I'll check it some time later.
Currently WebOne don't accept HTTPS connections to self, and on any attempts to get HTTPS content over proxy, it dowgrades to HTTP 1.0.
Found it is not easy to install Escargot MSN on Windows ME (I'm using it instead of Windows 98, but probably this does not matter). Only v4.6 can be installed, newer patched versions (in *.msi format) saying that the Windows Installer package is invalid. Okay, trying original MSN 4.6 with SetEscargotServer.reg patch...
23.04.2021 12:06:59 WebOne 0.10.7.0 (Win32NT-64, Runtime 3.1.10) log started.
...
23.04.2021 12:55:20.289+5000 >POST http://gateway.messenger.hotmail.com/gateway/gateway.dll?Action=open&Server=NS&IP=m1.escargot.chat (192.168.1.70)
23.04.2021 12:55:20.289+495028 >Uploading 0K of application/x-msn-messenger...
23.04.2021 12:55:20.289+1125064 Cannot load this page: NameResolutionFailure.
23.04.2021 12:55:20.289+1125064 Look in Archive.org...
23.04.2021 12:55:20.289+106206074 <Return information page: WebOne: Web Archive error..
23.04.2021 12:55:20.289+106216075 <Return information page: WebOne: NameResolutionFailure.
23.04.2021 12:55:20.289+106231076 <Done.
Then an error appearing about .NET Messenger login server not accessible.
Seems that MSN Messenger 4.6 have hard-coded http://gateway.messenger.hotmail.com/gateway/gateway.dll?Action=open&Server=NS&IP=m1.escargot.chat URL.
Trying to made a redirect which will emulate the dead Hotmail gateway.
[Edit:^http://gateway.messenger.hotmail.com]
AddInternalRedirect=https://m1.escargot.chat/
Got an better thing, but still don't work.
23.04.2021 13:03:23.340+710040 Fix to https://m1.escargot.chat/ internally
23.04.2021 13:03:23.340+735042 >Uploading 0K of application/x-msn-messenger...
23.04.2021 13:03:23.340+17240986 200 OK. Body 0K of application/octet-stream [Binary].
23.04.2021 13:03:23.340+17250987 <Done.
Going to original v5.0 and try to merge it with manually unpacked patched MSI content. Firstly started raw version just after upgrade:
23.04.2021 13:09:06.867+5000 >POST http://gateway.messenger.hotmail.com/gateway/gateway.dll?Action=open&Server=NS&IP=messenger.hotmail.com (192.168.1.70)
23.04.2021 13:09:06.867+485027 Fix to https://m1.escargot.chat/ internally
23.04.2021 13:09:06.867+485027 >Uploading 0K of application/x-msn-messenger...
23.04.2021 13:09:06.867+17886023 200 OK. Body 0K of application/octet-stream [Binary].
23.04.2021 13:09:06.867+17886023 <Done.
Similar history.
Trying to apply patch....
WHAT?! "Escargot.dll requires a newer version of Windows." Okay, going to hiew32. It really requires Windows 5.1 (XP). No problems, patching to 3.1 :) . Retry... Now requires Kernel32.dll:SetFilePointerEx function. WTF?!
Last attempt to run this shit... Trying 7.0.
Installed msn-7.0.0820-ru.exe. It shown a warning about bad characters in saved password, ignoring.
23.04.2021 13:21:57.062+425024 Fix to https://m1.escargot.chat/ internally
23.04.2021 13:21:57.062+425024 >Downloading content...
23.04.2021 13:21:57.062+15990914 200 OK. Body 0K of application/octet-stream [Binary].
23.04.2021 13:21:57.062+15995915 <Done.
And again this situation. The escargot.dll also don't run on Windows ME.
Changed password to easier... Tried again previous versions with it... Nothing helped.
@IntelMiner , how to replay the problem with https://http:// URLs step by step? Which files, system updates are need? And what requirements to Escargot account? Should be the e-mail on hotmal.com, or any other can be used too? I've registered with gmail on Escargot.
The patched MSI installer that escargot offers works on Windows XP and above, you should be able to test with that
Otherwise with 98 or ME, I used MSN 7.0 EXE installer. I installed that, then manually copied over the msnmsgr.exe msnmsgr.exe-escargot.ini and escargot.dll files
I also edited my hosts file to point at escargot's IP address for each of the hosts MSN tries to connect to
Tried WinXP SP3 (FLPC) with TSL 1.2-related updates installed (that virtual machine successfully opened all websites in 2018 in IE6).
1st attempt - MSN 3.6, 4.6. Both tries to connect, but don't accepts login/password.
2nd attempt - MSN 7.0 Escargot.
3rd attempt - MSN 5.0 Escargot. Similar.
4th attempt - MSN 7.0 Original. W/o proxy don't work at all, with proxy network check in settings window performs correctly. But I can't enter user name, as it redirects me to a .NET Passport wizard which unexpectedly ends (may be an OS-related problem).
Okay, going to WinME. It have no this wizard.
5th attempt - MSN 7.0 original, WinME. Network check is working again, also I can enter username and password, got few tens of requests to Escargot (redirected by WebOne from HotMail address)...
23.04.2021 23:01:36.970+0 >POST http://gateway.messenger.hotmail.com/gateway/gateway.dll?Action=open&Server=NS&IP=messenger.hotmail.com (192.168.1.67)
23.04.2021 23:01:36.970+615035 Fix to https://m1.escargot.chat/ internally
23.04.2021 23:01:36.970+620035 >Downloading content...
23.04.2021 23:01:36.970+3335191 200 OK. Body 0K of application/octet-stream [Binary].
23.04.2021 23:01:36.970+3335191 <Done.
...and then I've getting error 81000306.
So currently I am still can't log-in using Escargot in any way, except anything in browser (e.g. pages about change password, enable/disable old MSN and AIM support, etc).
Registered a new Escargot account with another e-mail, and have successfully logged-in using MSN 2.2 (default in WinME). Seems that there is a bug of Escargot, which has broken that account.
But on attempt to log-in using unpatched MSN 7.0 I've got endless log-in. On attempt to log-in via other versions I've also got this. Seems, Escargot have anti-bot protection or similar. Simply, don't like more then 1 login per approx. hour.
Successfully logged-in to Escargot MSN 7.0 through ProxHTTPSproxyMII on WinXP. But still can't find any place where https://http://SomeWebAddress URLs may appear if WebOne is enabled. The only which I have found, is that WebOne currently can't act as a HTTP-MSN gateway. But I am doubt that Escargot currently have properly gateway support.
Opened discussion #40 about gateway mode.
Sorry for not following up on this. The motherboard I was using to run 98 on decided to die on me
I've ordered a new one on eBay and will report back when I've got MSN 7 running again (and older versions if needed as well?)
I've been trying to reach this same outcome of making an unpatched copy of MSN 7.0 work under Windows 98 with WebOne and I've reached about the same dead ends described above. This is my rule in webone.conf:
[Edit:(^http://.*messenger\.hotmail.*\.com/)(.*)IP=messenger.hotmail.com(.*)]
AddInternalRedirect=https://msnmsgr.escargot.chat/$2IP=msnmsgr.escargot.chat$3
[Edit:(^http://.*messenger\.hotmail.*\.com/)(.*)]
AddInternalRedirect=https://msnmsgr.escargot.chat/$2
This should get you past the gateway connection, resulting in the MSN client continuously retrying the login POST until it eventually gives up. I haven't been able to get any further. I also tried to manually patch the client (doing string replacements rather than their new recommended method of using a DLL that requires XP in a lack of oversight) and the result isn't much different.
My pet theory at the moment is that after the client receives the response from the gateway (which tells it what domain endpoint to use to connect), it attempts to connect over non-HTTP protocol on a port range around 1400-1500 or somesuch, picked at random. This might not be filtered by a plain HTTP proxy such as WebOne.
I'm wondering if there's a way to make WebOne handle non-HTTP/HTTPS ports as well? It looks like using non-HTTP protocols over a HTTP proxy should be somewhat possible. However I admit I don't fully understand enough about the MSNP protocol at this time to be 100% sure that this is the issue.
This might be over 6 months old, but Escargot dev here.
First things first, MSN < 4.6 do not use HTTPS at all. It's all TCP only. If you can't login with those versions, it's because your credentials are probably wrong, or you didn't patch the client (https://escargot.chat/patcher/)
With 7.0 on your Windows ME install, you probably didn't patch it correctly either (using a binary string replace works on 7.0 but not on 7.5, did you change everything?).
Anyway, we've changed web servers since (from Caddy to nginx), maybe that issue has been fixed?
Sorry to revive this issue, just trying to make everything work :)
@Lana-chan , sorry for long answering. I've read text via e-mail notification, which wasn't contained edited portion of text (your addition to message).
I'm wondering if there's a way to make WebOne handle non-HTTP/HTTPS ports as well? It looks like using non-HTTP protocols over a HTTP proxy should be somewhat possible. However I admit I don't fully understand enough about the MSNP protocol at this time to be 100% sure that this is the issue.
Currently WebOne have no support for other protocols. I'm dreaming to add all simple protocols support (by analogy to HTTP processing inside WebOne), but this is a large work, and I don't know when I'll be able to do this. Currently only me is doing the development.
@Animadoria , thanks for reply. Currently I've lost ability to use most of my test virtual machines, but I'll plan to continue testing work of MSNP in both direct and HTTP gateway modes.
I've attempted again connecting from Windows 98 using MSN 7.0 patched using the new Escargot Patcher (which now works under 98), through WebOne proxy with the same rule I mentioned earlier.
25.01.2022 23:28:53.177+8262 >POST http://gateway.messenger.hotmail.com/gateway/gateway.dll?Action=open&Server=NS&IP=messenger.hotmail.com (192.168.0.36)
25.01.2022 23:28:53.177+537954 Fix to https://msnmsgr.escargot.chat/gateway/gateway.dll?Action=open&Server=NS&IP=msnmsgr.escargot.chat internally
25.01.2022 23:28:53.177+553090 Fix to https://msnmsgr.escargot.chat/gateway/gateway.dll?Action=open&Server=NS&IP=msnmsgr.escargot.chat internally
25.01.2022 23:28:53.177+574028 >Uploading 0K of text/xml; charset=utf-8...
25.01.2022 23:28:53.177+5350838 200 OK. Body 0K of application/x-msn-messenger [Binary].
25.01.2022 23:28:53.177+5368167 <Done.
25.01.2022 23:28:55.364+2000 >POST http://msnmsgr.escargot.chat/gateway/gateway.dll?Action=poll&SessionID=d196957d-ef9d-46d6-96e1-8c06fdc2f94e (192.168.0.36)
25.01.2022 23:28:55.364+223537 >Downloading content...
25.01.2022 23:28:55.364+1905809 200 OK. Body 0K of application/x-msn-messenger [Binary].
25.01.2022 23:28:55.364+1909110 <Done.
25.01.2022 23:28:57.382+1804 >POST http://msnmsgr.escargot.chat/gateway/gateway.dll?Action=poll&SessionID=d196957d-ef9d-46d6-96e1-8c06fdc2f94e (192.168.0.36)
25.01.2022 23:28:57.382+220039 >Downloading content...
25.01.2022 23:28:57.382+1824012 200 OK. Body 0K of application/x-msn-messenger [Binary].
25.01.2022 23:28:57.382+1826572 <Done.
25.01.2022 23:28:59.432+1633 >POST http://msnmsgr.escargot.chat/gateway/gateway.dll?Action=poll&SessionID=d196957d-ef9d-46d6-96e1-8c06fdc2f94e (192.168.0.36)
25.01.2022 23:28:59.432+189140 >Downloading content...
25.01.2022 23:28:59.432+1672711 200 OK. Body 0K of application/x-msn-messenger [Binary].
25.01.2022 23:28:59.432+1675862 <Done.
The application/x-msn-messenger responses keep repeating forever for about a minute or so until the client finally gives up. (this might just still be the issue with WebOne not supporting Keep-Alive)
EDIT: Looks like the Patcher didn't actually patch Windows 98 MSN 7.0, so I did it manually. Now it actually tells me in the connection test that it can find the server and I can access MSN services, but trying it without WebOne still results in a (different) login failure. Trying to load https://msnmsgr.escargot.chat in RetroZilla correctly returns 405 method not allowed, but the same URL in IE6 does not resolve to an https connection, which leads me to believe the new server still doesn't support anything older than TLS 1.2.
EDIT 2: I tried forcing TLS v1.0 with cURL on a modern linux box and the escargot server seems to reply gracefully. Not sure then why my 98 box refuses to connect with IE6.
EDIT 3: Dug around a bit more, matter of fact is that the Escargot servers, while supporting TLS1.0, do not support the only ciphers available in Windows 9x SCHANNEL, which are all outdated and considered insecure today. Re-enabling the weak OpenSSL ciphers RC4-SHA (128-bit) or DES-CBC3-SHA (168-bit) should allow HTTPS connection from 98 IE6 clients, but I'm not sure that's possible without building nginx with the specific option for weak ciphers. The other option is to wait until WebOne supports Keep-Alive.
Hi team,
I've not had time to get my 98 machine running again unfortunately. However some other friends have mentioned success with an unrelated project https://bitbucket.org/ValdikSS/oldssl-proxy
@Lana-chan Perhaps this could be the "missing link" you're after? It's a Docker container that provides a Squid SSL downgrade function
Seems that this was a Keep-Alive related problem. Now when WebOne got Keep-Alive connection support, it became solved: https://github.com/atauenis/webone/discussions/40#discussioncomment-3550739