JSS - TCP 8443 vs 443

[UESCDurandal]

Hey there,

I'm just curious if someone could outline the pros/cons of running your JSS under TCP 8443 vs. 443? Is there a good reason why default installations use 8443 instead of 443?

[mscottblake · Accepted solution]

8443 is the default port for Tomcat. There is not benefit to leaving it that way.

[mike_paul · Accepted solution]

@mscottblake is correct, it is the default https port used by Tomcat. I just want to point out that the port is part of the URL that devices are enrolled to so you cant go and just change the port if you already have devices enrolled as it would break both Jamf and MDM communication. There are some complicated workarounds by typically changing ports/url would require re-enrolling devices.

[mscottblake · Accepted solution]

8443 is the default port for Tomcat. There is not benefit to leaving it that way.

[mike_paul · Accepted solution]

@mscottblake is correct, it is the default https port used by Tomcat. I just want to point out that the port is part of the URL that devices are enrolled to so you cant go and just change the port if you already have devices enrolled as it would break both Jamf and MDM communication. There are some complicated workarounds by typically changing ports/url would require re-enrolling devices.

[blackholemac · Accepted solution]

This one is all answered and @mike.paul synthesizes two of my thoughts on the subject perfectly...changing the port is like changing the enrolled URL...you don't want to do that without a bonafide plan to re-enroll.

If you are hypothetically working in a never been deployed world, you could use either 8443 or 443. There are very small pros and cons to choosing one over the other.

Pros for 8443:

some third party written scripts and apps assume that most Jamf Pro users are using 8443 as that is what most deployments used. Well written ones such as the MUT or other similar caliber scripts don't assume much...they have the end user define the entire Jamf Pro URL.

8443 is less known of a port so you get a very tiny amount of "security by obscurity"...in other words some random bonehead who happened to know the Jamf Pro URL, but not which port it operates on could try to hit the web site and get told there's nothing there. That's really nothing to rest on though as it doesn't take much to figure out that most Tomcat installs run on 8443 as opposed to 443.

Cons for 8443:

Many firewall rules are written to be nice to 443 traffic going out...if you use 8443, that may be another rule needed at the firewall or web filtering level.

A lot of times 443 is assumed when connecting to a URL (again that could be good or bad).

In short if your server is setup right, it doesn't really matter...for instance a JamfCloud instance by default uses 443. If you install on premises, the installer assumes 8443. easily customizable.

[blinvisible]

Alternately, you could leave Tomcat on 8443 but proxy it behind port 443 with some other web server, as this ancient post of mine illustrates.

https://www.jamf.com/jamf-nation/discussions/8378/experience-with-jss-and-mod_proxy_ajp-or-something...

You could also use something else (such as HAProxy or Nginx) instead of Apache if that's where your expertise lies. For us it was more of a familiarity with Apache than anything else:
- We feel better about Apache httpd since it has been around longer than Tomcat and is thoroughly battle-tested (although as time goes on this difference becomes less relevant).
- We have a much better understanding of the attack surface of Apache httpd vs. Tomcat, and know how to disable un-needed functions.
- If a security problem within Tomcat or Jamf were to arise, we feel much more comfortable defending it (or other web applications) using Apache methods (such as mod_rewrite or mod_security) than by Tomcat methods (such as writing ServletFilters).

Something to consider if your Jamf server is exposed to the Internet.