Firestorm SOCKS5 Win 11 (and presumably 10)

[beqjanus]

Hi,
I'm a dev on Firestorm.
I'd not noticed the the proxy was broken until I read the notes here and followed the link to the Jira. There is an associated Jira on the FS system too.

It is rather odd, I can confirm that the behaviour remains as per the Jira as of this latest (pre)release (6.6.8) however, running the viewer in a debugger had no issues and the proxy worked fine. This suggests the code is mostly fine and we're looking for some kind of race condition or more likely just some uninitialised variable or something odd. I'll have a closer look at it when I get a chance. In the meantime, if you have noticed anything odd about the behaviour of the proxy code please let me know as it might help short-circuit that investigation.

Beq

[SaladDais]

Hi Beq, thanks for looking into this!

running the viewer in a debugger had no issues and the proxy worked fine

Interesting! I don't have a viewer dev setup under Windows (and I don't have a proper Windows install anymore,) so I'd never tried a viewer compiled in debug mode.

If the in-viewer SOCKS5 proxy setting works under debug mode, then I believe your speculation about it being a race condition is correct. What I'd observed when looking at Windows viewers' SOCKS5 handshakes in Wireshark was that either the SOCKS5 handshake or UDP ASSOCIATE response (I forget which) would be sent by the proxy, but the viewer would close the socket a fraction of a second before receiving the reply from the proxy.

It's entirely possible that the SOCKS5 proxy code does work under release mode, so long as the SOCKS5 proxy it connects to responds within an extremely short timeframe. Hippolyzer is unusual for a SOCKS5 proxy in that it's written in Python (extra latency!) and that it does extra bookkeeping before responding that most SOCKS5 proxies would not do (even more latency!) I don't recall if it was the initial connect or the read that was timing out, but I can look for my old pcaps if it'd help debug.

if you have noticed anything odd about the behaviour of the proxy code please let me know as it might help short-circuit that investigation

There're a lot of smells in the viewer's SOCKS5 code, unfortunately. If I had to guess, this issue's probably something to do with llproxy.cpp:tcp_blocking_handshake(), maybe the blocking timeout is set too short? It's 0.01 seconds at the moment. LL added an explicit ms_sleep() in there in 2019 to deal with previous breakage, looks pretty fragile.

[beqjanus]

Yep, we both had the same thought. The timeout was 1ms and the extra sleep pretty kludgy. I have made it 100ms on the timeout (and removed the pointless sleep). There's no good reason for keeping it so short, especially if it is expected to work with non-localhost.

I have committed a fix and confirmed that Hippolyzer works happily now with OpenSim. I am getting cert errors on second life logins though so I need to work out what is happening there.

[beqjanus]

I'm not convinced I have fixed the thing; maybe just moved it forward a bit. It seems more reliable but there's still something odd going on.

[SaladDais]

I have committed a fix and confirmed that Hippolyzer works happily now with OpenSim.

Awesome!

I am getting cert errors on second life logins though so I need to work out what is happening there.

Hmmm, I'm guessing the OpenSim grids you tested on don't use HTTPS for logins or caps? That's the only reason I can think of that OS would work and SL wouldn't.

If you've already done the cert installation process via Hippolyzer's File -> Install HTTPS Cert, there's a couple of things that it might be:

1. The viewer may be looking for the "custom" CA certificate somewhere other than where Hippolyzer tried to install it. The viewer looks for a "CA.pem" in the user settings dir, and adds it to its TLS trust store if present. Hippolyzer tries to find all viewer user settings dirs in the user's home directory (or user profile in Windows) and stuffs its ~/.mitmproxy/mitmproxy-ca-cert.pem in there as CA.pem. All this logic is in ca_utils.py. If the user settings dir for your current viewer lives somewhere weird, you may need to manually copy the certificate over.
2. The viewer may have changed how it validates TLS certificates, which was wonky even by 2000s standards (checking CN rather than SANs, odd usage of Subject Key ID, etc.) Hippolyzer hacks up mitmproxy's built-in TLS cert generation to generate ones of the same form as LL's simservers use. Hopefully that's not the issue.

I'm not convinced I have fixed the thing; maybe just moved it forward a bit. It seems more reliable but there's still something odd going on.

Yeah, I don't know why exactly this only an issue under Windows and not Linux or OSX. I've noticed that the connection attempt will block forever if you specify a remote address that doesn't have a proxy listening under Linux, so the timeout behavior may be totally different depending on the OS.

[SaladDais]

FYI, there's now an option to disable upstream SSL authentication under the "File > Allow Insecure SSL Connections" menu. Worst-case, if you weren't able to get SSL working, you could enable that, then set NoVerifySSLCerts to 1 in the viewer, then restart. The in-viewer browser may still complain, but it should mostly work.

[bennettgoble]

@beqjanus @SaladDais --a similar fix has been opened against the viewer upstream here, secondlife/viewer#1092.