2

We are trying to make a connection to a other service for my company and the webservice is hosted over a VPN on port 444 with SSL. I am just wondering why you should NOT want to use the standarized port for SSL, 443. Of course it's theoretically possible to host SSL/HTTP communication over any port other than 443 but I don't see a reason to do it.

The only reason I can imagine is that your webservices are routed based on the port number. So 443 goes to internal application X and 444 goes to internal application.

Can somebody give me some insights?

3
  • "theoretical possible"? I see this all the time. Using 443 just means https will default to that. You don't have to explicitly specify the port.
    – JimmyJames
    Commented Aug 24, 2016 at 15:24
  • @JimmyJames what are u saying? In practise there are few people who not implement https on a port that is not 443. Espacially when you serve website. Commented Aug 26, 2016 at 16:57
  • I'm just saying it's not just 'theoretically possible' or even just 'possible'. I've seen it done in multiple occasions. I'm not saying you should do it, just that it's not really that interesting. If you want people to be able to find your website easily, then you should probably use 443. If you don't care or don't want it to be easy, then you might use something else. As far as security goes, this isn't going to dissuade anyone who's motivated.
    – JimmyJames
    Commented Aug 26, 2016 at 17:20

2 Answers 2

3

There are several potential reasons:

  • Something's already running on 443 and the two services would conflict
    • For example, Splunk's log agent runs a local "web server"; they run it up around 9998/tcp to avoid conflict with a "real" web service on that host
  • The service is not a "web server" and the owner doesn't want it treated that way
    • Non-HTTP like IMAPS or POP3S
    • RESTful API with non-browser-renderable output
  • The service lacks root privileges required for a Unix privileged port (nod @Josef)
  • The owner perceives there is added security via the obscurity of running on an alternate port

None of these are solid security reasons (although some are quite reasonable architectural considerations). If you want security, use a firewall to limit access and/or robust authentication and/or a WAF.

1
  • The minor reason people run on non standard port is usually to avoid brute force attempts from swamping logfiles, but inside a VPN, this probably isn't much of an issue.
    – Lie Ryan
    Commented Aug 24, 2016 at 15:19
3

The usual reason to use something else than a well-known port is to reduce the attack surface by eluding scans of well-know ports.

Here if the port 443 is not open some 'bot scans' will consider there's no https access possible and won't try their usual attacks on this system.

This is the same reason for not answering ICMP requests publicly.

2
  • Another reason is that on Unix systems normal users usually can't start listening services on ports lower than 1024. That's obviously not the case here because 444 is also below 1024, but it general it is one reason why different ports are used.
    – Josef
    Commented Aug 24, 2016 at 13:04
  • That's a real case, but authbind and other tricks are existing for this purpose, so it's usually not the reason to change the ports. I assume here the question is about the security reasons which would drive this choice, not the technical ones. If so this Q should be moved to superuser or unix SE site.
    – Tensibai
    Commented Aug 24, 2016 at 13:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .