FOG 1.5.6 Officially Released

[george1421]

@Sebastian-Roth said in FOG 1.5.6 Officially Released:

Should FOG install as SSL by default?

SSL between FOG Client and fog server yes. SSL between fog webui and IT management station ~. One of the things we are seeing with modern web browsers is that they are not liking self signed certificates. So every site you go to that has a self signed certificate you get the warning and have to click through a few screens to get to the site that employs a self signed certificate. Now if fog could use one of those fee root traceable ssl certificates (like from lets encrypt) and then created the FOG SSL certificate using that then the IT admins would not get the browser nag messages. If fog did implement http ssl, would there also be value in ftps for ftp communications?

Beyond SSL there are a few things that FOG developers could do it improve FOG’s security stance (i.e. mysql, secure password, firewall, etc).

[Wayne Workman]

@george1421 said in FOG 1.5.6 Officially Released:

Now if fog could use one of those fee root traceable ssl certificates (like from lets encrypt) and then created the FOG SSL certificate using that then the IT admins would not get the browser nag messages.

using Let’s Encrypt for FOG installation wouldn’t work in >98% of cases because those fog servers are not open to inbound traffic from the internet. They couldn’t pass the DNS http challenge/response.

Mostly, FOG is used at universities and public school districts. While I can see a university maybe already having a self-signed cert installed in the OS’s trust store, it’s not my experience or observation that public schools do this. While I’m 100% fully on-board with end-to-end encryption all the time everywhere, I feel it’d only be an unwanted hurdle to jump for most FOG users that are just trying to get some computers imaged.

Perhaps it could be made easier to setup SSL, rather than forcing it? Perhaps make it optional, and defaulting to ‘no’.

At any rate, this is just my 2 cents.

[Sebastian Roth]

@george1421 @Wayne-Workman Thanks for your thoughts on this! Definitely helpful to get some more inspiration on this topic.

I guess we need to distinguish between different communications when talking about SSL. As George mentioned there are two (or actually three) different things communicating, one fog-client to FOG server, the other one IT admin web browser to FOG web UI and as third communicator there is iPXE to load the boot menu. The fog-client is using it’s own encryption protocol (HTTP within an encrypted tunnel based on certificates similar to HTTPS but not exactly like it!) since years and switching that to the official HTTPS standard is doable but not planned at the moment. The encryption used is state of the art and as strong as HTTS (SSL/TLS) is.

We transfer login password, AD credentials (when configuring those) and other things like that on the web UI communication and I definitely see that securing this should be easy to accomplish for users who want/need it. But we still default to plain HTTP partly because we provide pre-compiled iPXE binaries that cannot include a SSL CA trust certificate as every FOG server in the world generates it’s own CA on the first install. So delivering pre-compiled iPXE binaries is not possible. I have added a script (utils/FOGiPXE/buildipxe.sh) some time ago that is called to compile a full set of HTTPS enabled iPXE binaries embedding the “personal” FOG server CA into them. This works in most cases but it’s quite a heavy challenge if something goes wrong and we need to guide people through debugging this.

Perhaps it could be made easier to setup SSL, rather than forcing it? Perhaps make it optional, and defaulting to ‘no’.

Ok, that would be just renaming the option from force-ssl to use-ssl and ask for it as an installer question I reckon. Could do.

One of the things we are seeing with modern web browsers is that they are not liking self signed certificates. So every site you go to that has a self signed certificate you get the warning and have to click through a few screens to get to the site that employs a self signed certificate.

True, but let’s encrypt is not an option here as Wayne already explained. Maybe we should make it easier (provide a tool) to import the CA certificate into the browser store to get rid of the self signed messages. Not sure if that might cause other issues for users?!

Beyond SSL there are a few things that FOG developers could do it improve FOG’s security stance (i.e. mysql, secure password, firewall, etc).

Definitely a good point!!! Should fix that before we get into encrypting everything.

[astrugatch]

@Sebastian-Roth @george1421 @Wayne-Workman

While I agree that the self signed warnings are annoying; from a security standpoint it is still better and common for many self hosted services. Web communication should be secure even if it is less convenient. The fact FOG has so much power over clients (forcing re-installs, running snapins) means that the login to the web ui HAS to be encrypted. Most management services default to self signed and provide the option to replace with a thirdparty / external cert. Adding a UI element to streamline this (eg upload third party cert and restart fog from the UI) would make it more user friendly. This is the default with JAMF (tomcat) and Solarwinds.

I do agree that looking at requiring a mysql password and configuring the firewall should be addressed too.

[Wayne Workman]

It’s worth noting that FOG is open source and runs on Linux and Apache. There’s a thousand articles on the internet about applying SSL to Apache. Anyone can secure their FOG installation with a self signed cert, or an organization-trusted cert. One could even say that securing things with SSL is the admin’s job.

[astrugatch]

@Wayne-Workman

I agree that applying a cert in Apache is simple but I also believe the best experience is to meet a minimum level of security out of the box so to speak. Honestly I would say that moving the require https out of the installer flags and making it one of the dialogues (like the questions about network config) would be good enough. At least then new users (even ones following random out of date guides online most of which don’t reference the installer script flags) would be able to choose.

