Bug #8802

Update server should be https to prevent MITM attacks on updates

Added by john aylward over 5 years ago. Updated about 3 years ago.

Closed: Behaves correctly
Nice to have
Jordan Hubbard
Target version:
Seen in:
Reason for Closing:
Reason for Blocked:
Needs QA:
Needs Doc:
Needs Merging:
Needs Automation:
Support Suite Ticket:
Hardware Configuration:
ChangeLog Required:


When updating my freenas, I noticed the update site listed as:

Update Server:

Having signed updates doesn't help if an attacker can proxy those requests to their own server and issue their own signed updates. The update server should use HTTPS for all queries to ensure that firmware updates are from a trusted source.


#1 Updated by Jordan Hubbard over 5 years ago

The attacker would have to hack your FreeNAS box as well, since the updates must be signed with our key and pass our CRL checks. They can't be just arbitrarily signed.

#2 Updated by john aylward over 5 years ago

Wouldn't it be signed with your private key on the dev/release server, and decrypted with the public key on my freenas box? That would indicate that your release server is the weak link in the keystore chain for hacking, not my box. The release server would likely have a higher risk of being hacked than my little box behind a NAT and firewall.

Either way I see your point that SSL would not protect against this type of threat, but I still think it's a decent idea to have updates over ssl for firmware.

#3 Updated by Sean Fagan over 5 years ago

If it's hacked on our end, what possible protection do you think happens with https?

Are you imagining that this hypothetical attacker somehow managed to crack the key we use to sign releases, but then forgot to insert his own ssl key for the web server?

#4 Updated by john aylward over 5 years ago

Lol, that would be a lazy hacker. No, as stated in my previous comment I can't see SSL offering protection on that front. I'm not that familiar with code signing, so I'll try to read up more on how that's handled. My Initial thought was that given enough data, the private key could be brute forced out of the updates by a listener, but the updates are effectively public anyway, so SSL still wouldn't help on that front. While you are likely right that it wouldn't offer any actual benefit, my initial inclination is still wondering why traffic is unencrypted.

Thanks for your time.

#5 Updated by Jordan Hubbard over 5 years ago

  • Status changed from Unscreened to Screened
  • Assignee set to Jordan Hubbard
  • Target version set to 49

#6 Updated by Martin Grohmann about 5 years ago

I still think the updates should be distributed over https.

I am trusting my FreeNAS box with all my data (some more valuble than others, but still all my data), so I want the top most security. And that means besides the key verification of the update the distribution over https.

#7 Updated by Jordan Hubbard over 4 years ago

  • Status changed from Screened to Closed: Behaves correctly

Our updates now go over a CDN (which we can't force certificates on) and we have code signatures in all the places that matter which prevent unauthorized / tampered-with updates from installing.

#8 Avatar?id=14398&size=24x24 Updated by Kris Moore about 3 years ago

  • Target version changed from 49 to N/A

Also available in: Atom PDF