Difference between revisions of "FOG Client"

From FOG Project
Jump to: navigation, search
Line 37: Line 37:
  
 
References: [https://forums.fogproject.org/topic/6325/invalid-security-token-without-any-security-tokens-being-set-also-ca-ssl-security-concerns/6 CA SSL security concerns]
 
References: [https://forums.fogproject.org/topic/6325/invalid-security-token-without-any-security-tokens-being-set-also-ca-ssl-security-concerns/6 CA SSL security concerns]
 +
 
[https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning Certificate and Public Key Pinning]
 
[https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning Certificate and Public Key Pinning]
 +
 
[https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Certificate_and_Public_Key_Pinning Transport_Layer_Protection_Cheat_Sheet]
 
[https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Certificate_and_Public_Key_Pinning Transport_Layer_Protection_Cheat_Sheet]
  

Revision as of 06:35, 13 December 2015

Article under construction - below you will find notes / gibberish that has slowly been collected to make an article out of.

Be thoughtful and only use what you need. Feel free to ask questions in the forums.


FOG 1.3.0 Client

Security design

Communications between the FOG Client (0.9.9+) and the FOG Server (1.3.0+) are secured with SSL.

A CA and certificate is generated on the FOG server during installation in these locations:

/opt/fog/snapins/CA
/opt/fog/snapins/ssl

The public certificate is generally located here:

/var/www/html/fog/management/other/ssl

The client installs your servers’ certificate and the FOG Project certificate.

The “FOG Project” CA (made by the FOG Project) servers two purposes:

  • SYSTEM level services need to be digitally signed otherwise windows will throw security errors. This can also be used to ensure no tampering was done with the client files
  • That certificate is used to “verify” upgrades. Lets say we release a patch for the client, the client will download the MSI from your server and check if it was signed by us. If the MSI was somehow tampered, the digital signature would no longer be valid.

Using HTTP over HTTPS has no security benefit to the client. Why? Because all traffic is already encrypted. Here’s a very basic overview of how the new client communicates

  • Each client has a security token. This is used to prove to the server that the client is the actual host and not an impersonator. This token gets cycled constantly. When the client first makes contact, it encrypts its token and a proposed AES 256 key using RSA 4096 using your server’s public key. This public key is verified against the pinned server CA certificate by checking the x509 chain and fingerprints.
  • If the server accepts the security token and the new AES key, all traffic from that point on is AES 256 encrypted using that securely transmitted key.

The whole point of our security model is to allow for secure communication over insecure medians. Even then, the client installation has an HTTPS option, but it serves no real security benefit.

References: CA SSL security concerns

Certificate and Public Key Pinning

Transport_Layer_Protection_Cheat_Sheet



FOG Client 0.9.9+ Installation options

msiexec /i FOGService.msi /quiet USETRAY="0" HTTPS="0" WEBADDRESS="192.168.1.X" WEBROOT="/" ROOTLOG="0"

Firstly, all options are optional. Here’s what they all do:

  • USETRAY: defaults to "1", if "0" the tray will be hidden
  • HTTPS: defaults to "0", if "1" the client will use HTTPS (not recommended)
  • WEBADDRESS: defaults to "fog-server", this is the ip/dns name of your server
  • WEBROOT: defaults to "/fog"
  • ROOTLOG defaults to "0", if "1" the fog.log will be at C:\fog.log, otherwise %PROGRAMFILES%\FOG\fog.log

Reference: MSI Silent Install without Tray Icon

Manually reset encryption on ALL hosts

mysql
use fog
UPDATE hosts SET hostPubKey="", hostSecToken="", hostSecTime="0000-00-00 00:00:00";