There is no real method of verifying download integrity - we need gpg keys
-
The GPG keys are no "real method" either. https://blog.filippo.io/giving-up-on-long-term-pgp/
-
@virgiliomi:
SHA256 checksums of the release version download files are available from pfSense's site for verification of the download. They can be found here:
https://files.pfsense.org/hashes/
Even the daily snapshots of the development versions include SHA256 files, though those are on the same server as the snapshots are.
Edit: I see you're aware of the checksums… but my question to you is... if the server is verifiable as belonging to pfSense (through the SSL certificate) then what's the issue with using these checksums?
"verifiable belonging to pfsense" ok so what is stopping someone from messing around with the .sha256 files by hacking the server or doing a MITM with a certificate from another CA?
The PKI CA system relies on every CA being honest, they won't really verify who is actually requesting a certificate even with EV and that still relies on someone actually noticing the lack of the EV box.
Certificate pinning only works until they get a new cert.Every so often there is a story in the news about someone convincing a provider to sign for google.com or some other popular website where they really should know better.
GPG WOT signed keys are the best option available, plain and simple.
-
GPG WOT signed keys are the best option available, plain and simple.
Yeah, WoT. Mentioned in the link I posted. IOW, noone verifies things like this. People grab the key from a random keyserver. How's that different from grabbing a checksum from pfSense website goes beyond me.
-
So because according to you "nobody verifies this" (how do you know that? I verify and so do people I know) we should just give up on security, surely no one will attack a distro that is used by governments and important companies.
As of now there is no way to tell if the .isos are corrupted, or if the build server is corrupted as we still don't have reproducible builds), does that seem ok to you?
Grabbing a key from a random keyserver (basic gpg verification) is much better than putting the "verification" hash on the same server as the .iso.
Does anyone know how to get in touch with whoever is actually running pfsense to ask them to do this? netgate doesn't answer my emails as I don't give them money…
-
Grabbing a key from a random keyserver (basic gpg verification) is much better than putting the "verification" hash on the same server as the .iso.
Exactly how's that "much better"? Put some key on keyservers and use those for signing the fake ISOs. About 99% of people out there won't bother with verifying, and 99% of the rest will use whatever key you tell them to "verify".
-
So you want them to do it like freebsd does it where they have their checksums signed, and you can get the freebsd keys
https://www.freebsd.org/doc/en_US.ISO8859-1/articles/pgpkeys/
And then you could verify the checksums with the keys, etc. Sure why not.. It too could be compromised as dok says for billy bob coming to the site and grabbing the keys to validate either off the same site or some random keyserver were anyone can just upload keys, etc.. So not so sure how much "better" it is..
Unless you have previously validated the keys, etc. So if you had keys from say when they first release them, and have validation of those keys. Then this would be good idea, it's a bit more work - but if pfsense is wanting to show they are going the extra mile.. Sure why not..
There was a recent blog article about how they had some 3rd party validation of their code done.. So yeah this might be the next step.. As to contacting them
https://www.pfsense.org/about-pfsense/#contact-us
To contact us for submitting patches, inquiring about contributing to the project, notifying us of problems with any of our web sites, or any other non-support issue email coreteam@pfsense.org.To contact us for security issues, use security@pfsense.org
Or you could prob hit up jwt or jimp with PM here on the board fior best direction to take such a request.
-
Grabbing a key from a random keyserver (basic gpg verification) is much better than putting the "verification" hash on the same server as the .iso.
Exactly how's that "much better"? Put some key on keyservers and use those for signing the fake ISOs. About 99% of people out there won't bother with verifying, and 99% of the rest will use whatever key you tell them to "verify".
Forward verification and web of trust obviously.
Why are you arguing against security improvements? What is your real motive? So because most users are idiots security shouldn't be bothered with?
You and the other trolls can go fuck right off, you have no good ideas and no constructive criticism all you do is come in and shit all over the place and people who want to make a difference.
@johnpoz:So you want them to do it like freebsd does it where they have their checksums signed, and you can get the freebsd keys
https://www.freebsd.org/doc/en_US.ISO8859-1/articles/pgpkeys/
And then you could verify the checksums with the keys, etc. Sure why not.. It too could be compromised as dok says for billy bob coming to the site and grabbing the keys to validate either off the same site or some random keyserver were anyone can just upload keys, etc.. So not so sure how much "better" it is..
Unless you have previously validated the keys, etc. So if you had keys from say when they first release them, and have validation of those keys. Then this would be good idea, it's a bit more work - but if pfsense is wanting to show they are going the extra mile.. Sure why not..
There was a recent blog article about how they had some 3rd party validation of their code done.. So yeah this might be the next step.. As to contacting them
https://www.pfsense.org/about-pfsense/#contact-us
To contact us for submitting patches, inquiring about contributing to the project, notifying us of problems with any of our web sites, or any other non-support issue email coreteam@pfsense.org.To contact us for security issues, use security@pfsense.org
Or you could prob hit up jwt or jimp with PM here on the board fior best direction to take such a request.
Yeah thats the idea.
Thanks, I had assumed that only paying customers would receive a reply due to the new corporate types in management.
I created a bug report but jim pringle closed it as a duplicate and pretty much said that having https and another server with the checksums is good enough, which it isn't as all it takes is one rogue CA either malicious or with poor security. I will message him again….
Why the hell are people arguing against security improvements? It makes absolutely no sense.
-
Why are you arguing against security improvements? What is your real motive? So because most users are idiots security shouldn't be bothered with?
You and the other trolls can go fuck right off, you have no good ideas and no constructive criticism all you do is come in and shit all over the place and people who want to make a difference.
Why the hell are people arguing against security improvements? It makes absolutely no sense.Noone's arguing against real security improvements. Wasting time on "improvements" that you just imagine to improve something (plus that a vast majority of people has no idea how to use) is just… well, waste of time. Already told you that the WOT is just something that plain does NOT work.
P.S. And yeah, my real motive is to backdoor every pfSense user, ya know, 3letter agent. ::)
-
Although doktornotor is a bit callous, all his points are valid and constructive. Telling him to "fuck off" is uncalled for… :( He actually does know his ass from a hole in the ground.
Unless you're physically meeting the pfSense to get their PGP keys, the increase in security is minimal.
-
If your primary concern is that the hashes are on the same server as the files, then that isn't always the case: When you download a file from pfsense.org using the download selector it shows you the hash on that page, served from the web server and not the same server that is sending you the img.gz/iso.gz. That should be sufficient verification for the majority of cases.
