Unable to find signature files for installer downloads
-
Hello pfSense forum,
This week I want to do a fresh pfSense installation with the current stable release. I can find the gz file with the iso image and the files for md5 and sha256 checksums, but there are no signature files available. I need them to verify that the downloaded gz file has not been tampered with.
On the pfSense website and in the online documentation there is no signature file mentioned at all. How do I verify the signature? What I expect would be a .sign file for every checksum file that I can verify with GnuPG.
For this topic I was unable to use the search, because my search terms bring up a lot of topics concerned with the functionality of pfSense itself instead of its installation. Thus I apologize if this has been explained before.
Thanks!
-
The hashed checksums aren't enough for you? I would think that getting it from the source via HTTPS and then verifying the checksums would be sufficient.
-
How do you know that the checksum files weren't tampered with in that situation? HTTPS won't help much, how do you know that the certificate isn't compromised (allowing for MITM attacks)? This happens - it's not a hypothetical scenario.
I think that the upgrade function in pfSense does check a signature, right? Then there has to be some way to do it when doing the initial installation.
-
I asked for the same thing a couple years ago. It sounded like people thought it was a good idea but it was never implemented.
At least a signed release announcement with the hashes in the announcement.
I disagree with your assessment of the problem though. If you're worried about compromised secret keys for HTTPS then you should also be worried about compromised secret keys during the signing process.
I'm more worried that the entity that can place altered versions of the software on the server can also place altered hash files alongside them.
-
If you're worried about compromised secret keys for HTTPS then you should also be worried about compromised secret keys during the signing process.
Those are two very different things. One is about the certificate authority being compromised, the other is about pfSense themselves being compromised - the first actually happens, again and again, just in March this year Google decided not to allow the CNNIC root (China) anymore, because they had their security compromised, allowing for MITM attacks on certificates issued by them, for Google and other companies. Aside from that we know governments can take over certificates from the CA to do MITM attacks themselves, which at the minimum GCHQ+NSA do. This is a very real risk. It might not matter at all for the homelab pfSense box, but in this case I have to do an installation for a company that absolutely takes those risks seriously.
I'm more worried that the entity that can place altered versions of the software on the server can also place altered hash files alongside them.
That is exactly what I am saying, and that is my reason for creating this thread.
I found out that the internal upgrade mechanism uses gzsig for verifying the gz files, at least the update files from http://updates.pfsense.org/_updaters/ have a signature embedded - I just verified it myself with my pfSense box at home and its pre-installed public key.
However, the release live DVD archives do not have a signature embedded at all, according to gzsig (no signature found message). So the signature files for the checksum files are still a requirement…
-
No, I'm talking about the private key for the HTTPS server, not the private key for the certificate authority that issued the certificate.
-
I don't think this is relevant for this discussion, I am not concerned about that.
-
Yawn. I'd rather see pfsense.org DNSSEC signed and using TLSA. gzsig my ass.
-
So in the end the only thing I can really do is download all installation files from all the mirrors and compare their checksums and if they all match, I shall hope for the best…
I really do understand that certain features are not possible with pfSense and would require extensive funding, but signing? That can be automated and doesn't require anything beyond verifying it regularly once it is set up.
What does DNSSEC have to do with my topic?
-
What does DNSSEC have to do with my topic?
Since you are so horribly concerned you are not getting the real thing, surely being able to verify that you are downloading things from the proper site would help? So you want to verify some signature, now what's the point when that proper signature needs to be published somewhere on the website so that you could verify it. Kinda useless when you can publish anything via MITM.
Overall, being able to verify something against checksums published on a trusted site a hell lot easier than messing with some cryptic gpnug/gzsig nonsense that 99% of users absolutely do not understand and have no desire to learn. Make a poll here and ask about about how many of them understand how's the signature verification of upgrades/packages working and see for yourself.
P.S. Contrary to your beliefs, implementing this gnupg stuff on infrastructure is a giant pain to start with, go read the Gentoo -dev ML archives.
-
Since you are so horribly concerned you are not getting the real thing
Tell me: Did you phrase it like this on purpose? Should I not be horribly concerned when I know that my own government has their spy equipment installed at a hop that all the traffic of our company comes across? When I have to assume that other governments do the same thing (GCHQ, NSA)?
So you want to verify some signature, now what's the point when that proper signature needs to be published somewhere on the website so that you could verify it.
I was talking about verification via GnuPG. DNSSEC won't be less of a "giant pain" than GnuPG. GnuPG might be a giant pain, but mostly because of problems with the web of trust, not because of setting it up.
messing with some cryptic gpnug/gzsig nonsense that 99% of users absolutely do not understand
I see. So apparently GnuPG is now nonsense - "gpnug" certainly is, I agree. I also like how you made up the percentage number :) I cannot speak for other users and what they understand or not understand. I do care for it and it's not a very exotic or unreasonable thing to ask for.
This discussion with you adds nothing valuable to this topic, but I suppose I got the answer to my question: There are no signatures to verify. While I'd like to know more about it and possibly find a way to resolve this issue, I do realize this is not the right forum for that.
-
Should I not be horribly concerned when I know that my own government has their spy equipment installed at a hop that all the traffic of our company comes across? When I have to assume that other governments do the same thing (GCHQ, NSA)?
I sincerely hope you are actively avoiding any Intel HW… especially on your firewall. If not, all of this is a totally moot point.
-
Something like this doesn't seem like too much to ask.
https://www.freebsd.org/releases/10.1R/announce.asc
-
Something like this doesn't seem like too much to ask.
https://www.freebsd.org/releases/10.1R/announce.asc
Yeah. And note that freebsd.org is DNSSEC signed and has a TLSA record for https://www.freebsd.org. Without this, publishing similar stuff is essentially useless when you are concerned about MITM.
-
Useless how? If I've had the FreeBSD security team's public key for years, any alterations to the file can be detected if an MITM wants to play games. The communications channel doesn't matter if I can reliably verify the contents of the message.
-
If I've had the FreeBSD security team's public key for years
That's extremely relevant for those loads of people that don't have it. Or when the key gets revoked. Or when it expires.
-
Key management can be a hassle, yes. Not too bad for those who actually try to verify the integrity of their downloaded firewall software prior to use. Only a few people have to be doing it. They can raise the flag if they see something amiss.
You can stop trying to convince me of all the reasons this is not a good idea. You are wrong. It's the best, currently-available solution to the problem. Yes, they should also DNSSEC.
They should also PGP sign their announcements. Even if posted to the forum or blog there should be at least a link to the PGP-signed version.
