Xojo Web App and S-HTTP detected

Hello, I have a stand-alone web application Xojo 2025R2.1 running as a service on a (intranet only) Windows Server 2022 on port 9101.

These are the only startup parameters I’m defining, everything else are the defaults.
c:\WebApps\mycbord\App\mycbord.exe --port=9101 --maxsockets=400

I’m using Windows IIS on the same server with an internally signed certificate and setup a website connection on SSL port 9100 with a reverse proxy and localhost connection defined to the Xojo web app on port 9101.

This is working fine, no issues, my test users are connecting to the https IIS url on port 9100 and the Xojo web app is working as expected.

Our internal security team did a vulnerability assessment of my Xojo application and detected the older S-HTTP protocol enabled on port 9101 (Xojo web app).

Is this because I’ve left the SSLType parameter at the default setting (TLSv12)?

Should I change that to SSLv3, even though I’m not going to setup and communicate on a secure port with the Xojo web app?

Thanks for any help.

If it’s running behind a proxy server (IIS in your case), it doesn’t really matter the port. It can even be plain old http (80). What matters is IIS. Just make sure port 9101 is not accessible from outside.

Hi Mark,

Something feels off here. I’m pretty darn sure the secure port and the non-secure port cannot be the same port.

So either you’re using port 9101 as the secure port or the test is giving a false positive?

From a browser running on the server, what happens if you try and browse to: https://127.0.0.1:9101 ?

If you get a self-signed certificate warning from the browser (or just connect if a cert is is place), then 9101 is the secure port.

If the browser times out, then port 9101 is using HTTP, not HTTPS and the test is giving an erroneous result, maybe??

Anthony

Thanks Gabriel and Anthony, I agree that since the app is running behind a reverse proxy in a intranet environment the risk is low even with the app running on an http port.

When I try https://127.0.0.1:9101 locally on the server it is comes back with page can’t be reached. Port 9100 is definitely the secured port, and port 9101 is using http. I think the security test is somehow still seeing s-http enabled on port 9101, but I’m not using that protocol to communicate with, therefore I just need to re-explain to them how this setup is working. Thanks.

Set up a firewall on the server so that the app is inaccessible from the outside. With the only way to access your app being through IIS, your security team can take up any issues with Microsoft.

Thanks Tim, good point, lockout port 9101 from any access outside of the server.

I’d be curious what they did to detect that, and what threat level they give for it.

My recollection is that the Xojo socket uses the fallback setting, meaning that it will start with TLSv3 and fall back to older protocols as necessary so yes, it could report support for an older protocol, but I think an attacker would be hard pressed to cause an exploit in this case.

I did a quick search. I can tell you that Xojo apps do not support S-HTTP and never did. The only security protocols used by Xojo were SSLv2 and v3 (both gone now) and TLSv1 through TLSv1.3. None of these protocols are used in S-HTTP and as far as I can see, IIS doesn’t use it either.

So either this is a false positive or their test is wrong.

Excellent thanks Greg for confirming, I’ll find out what tool they used to detect this, and let you know.

Hi @Greg_O the S-HTTP threat was considered a medium level, and the tool used was Greenbone. Our security team agrees now that it’s most likely a false positive.

Thanks again for everyone’s responses.

2 Likes