FOG behind reverse proxy



  • Hi,

    I am looking to use the Let’s Encrypt wildcard Certs with a number of the sites we host (even those used internally) and was planning on putting them all behind a reverse proxy since we can’t automate our DNS and need to allow Certbot to communicate with Lets Encrypt’s servers. If we have an internal DNS name for fog that we put into the client (fog.domain.org/fog) will it be a problem if it is passing through the reverse proxy?

    Thanks



  • @Sebastian-Roth

    It might be worth researching how services like JAMF support external CAs for their enrolled clients.
    By default JAMF works the way fog works with a selfsigned cert from its own CA but they do have support for certain Public CAs.


  • Developer

    @astrugatch said:

    I do think support for external CAs would be good in the future for the client as well but that isn’t my current goal.

    I thought about this a couple of times when I wrote that post. But I have not come to a nice conclusion yet. I mean supporting external CAs within the fog-client would be just a minor code change - no trouble. But actually moving an existing environment from one CA to another one is a tough job I reckon. And on the other hand I wonder if it’s advisable to do because someone might misuse that to trick clients into trusting a different (fake) server. Not very common as an attack vector within an internal network but I am not sure if we want to open such a vector yet.



  • @Sebastian-Roth

    Thanks for the super thorough reply. I wasn’t looking to encrypt the client traffic, just the web UI, but knowing that them having the same hostname and thereby passing through the ReverseProxy was my concern. The separate vhost or DNS entry might be better, one for the web UI and one for the clients to use, so I can leave the CA certs untouched. then the clients can go directly to the fog.domain.com/fog and the webUI can be something like fogmgmt.domain.com/fog

    I do think support for external CAs would be good in the future for the client as well but that isn’t my current goal.

    Thanks for all your help!


  • Developer

    @astrugatch Let me start by saying that this is kind of an advanced setup that I guess you are one of the first people considering this I think. While I think it’s a good concept I am fairly sure you’ll run into a couple of obstacles that won’t make it easy for you.

    Before I start to get into the details I might ask you what is your exact aim? I see you asked about SSL in the forums a while ago. But I am not sure which way you decided to go and what stage you are at. Is your aim to have the FOG server HTTPS only with Let’s Encrypt cert? Or do you simply want HTTPS with Let’s Encrypt cert for the webUI? I just ask because different aims lead you different ways and some are harder or even impossible to go while others can be achieved.

    Here is the story why I think you aim matters a lot:

    When the new fog-client came to life years ago (Summer 2014 I think) HTTPS was not as wide spread as it is today. But still the fog-client was made to use encryption to secure the communication. It’s not general HTTPS (SSL/TLS over HTTP) but a self engineered communication protocol based public/private key encryption using certificates just as HTTPS is. It actually uses exactly those certificates that can be used for HTTPS but follows a different protocol (using state of the art AES 256 encryption)! Back then I was not as heavily involved into FOG yet and I lack the information on why the developers decided to go this way. I am sure it was for good reasons! Just keep that in mind.

    So when you install the client it asks for server address (IP or DNS name) and web root. Now it connects to the FOG server, downloads the CA certificate, verifies it and locks into that as root of verification (process is called pinning) for all later (encrypted) communication. As mentioned the communication is done over HTTP (http://fog.domain.org/fog) but the contents are encrypted. Now if you change the certificates (CA and server cert) on your FOG server while some of your fog-clients have already been pinned to the old one the communication will break. You would need to re-pin (not sure if that can be automated) or re-install the fog-client to all your hosts to make them use your new CA cert the root of verification.

    And even if you decide to re-do it all I need to inform you that we’d have to compile a fresh fog-client version for you. As of now you can only use certificates from a self signed CA as the fog-client checks the subject of the CA certificate to be “FOG Project” when it does the pinning. So it won’t pin to the Let’s Encrypt CA certificate.

    There is one more thing I want to bring into play. Beside all the fog-client encryption stuff you can still make the fog-client use HTTPS (double encrypted sort of). You can switch to HTTPS after fog-client installation changing the parameter HTTPS from 0 to 1 in C:\Program Files (x86)\FOG\settings.json. But as you can’t switch off the fog-client specific encryption you’d still run into the problems mentioned above. AFAIK the pinning is done via HTTP and we’d need to change that in the fog-client code as well if you want to go HTTPS only. Not sure if it’s worth going that route.

    The things mentioned so far don’t stop you from using Let’s Encrypt certificates for the web UI though. You need to sort of separate web UI from from fog-client communication certificate-wise. Probably best to use different vhost definitions as you were discussing with Tom in the other forum thread.

    Again, this is just an overview of what I think needs to be considered when you want to use a reverse proxy. I might even have missed something here. As well I am writing this just form the top of my head as I don’t have the time to go through the code and even test things right now.


Log in to reply
 

452
Online

5.5k
Users

12.7k
Topics

120.2k
Posts