Hello Team,
We have a use case implementing BigFix for a Customer.
Here customer is not allowing download on Port 80 and just allowing 443 downloads.
We have already enabled https download to 2 . for site gathers,
Patches for windows have the http URL, but as port 80 is not allowed for patch Download in that is there any way we can redirect bigfix to download the patch on https?
Because it will be very difficult to change the url to https every time before patching.
The downloads do not take place on the endpoints, they take place on the BigFix server and are passed down through the relays to the endpoint (Unless otherwise configured, direct download) via the agent/relay/server relationship. If you have enhanced security on, this path from the BigFix Server to the endpoints is encrypted.
So what restrictions they have in their environment should not impact the download of patches unless the BigFix Server itself has those same restrictions.
There is also security built into the downloads to the server, this being the comparison of the sha values.
There are a few exceptions to the download path through the server, Microsoft Click to Run (C2R) versions of office actually pull the patches directly from the Office Update Sites, they do not run the patch from BigFix Server to Relay to Endpoint. This is because BigFix does not actually install the patch, the updater for C2R and them monitors to see if the version of office installed changes to the new version.
Hello Dean,
The download is happening on the root server not on the endpoints.
And the http download limitations are applied there.
This should help you then…
https://help.hcltechsw.com/bigfix/9.5/platform/Platform/Config/c_https_gathering.html
Hello Dean,
We already enabled this one but this is not changing the fixlets url to download the patches to https.
Still directing the http download which is blocked and the problem statement.
There’s nothing you can adjust for this. BigFix downloads in the protocol listed in the content.
You can submit an Idea for this, but in some cases it may be limited to how the vendor makes the content available, or how they publish their catalog.
I am having a similar issue. There has been a policy change for us where some http downloads are now being blocked apparently. I have been seeing this for the last couple months when trying to pre-cache Windows updates. Similarly, last month I set the https_gathering option thinking it would solve my issue this month but it didn’t.
Hello, BigFix team is aware of the issues related to HTTP vs HTTPS in the prefetch statements. This applies to situations like the ones described here, as well as cases where Microsoft removed the HTTP URLs.
We are working to modify the existing fixlets in order to use, where available, the HTTPS URLs. This is a huge task that we are performing over time in batches.
At the same time, in an upcoming platform release, we will introduce a behavior whereby attempts will be made to use both the HTTPS and the HTTPS URLs for the prefetch.
Hope it helps.
I’m wondering that even new fixlets, eg. update notepad++ from Windows Application site (which I really like!) are being released using http link.
With BigFix platform 10.0.8+, http call redirection is followed; if the destination is HTTPS, the connection will be validated with certificate before the download actually happens.
This does not address the case where HTTP calls are blocked in the network (in which case they do not reach the destination server, so no redirection happens.
In this latter case, currently you can either manually pre-cache the content on the Root Server, or change the actionscript to use the https address in place of http.
BigFix will work going forward so that https URLs are used where available.
Just to add, until / if the BES Server platform adds functionality to force HTTPS for all downloads … if your customer is blocking all HTTP, they should consider using their proxy server to rewrite the URLs to HTTPS.
I’d expect all the major proxy vendors to support that functionality. Configure the proxy server, then configure BigFix to use your proxy and let the proxy handle converting to HTTPs.
I haven’t tried it myself, but this example of configuring the Squid proxy server may be helpful https://serverfault.com/questions/907490/forward-proxy-convert-http-to-https