HSTS on Jamf Pro - why?

[user-dIrrpGXxza]

So we know that JAMF recommends to enable HSTS on Jamf Pro on-prem instances. However, I find the article lacking in several aspects.

If we start with what I'm most curious about - Why? For instance, these specific questions come to mind:

* If HSTS isn't enabled, can the MDM connection be downgraded to HTTP when the device is already enrolled, and thus can the device be tricked into executing MDM commands on either a HTTP session or a HTTPS session with an invalid certificate? Is the user prompted in this case and can the user choose to continue?

* Is the HSTS recommendation meant or administrative access only instead?

* Is the HSTS recommendation there to prevent MITM attacks for initial enrollment only? Or a combination of that and administrative access? In essence, describe the risks if it isn't enabled in a JAMF pro specific scenario.

* Are there any downsides or pitfalls when enabling HSTS? A far-fetched thing would be that it automatically also enables certificate pinning so that an unexpected change of JAMF pro's SSL certificate would lock out devices even though the new certificate is valid?

* What problems/risks does it solve specific for JAMF pro in addition to the questions listed above?

In addition to the above, the article seems to be a bit misleading. I assume most of us who run JAMF on-prem have more than one tomcat server running? And that those have a load balancer in front of them? In that case, HSTS headers should be set by whatever LB that's in front, right? And tomcat needs no change if the back-end communication is HTTP? Perhaps a few example configs for common load balancers such as KEMP, apache mod_proxy and F5 would be appropriate - or at least a clarification that you need to figure out how to implement this properly for your Vendor X LB product? Also list if it's really recommended to enable this for all sub-domains as well (I doubt it, at least if you have plenty of other hosts in the same DNS domain). A recommended lifetime would also be appropriate.

[foobarfoo]

Well, since no-one replied, I can partially answer my own question. While we don't see any particular attack vector for HSTS other than for web-based JAMF admin traffic, we decided to go ahead and implement this anyway, but leave out the activation for subdomains.

While we were at it, we also decided to strengthen the SSL implementation in addition to HSTS. So we also added priorities for the crypto alorithms used. We use apache httpd with mod_proxy as a LB. In the end, we added the following - I hope it may be of use to someone in the future:

Virtual host:
Header always set Strict-Transport-Security "max-age=63072000"

SSL config:
SSLCipherSuite HIGH:!MEDIUM:!aNULL:!MD5:!RC4

[jake_pederson]

Thanks for the questions and feedback on the HSTS article, hopefully I can provide some clarity. We will look into making some modifications to the article as well.

To answer your question as to “why?”, ultimately, the HSTS header provides a way for websites to instruct browsers to only communicate via HTTPS. After receiving a HSTS header over HTTPS, an attempt by the user to initiate an HTTP connection will be stopped by the browser and redirected via HTTPS, thus preventing any traffic from leaving the device that isn’t over HTTPS, going to the server in question. The Mozilla article does a pretty good job of explaining the details. HSTS does not prevent HTTP communication from happening, it would be trivial to use cURL or some other tool to initiate HTTP communication. It is really just an agreement that the browser will respect the instructions from the website to only communicate via HTTPS.

Now, to answer your specific questions:

If HSTS isn't enabled, can the MDM connection be downgraded to HTTP when the device is already enrolled, and thus can the device be tricked into executing MDM commands on either a HTTP session or a HTTPS session with an invalid certificate? Is the user prompted in this case and can the user choose to continue?

MDM communication is dictated by the URL that is in the MDM Profile on the device, if that URL specifies HTTPS, then the devices will always use HTTPS to communicate with Jamf Pro, it cannot be downgraded to HTTP. Whether the HTTPS connection can be spoofed with another certificate is a different question, but generally, no, that’s why we use certificates, they’re very difficult to circumvent and ensure the two parties involved are who they say they are.

Is the HSTS recommendation meant or administrative access only instead?

Jamf Pro will include the HSTS header in the response for any HTTPS connection but it is up to the client receiving that response to take action. Whether or not macOS or iOS support the HSTS header for MDM communication really doesn’t matter, the URL in the MDM profile defines the communication channel. The Jamf Management Framework on macOS devices also uses the URL in the MDM profile during enrollment and then is saved in a preference file. The HSTS header is mostly for in-browser communication and as such, mainly protects interactions with the Jamf Pro UI, which is what I’m assuming you mean by “administrative access”.

Is the HSTS recommendation there to prevent MITM attacks for initial enrollment only? Or a combination of that and administrative access? In essence, describe the risks if it isn't enabled in a JAMF pro specific scenario.

Correct, the main purpose of the HSTS header is to prevent MITM attacks. This applies to any communication channel that occurs over HTTPS at any time, once a client connects to Jamf Pro over HTTPS the first time, that header directs the client to only ever communicate with this domain via HTTPS. Again, it is an agreement on the part of the client to respect the instruction from the website to only communicate via HTTPS in the future. The risk of not enabling HSTS would be a MITM attack against your Jamf Pro domain if you were to browse to it via HTTP, for example if you clicked a spear-phishing link to your Jamf Pro domain while on a compromised network, or you had the HTTP domain linked in a bookmark in your browser.

Are there any downsides or pitfalls when enabling HSTS? A far-fetched thing would be that it automatically also enables certificate pinning so that an unexpected change of JAMF pro's SSL certificate would lock out devices even though the new certificate is valid?

Certification pinning is a different feature that could be implemented, but is in no way affected by enabling HSTS. There is very little risk of enabling HSTS unless you have a workflow that requires HTTP communication on occasion via a browser or client that supports HSTS (cannot think of a workflow that would require this). However, if for example, you have a workflow that requires API communication via HTTP only, as long as the client you’re using to initiate that communication doesn’t respect the HSTS header AND/OR does not at any point initiate communication via HTTPS, it will continue to work perfectly fine.

What problems/risks does it solve specific for JAMF pro in addition to the questions listed above?

None. This strictly relates to how clients interact with Jamf Pro via HTTPS, instructing them to only use HTTPS once they have connected via HTTPS at least once. All the other security measures we have in place should still be used and HSTS is not a replacement for any of them, including HTTP -> HTTPS redirects on the server side.

As far as load balancers go, you are correct, the HSTS header would be set by the load balancer and not in any of the tomcat servers. Load balancers are all unique and varied, and their configurations and settings are complex and specific to the environment they are running in. We don’t feel it would improve the article to add examples for any load balancer products because our documentation is specific to Jamf Pro, if you wish to enable HSTS on your load balancer, please refer to your load balancer’s documentation.

Cheers!

-Jake from Engineering

[foobarfoo]

Thank you so much for that very detailed response! I'd sum it up as the following TLDR for others:

HSTS is just to protect your admins that are sloppy with checking which links they access, and if they're HTTP or HTTPS. But it does no harm unless you add the optional option of protecting subdomains as well that may use HTTP - but if you're on the jamfcloud.com domain that isn't an issue.

And completely unrelated, great that you're here, always glad to see someone from engineering taking part in the real world issues and challenges! Would 5x kudo if I could just for that. :)