Score:1

Is it possible to only allow HTTPS and block HTTP on a arbitrary port

in flag

We are using RHEL and we have to open one non-privileged and arbitrary port, say, port 12345, to an ordinary user. This ordinary user needs to run an HTTP service listening on this port and every computer within the LAN network can access the service. Given the nature of the service the user needs to run, reverse proxy is unlikely to work and the user's service has to directly listen on the port and serve its clients.

We want to force the user to secure its service with an SSL certificate but currently we don't have a good way to do so from a technical aspect. (Currently, all we do now is keep reminding the user to properly configure HTTPS himself.)

The question is, would it be possible for a sysadmin to force a port to serve HTTPS content only and suppose the user uses plain HTTP (either knowingly or unknowingly), the traffic will be blocked?

Usually I do this with a reverse proxy--internal services listen on localhost only and a dedicated HTTP server program such as Apache is used to handle the SSL part. This approach does not work easily this time since the web service is pretty complicated (I suppose it might work with some equally complicated rewrite rules) so I am wondering if there is another simpler approach.

Thanks!

djdomi avatar
za flag
please provide the used firewall appliance
Alex Kong avatar
in flag
what do you mean by firewall appliance @djdomi ? This is a standalone RHEL server. If you mean firewall program, currently we are using firewalld but we are open to any other programs if it is needed.
Alex avatar
us flag
If the users are using these ports, I imagine they start some daemon or run some app / script that actually starts the web server. Is it possible to rewrite this script that is provided to the users in a way that only HTTPS connections are accepted? Or, if the script configures some web server (e.g. Apache) - again, you can either block HTTP completely, or establish a redirect to HTTPS on Apache level... Would that be possible? Please share some details about how the users launch the web server, maybe the community will suggest something.
Alex Kong avatar
in flag
Hi @Alex, the issue is, I don't want to assume that users always follow our standard--since we open a port to them, it is possible that they just skip my script and use their own scripts (which use HTTP). Therefore, what I want to have is something similar to a firewall which can ban this. Regarding using Apache, it seems to me that this could be pretty difficult to set--the script users are going to use has its own redirect/port/relative url/etc settings. Do you think there is still a simple way to use Apache?
Alex avatar
us flag
No, if users can create their own scripts and change Apache configuration, then my approach would not work I guess. I assumed either all the users have one common script they run, or they all use Apache with default site, so it can be freezed on system level. If everyone's using Apache, it might (might not!) be possible to create a global rewrite rule for all sites that will force HTTP to HTTPS, and revoke write access to that Apache config file. This option just seems easier to explore compared to inspecting all the traffic and blocking it on the fly - that's a task for WAF, or at least NGFW.
Alex Kong avatar
in flag
Hi @Alex, perhaps I did not make myself clear. "users can create their own scripts" -> This is correct; "users can change Apache configuration" -> no they canNOT change Apache settings. But currently Apache is not used--users just use their scripts to listen on a given port. The reason Apache is not used is that I failed to figure out a way to make all scripts compatible with Apache's reverse proxy...
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.