Thanks for the reply Sebastian and sorry for the super long delay.
I am observing this behavior when using “ipxe.pxe” – I have not used any other one binary (not since I switched it to a production server a couple months ago).
Also, to clarify, the transfer rate is good once the transfer begins, it is only when it is “configuring net0” that it seems to be a slow link. However, I assume it is some hardware dependent issue as I just tried a random computer model and saw it was configuring at the expected 1Gb link speed.
So I guess the tl;dr is that this isn’t really a problem.
Sorry I’ve been unresponsive – I’ve been quite busy with tasks at work and probably wont’ update anytime soon. If you think it’s fixed, I’d say it’s fine to close this ticket ----- if/when I upgrade, I can re-open/comment if I still find it to be an issue.
@mrayzies not a problem. To answer those questions:
Yes, the client installs your servers’ certificate and ours.
The “FOG Project” CA (made by us) servers 2 purpose.
SYSTEM level services need to be digitally signed otherwise windows will throw security errors (I have seen this issue when imaging a machine with an unsigned client). 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 v0.9.10, 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.