Is it safe to serve HTTP/HTTPS over ports 8080/8443

Question

Due to an infrastructure limitation, one of the proposed solutions for serving an HTTP service to the world is to offer it over ports 8080 and 8443.

My concern is that some users may not be able to access these services because they are not running on standard ports, and the content might be filtered by (for instance) as part of the corporate network policy.

So... how likely is it that a user from the internet at large might not be able to access these services?

Solution 1

Corporate networks will usually be defaulted to rules like this:

deny all; allow 80; allow 443; allow 21; allow 22; etc...

It is much easier to configure this way rather than to explicitly deny 99% of the 65,535 available ports.

With that said, I took over a client-facing portal which used a non-standard port due to network limitations; I do not know the NAT details. Anyways, this made it impossible for about 50% of our users/visitors to access site and whenever they would call us to report this issue, we would have to coordinate with their non-existent IT to try and get an allow rule implemented.

---

I do not know the details of your infrastructure limitations but I would imagine that something else is running on 80/443

If this is the case then your only shot might be to use an internal proxy or upgrade the switch to something with more advanced NAT capabilities which can route the requests appropriately.

---

TL;DR

Don't use a non-standard port for public-facing services which already have a standard port.

Solution 2

It is very likely those will be blocked, especially in corporate networks or on public wifi. Less likely on a regular home internet connection.

It would certainly be blocked on my work network.

In addition, people will have to remember to type the port number to get to your site, which is an extra headache you don't want to deal with. For internal or private sites its not a big problem but if this is for the general public you will have a lot more success using the standard ports.

Solution 3

Its not hard to make your browser hit say http://example.com:8080/index.html, but when you talk about corporate policies blocking non standard ports that seems mighty difficult.

If you have some sort of Load balancing set up, you can still set up your applications to run on a standard port and have the load balancer port forward to the odd port internally. Even if you don't have load balancing, I'm sure you can find a way to port forward to an internal port that is non standard.

Internally, users could access on an odd port (if not part of your corporate policy to block ), externally they see http://example.com.

There are many ways to do this, you'll have to get a little creative depending on the types of roadblocks you encounter. Its always a challenge!

Comments

[Froggiz]

can't you proxy the adress to port 80 & 443 ?

[spender]

We're using Web and Worker roles in Azure Cloud services. As far as I can tell, it's not possible to point a second VIP at a different machine unless we switch to Azure VMs. Other options include replacing the entire front-end webserver with a proxy, but obviously using different ports would solve this problem with less expense.

[Froggiz]

i mean like that : azure.microsoft.com/en-us/documentation/articles/…

[Nathan Osman]

I'd like to address a concern that seems to be missing here. The fact that you cannot use ports 80 or 443 might suggest that you are running on a shared server. If so, the possibility exists that another user could bind to those ports if yours ever stopped working. That user could then impersonate your website (though SSL could help mitigate this).

[Pacerier]

@NathanOsman, I think he's worried about user access and user firewalls.

[spender]

@NathanOsman To be clear, the limitation I faced was a single public IP address from which I wanted to serve data from two different webservers. This is a limitation of Azure (classic) Cloud Services and was avoided by using one of the webservers to proxy a small number of actions/routes through to the second.

[spender]

The services in question are never typed into the browser... rather they are pointed to from resources served over the normal ports. It seems, however, that my concerns about the reliability of my approach are well justified.

[Froggiz]

can you explain why it would be blocked ? i used port 800 for long time without any trouble even with google SEO tools and referencing..

[spender]

One of my jobs is running a website that indexes shoutcast streams, and it's a common complaint that some users behind corporate networks can't listen to streams that are running over non-standard ports. However, 8080 and 8443 seem to be a bit special, but probably not special enough. I'd say that running a service on 800 is particularly risky because it falls under "well-known" ports that are considerably more likely to be blocked.

[SnakeDoc]

@MonkeyZeus In that case, OP will need to do URL String matching and forward based on the requested URL path. Ya, it gets dirtier the more trickery required to make it work.

[MonkeyZeus]

@SnakeDoc Agreed, I covered the proxy option in my answer :-)

[user253751]

"It is much easier to configure this way rather than to explicitly deny 99% of the 65,535 available ports." - even if they did explicitly deny 99% of the ports it would have the same effect.

[spender]

We ended up using the main webserver to proxy requests to the services offered on other ports. Because the other services need to scale for additional processing power rather than because they hit network limits, and the size of requests and responses is relatively low, this arrangement works very nicely with the main load-balanced website easily absorbing the cost of proxying.

[MonkeyZeus]

@spender I'm glad to hear you guys were able to work it out without using client-facing non-standard ports :)