freebsd
Use https vuxml.freebsd.org for all links and vulnerability database
Using ttps by default would be an issue, because by default we cannot validate the certificate given there is no CA provided, so pkg audit will fail without ca_root_nss installed
We know what CA provides the certs for the FreeBSD pkg servers. Why can't we bundle the cacert with ports-mgmt/pkg ? Or even include it in the base system like we do the SSL keys for the FreeBSD pkg repos?
@infracaninophile There may be some other concerns, e.g. a firewall may prevent using https in the first place, etc. and we may revisit this at a later time. I only noticed this when someone asked in ports/200665 (which I think you guys would want to take a look too).
I'm not sure if it's a good idea to embed the public key in pkg itself though -- it would make future update of the key harder. Perhaps we can use the DANE/TLSA record when it become available? (I haven't asked clusteradm@ for that because major browsers doesn't support it yet, but since we already do DNSsec for f.o domain it's trivial to implement it).
Sure. Running pkg(8) over HTTPS doesn't really add anything to the security of the packaging system which relies on the built-in RSA signatures. It improves the confidentiality of the network traffic, although the fact that you're connecting to a FreeBSD pkgrepo pretty much gives away what you're up to in any case.
Being able to use DANE would be cool -- not sure if libfetch groks that yet. However, chance of being in a DNSSEC compatible environment probably similar to being somewhere where HTTPS is blocked. This airport WiFi I'm on at the moment fubars checking the TLSA records I have for my home systems...
The proper DANE implementation is hard. I have some ideas in this area that we could discuss at the upcoming BSDCan.
@infracaninophile This is for vuln.xml.bz2, which is not signed currently.
Confidentiality is not a big concern for pkg repo nor vuln.xml because these are public information, and by accessing the IP address associated with the sites, it's very easy for a network administrator know what's going on.
However, with TLS we also mitigated another attack -- replay attack by requiring an randomly generated nonce value. A typical attack would be e.g. set up a transparent caching proxy and stop invalidating stale data. Now, the victim system will have no vuln.xml updates. (Note by the way, that vuln.xml.bz is not signed at this time).
Note -- I'm not asserting that this is a real and immediate threat, (in other words, I don't believe we are in an immediate danger, and if an attacker can do it they could already do things that are much more profitable), but just would like to point out that there is a possibility.
@vstakhov I agree. Unfortunately I would not be attending this year's BSDCan, wish you guys have a fruitful conference there!
This has been in a "it's unclear how to solve this" mode for a year-ish. As described in the original PR I see the main risk in modifying the transferred file, so maybe signing would really be a an alternative option. Another thing I can suggest is to at least check there's no binary garbage in the file before it's passed down to libxml. That might be easier to do than anything else.
As such, this also serves as a workaround admins can use: Mirror the file locally on a server you control, and audit by some means before making it accessible to your clients' root crontabs ;-)