[Sebastian Roth]

@astrugatch said in FOG 1.5.6 Officially Released:

Adding a UI element to streamline this (eg upload third party cert and restart fog from the UI) would make it more user friendly. This is the default with JAMF (tomcat) and Solarwinds.

As discussed here it’s not as easy as it sounds: https://forums.fogproject.org/topic/12926/fog-behind-reverse-proxy

But I am with you that we should encourage more people to make it more secure and one important step would be to ask within the installer. Just not sure yet if we make the default choice yes or no.

[astrugatch]

@Sebastian-Roth

To be clear I’m mostly speaking about the web UI right now. But the client would be important too. The way JAMF handles the migration is that it continues to use its internal CA and distributes the new cert to the machines on check in. It keeps track of those that have received the cert and compares that to its list of enrolled machines. When all machines have received the cert there is a UI element that goes from red to green letting you know that the server can now be switched to communicate via the external CA.

[george1421]

@Sebastian-Roth Really when you think about it, its not an either or situation. Why not setup both http and https in apache. Neither is dependent on the other.

So go ahead and by default create the apache self signed certificate and spin up both http and https in apache (to different config files so the FOG admin can stop http if wanted). Make the self signed public root certificate available so the IT admin can download it and install it in his/her computer’s trusted certificate store then no more warnings in the web browser for certificate issues. (we did something similar with our vSphere environment where vCenter creates its own self signed certificates)

The issue will be with making ipxe https compliant. Those binaries could be problematic on the target FOG system. IT can be done, but then FOG will need to load the compiler and development libraries to compile iPXE. It can be done, its just one more failure domain.

(thinking out loud here) I wonder if FOG can create a valid certificate chain, then create the local certificates via a subordinate CA. So if the FOG Project created a root level trusted certificate then all FOG servers would then create their self signed certificate (as a subordinate CA) from the FOG Project trusted root certificate. The iPXE binaries could be compiled against the FOG Project trusted root certificate by the FOG Project devs. Would those work in this new SSL environment since everything would have a common trusted root? (just guessing). Would this be any different situation from what Verisign or other trusted root providers do?

[Wayne Workman]

@george1421 said in FOG 1.5.6 Officially Released:

Why not setup both http and https in apache.

I’d say that’s a good idea.

[Sebastian Roth]

@astrugatch Sorry for my late reply. Just too many other things so I set this aside for a bit…

To be clear I’m mostly speaking about the web UI right now.

Ok fine. I will work on adding that to the installer in a way that more people might use it.

But the client would be important too.

What exactly to you mean? We do state of the art encryption between fog-client and FOG server ever since the current fog-client was released (compared to the old legacy client). Anything more we need here?

The way JAMF handles the migration is that it continues to use its internal CA and distributes the new cert to the machines on check in. It keeps track of those that have received the cert and compares that to its list of enrolled machines. When all machines have received the cert there is a UI element that goes from red to green letting you know that the server can now be switched to communicate via the external CA.

Yeah this is highly advanced certificate handling that I would love to add to FOG but probably won’t find the time to do so any time soon. We are on the very edge with way too little work force working on FOG.

I’d prioritize the mentioned database password security now. Follow up topic here: https://forums.fogproject.org/topic/13267/database-security

[jburleson]

@Wayne-Workman

If the FOG client uses HTTP to communicate, is there any reason that we have to use the generated self-signed certificate for HTTPS?

Why not run both but allow the admin to change the cert for just HTTPS? No need to change the way the client works but allows the admin to use a signed certificate if they want to avoid the browser warnings.

I kind of do this now except I use the FOG generated certificate. I do not really mind the browser warning (as long as they do not start outright blocking it).

I have not tested this using my signed certificate but I can test it next Monday if there is interest.

[Tom Elliott]

@jburleson if the cert you’re using is signed by the fog server, and the machines you are using to access the server have the fog client on them, then you shouldn’t get the warnings either as the FOG CA signed the certificate and it’s relevant chain is also trusted by the machine.

[jburleson]

@Tom-Elliott For Windows 10, I think this is only true if you use Microsoft Edge. If you use a different browser (Firefox, Chrome, etc.), then you will get the browser warning until you add an exception for the cert in the browser. At least that has been my experience so far on all the Windows 10 machines that I have deployed.

[Tom Elliott]

@jburleson for Firefox yes but chrome uses the windows cert store

[george1421]

@jburleson Yes both firefox and chrome uses the windows cert store as Tom posted. I know because we had to do this with our vCenter servers. You need to take the public root certificate of the self signed certificate and import it into the machine’s trusted root certificate store. Once you do that then there is no warnings in any of the three browsers.

While these instructions are specific to vCenter the process would be the same for any self signed root certificate. https://tinkertry.com/how-to-get-rid-of-vsphere-browser-certificate-warnings-in-windows

[Sebastian Roth]

An issue was found in 1.5.6 that calls for an early next release to fix that. Find the details here if you run into problems with FTP connections on kernel updates or storage nodes in 1.5.6: https://github.com/FOGProject/fogproject/issues/311