Dave Townsend schrieb: > Nils Maier wrote: >> Addressing Dave's demand for proposals: > > Sorry but I didn't actually demand proposals. I gave one and asked for > opinions on it. I am of course open to other proposals and a few have > been given. > >> If there is no workable solution then don't implement one. > > As far as I can tell there is one, I need to investigate the code more > though. > >> It isn't like there are armies of evil folks out there lurking on wifi >> hotspots just to intercept update requests. > > Maybe not, but given the working demonstration and if we choose to do > nothing about it who can say that people won't start to give it a try?
This treat is greatly exaggerated IMO. There are far more easy ways to anonymously get into a user's system than lurking around wifi hostspots with the fear of getting caught. >From a (criminal) business point of view the risk and effort simply does not match the revenue. So I would imagine some script kiddies playing around and performing such attacks, but not a serious bot herder or identity thief to do this. But you're right of course, you never know before ;) >> Furthermore the first installation could be hijacked as well, so until >> this is addressed the problem persists anyway. > > Correct, but I'm not convinced it matters which order we tackle these > two problems in. I was just saying that it doesn't make any sense to rush a solution for updates (instead of taking the time to get it right; which I fear could happen here) when the other major MITM attack vector is still wide open. >> Make it opt-in, not must or opt-out, if there is no solution in reach >> which would satisfy all requirements. > > It will absolutely not be opt-in, that would be equivalent to doing > nothing. I seriously hope it will not be opt-out either, so yes I am > looking for a solution that applies all the time. The only exception to > this could be local machine development. Opt-in is not equal to "nothing". A damn lot of extension authors will still opt-in limiting the possibly attackable targets and thus changing the effort/revenue calculation bad boys do, maybe down to that point that is does not make sense to take the effort and risk of mounting a MITM attack against the update service at all. Remember, we are talking just about a small fraction of extensions that use insecure updates, and providing workable opt-in solutions and evangelizing authors will even lower that small fraction. It is still a security against usability trade, but making/keeping the numbers low and therefore the possibility of an attack might be secure "enough". > >> Try to promote workable solutions, evangelize authors, to use what is >> available already (extension code signing, SSL install/updates). Most if >> not all high-impact (or better popular) extensions will likely implement >> secure updates, especially if they get some guidance from mozilla. >> Those are the ones with the highest risk of being "attacked" anyway. > > This is already in progress I believe. Yeah, but still these efforts could be maximized. Starting with devmo documentation: I don't really see real information about it e.g. on devmo. There is a warning in "Install manifests" suggesting to use https, but no further explanation beside a generic MITM remark. Not all authors know what this means or the implications of this. http://developer.mozilla.org/en/docs/Code_snippets:Signing_a_XPI is hard to understand and has red text all over it. There is no information about CAs that offer code signing certs. I went out to find and compare offers for this, but it was incredible hard to track down CAs and their pricing. So somebody with a real knowledge and some writing skills would need to improve these articles and examples. >> That community program that gives away software/hardware could be >> extended to provide popular extensions with (money for) code-signing >> certificates... > > Worth a thought, I shall flag this for Seth's attention. > >> Maybe make it easy for authors to add their own self-signed cert that >> might check updates. >> Thinking of a fuel-esque way to easily add those certificates, and tools >> that make creating certs and signing more easy (all those "help me >> signing that xpi" threads clearly indicate that it is not easy enough >> yet). >> Maybe even allow to use self-signed certificates for installation, then >> asking the user to import the certificate if he trust it. (Admittedly >> this raises the question if the users will understand such >> confirmation-dialog and not just OK-it away). >> >> My observation is that none of the distribution systems solved this >> trust-issue fully yet. >> E.g. DPKG/RPM will warn you but still allow you to install >> unsigned/unknown-key-signed packages. > > I wouldn't consider that much of an indicator. dpkg/rpm aren't exactly > for novice users. It would be interesting to know why they allow you to > override the security though. As I understand it windows updates are > signed and rejected if they fail the signature check. > > Dave Windows updates don't really apply. MS and only MS issues them. However there is not even an unified install/update mechanism for Windows. There is msi (which is not but can be made secure, similar to dpkg/rpm), mozilla upgrade, ... There are thousands of different application-mechanisms in fact and I guess most of them aren't secure. Oh, and IIRC if you don't use automatic updates put pull them directly from microsoft.com/download then MITM similar to what we discuss here are still possible (last time I checked they didn't have https download servers nor were those msi packages required to be signed). dpkg/rpm however are issued by different entities and maintained by different entities (i.e. mirrors driven by universities). First thing a lot of Ubuntu users will do is to install automatix or similar. The corresponding deb is signed IIRC, but the key is unknown. So even novice users are likely to be affected by this. ;) You would either have to disallow those completely (not an option), or have to require that the key is imported manually prior to installing, but that is just the same overriding of security/trust although admittedly harder to do for n00bs (and therefore bad for user experience). Disabling installation/updates of unsigned packages would create an uproar, as it takes away the users freedom (which cannot be tolerated in F/OSS) and creates a de-facto monopoly where the distro makers would effectively decide which software a regular user may run. I could imagine further side-implications, like courts ordering to prevent certain software from being installed because of legal issues (like mpeg2-codecs which are covered by patents) although the user either has a valid license or lives somewhere were it isn't illegal (like Germany where software patents are not enforceable ATM). This whole issues can be seen as a case of proposed DRM, crafted with good intension, but which could easily turn bad if not crafted carefully enough. Nils _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
