On 01/01/14 21:23, iyCXLONo mVUTxeyv wrote: > Hello, > > Is it possible to download OpenWrt binaries over HTTPS? If not, which seems > to be the case, I want to suggest that HTTPS for downloads is needed. The > HTTP downloads are at risk of man-in-the-middle attacks. For instance, > compromised binaries could be supplied in response to HTTP download requests. > Also, downloads could be eavesdropped to learn the hardware of a downloader, > which increases the risk of the downloader to targeted attack. > > If this seems like a paranoid concern, it was reported a few days ago that > the NSA is building a network of hacked routers across the globe as part of > its QFIRE program [1]. Given the general state of consumer router security, > it seems unlikely that intelligence agencies are targeting specifically > OpenWrt downloads, but we know both that routers are a target and that HTTP > downloads are a vulnerability, which amounts to a real risk for OpenWrt users. > > A Trac ticket from April exists for HTTPS downloads, but it has not gotten > much attention [2]. > > [1] http://cryptome.org/2013/12/appelbaum-30c3.pdf, slide 18 > [2] https://dev.openwrt.org/ticket/13346 >
Hi there, As the person who submitted 13346, I'd like to add an 'update' at least to this list of my current thoughts in light of recent information releases by such people as Snowden and Appelbaum as well as what was published in Der Spiegel (I would cite, but [a] it's early in the morning and I'm lazy, but moreso [b] by now I figure anyone following this thread now or in the future will be reasonably well informed of the generality of the information released rather than who released what). Once I get some coffee in to me, I'll update the trac entry with something very close to the following: ---- tl;dr - Some of the serious brains at the IETF think the Internet is probably broken beyond repair and needs re-engineering. There's no way for a reasonably well informed person to conclude otherwise. An inability to fully trust initial downloads creates a dangerous false sense of security of any subsequent updates. Detail: There are some problems even with https downloads, as described (albeit for another distro, but the bug entry has some good discussion in it that should get a reader thinking about how to get bootloaders and the like to trust keys/certificates as well as revocations etc. ) [1] Note it's 'oldest-bug-evar' alias and report date of 1999. Can't recall if it's mentioned there, but one way to alleviate that is to use some sort of signed BIOS system, effectively how MS use UEFI. The problems of Open Source on UEFI is well documented, I shan't cite here suffice to say there's a very large chicken and egg problem. I believe if we, as the online commmunity with an interest in this area, consider how we can trust boot loaders to correctly handle Keys and Certificates, along with OpenPGP KeyID problems as described [2] and I do not think it is clear how 'ultra-paranoid' or even 'reasonably paranoid' end users can currently verify how they can relatively easily initially 'trust' upstream anything these days without 'positive biometric feedback indicators'. Finally, as an aside, given it's been shown that certain Government agencies are capable of intercepting WiFi signals over 10 kilometers away with 'NIGHTSTAND' technology[3] I believe these sorts of issues are precisely the sort of things that the IETF are looking to address in their 'perpass' discussion[4] of which there has been much debate[5] Those still reading and with a interest of where the online community may need to go in the future, could do far worse than read Phillip Hallam-Baker's draft about a 'PRISM Proof email' system[6] in particularly his points raised about 'Policy, Audit and Transparency'. I think the best the paranoid can hope for is vetting and building code locally and hope their build machines and production systems haven't been physically intercepted at some stage. Cheers, Pete. [1] https://bugzilla.redhat.com/show_bug.cgi?id=998 [2] http://debian-administration.org/users/dkg/weblog/105 [3] http://www.engadget.com/2013/12/30/nsa-can-hack-wifi-devices-from-eight-miles-away/ [4] https://www.ietf.org/mailman/listinfo/perpass [5] http://policyreview.info/articles/news/technical-community-debates-over-taking-back-internet/215 [6] https://www.ietf.org/id/draft-hallambaker-prismproof-req-00.txt ---- Coffee sourced, I've edited this a bit. I realise it's a bit clumsy, but to close off: I'm happy for vendors to acknowledge the issues involved, but I'm highly dubious of any suggestion that provides what the 'paranoid' seek because the underlying infrastructure of The Internet is incapable of providing what is needed for them. If vendors close such tickets with a 'WONTFIX' or even 'NOTABUG', I can understand, however I'd like to think vendors will leave such tickets open so that if a serious proposed resolution is found in the future the existing problems can be easily checked off. Must dash, all the best, Pete. _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
