On July 28, 2014 at 8:02:35 PM, Giovanni Bajo (ra...@develer.com) wrote: > > Il giorno 29/lug/2014, alle ore 00:26, Donald Stufft ha scritto: > > > On July 28, 2014 at 5:57:54 PM, Giovanni Bajo (ra...@develer.com) wrote: > >> Il giorno 28/lug/2014, alle ore 22:26, Donald Stufft ha scritto: > >> > >>> > >>> * Anyone able to defeat our TLS and is in a position to MITM a regular > >>> user > >>> can simply supply their own trust file. > >> > >> Yes, though as you say, this is fixed by having the trust file signed. > > > > If we're relying on an online key to sign this file, then we can trust that > > online key to just sign everything and we don't need the authors to do > > anything > > and we don't need a trust file. > > Each signing protects against different attacks: > > * If you only sign the trust-file, a MITM that can break TLS for a package > maintainer, can > modify the package in the transit. > * If you only sign the package file, a MITM that can break TLS for an user > can modify the trust > file in the transit
I don't understand what this is even saying. The author signature does not matter in the slightest if the trust file is compromised. > > >> It can also be mitigated with certificate pinning and online sign of the > >> trust file. > Google+Chrome > >> has shown that pinning is very effective for this specific use-case > >> (specific client > >> connecting to specific server). > > > > If we're relying on pinned certificates in order to fetch the trust file > > securely, then we can rely on it to securely transmit the package files. > > When I say *mitigation*, I mean “reducing the likeliness of an attack”. I’m > not saying > that certificate pinning fixes the attack altogether and thus makes > everything else > in the PEP useless. > > If you reduce the likeliness of a TLS MITM down to a level that you are > willing to accept > the risk, then you don’t need to expect a package singing proposal to work > also without > TLS. Assuming unbreakable perfect TLS, you still need package signing to > guard against > modification of files at rest; it’s true that an attacker that can alter > django.tar.gz > on PyPI/Fastly can probably also alter the trust file, but If you're relying on TLS to download the trust file securely, then the maximum security provided by that trust file is limited to that of TLS. This isn't an opinion it is a fact. > > 1) the trust file is publicly audited and append-only, so variations are far > easier to > notice (think of an external service monitoring the trust file and mailing to > maintainers > for each modification that appears there) > 2) trust file can also be manually handled; again think enterprises; > automatic deployments; > freezing in a virtualenv and only updated on explicit request and with > careful checking. This isn't really much better than TLS here again. It will protect against online compromise of a private index (vs a TLS connection) however that is a fairly minor use case and isn't worth the additional complexity. > 3) package signing still prevents attacks of package shadowing between > multiple indexes Well sometimes shadowing is what you want too (which I don’t think I saw here…), but I don't think it actually does cover this unless you prevent alternative indexes from having signed packages or you introduce a priority system, and if you introduce a priority system then you don't need signing to prevent that. > > You need package signing to enable these scenarios to even only exist and be > possible, > even if the default solution with the auto-updating trust-file is less secure > than our > final goals. > > >>> * Anyone able to defeat our TLS and is in a position to MITM a package > >>> author > >>> can simply register their own GPG key. > >> > >> The same happens with PEP458, for all packages but those in the “claimed" > >> role (which > >> requires manual vetting; this can be added to my proposal as well). > > > > Of course. I never said it didn't. The difference being that PEP 458 had a > > plan for this, and the current proposal doesn't. This is a flaw with > > anything > > that doesn't use some offline key or verification. However, as this proposal > > copies more things from PEP 458, I struggle to see the reason for having it > > over just doing PEP 458 (which I'm still not entirely sure is worth it). > > Well, you’re giving me a point. If you are saying that PEP458 and my PEP are > ultimately > equivalent for non vetted things, my PEP is far better as it’s several order > of magnitude > simpler for any of the involved parties (implementers, maintainers, ops, > auditors). My point is that without the offline verification the TUF PEP is completely uninteresting to me and I would not be willing to implement it and I would do everything I could to prevent it from being implemented. Your PEP lacks this and thus is completely uninteresting to me. > > If you care only about the security you get with offline verification, then > what about > changing my proposal to sign the trust file with an offline key (with pip > checking gpg > only for things in the trust file)? It's simpler, but in a broken way. The complexity that exists in TUF exists for a reason. I would suggest that you should take the time to understand TUF before proposing an alternative (going by your statements). > > PEP458 says that detailing offline verification is outside the scope of the > PEP. If you > think that’s the only reason the PEP exist, I don’t think that it’s correct > to declare > that it’s out of scope. We would need to say a concrete description of how an > offline verification > process would work at PyPI scale, with PSF staff and resources. Well it's not the *only* reason, there are other benefits to it, but I consider them additional benefits and not the primary driver for the PEP. To be completely clear, I don't consider PEP 458 to be a for sure thing either. It is the only proposal I've seen that even begins to be acceptable to me. I'm still unsure if the added cost (in terms of complexity) is worth it for what we get from it. I do think that it's the best proposal I've seen for this, and I'm unable to come up with a better solution. There's also the question of if we should do anything. Not signing packages is a completely reasonable end result if a solution that actually protects against more things than TLS in a meaningful way isn't found where the costs don't outweigh the benefits. > > >> This is fixed by 2FA. Notice that implementing 2FA but *not* package > >> signing is not > enough > >> to fix this attack; the attacker in fact would still be able to simply > >> modify a package > >> release in the transit, and the user would then 2FA-authorize a modified > >> package without > >> realizing it. > >> > >> This is one of many examples in which 2FA collaborates with package > >> signing to increase > >> security, and this is why I merged the two proposals; of course they can > >> be split, but > together > >> they achieve more. > > > > No, 2FA does nothing for this, if you're in a position to MITM an exploited > > TLS > > stream, you can just steal the session cookie which does not have a second > > factor. > > You’re thinking 2FA too conservatively, or I’m using the term “2FA” in a too > lateral meaning. > Think asking for an OTP to confirm an operation, not to login, e.g.: after a > package upload > or a GPG key change; the author would receive a SMS saying “confirm that your > new GPG key > is 123456789abcdef by entering code 671924”. It’s unlikely that we’ll end up in a situation where any change requires a confirmation. > > > > 3. If we implement our own it'll be TOTP, probably with a QR code yes. > > 4. Backup codes should exist yes. > > What about using only SMS instead? That would allow us to also use them for > confirmation > of security-related changes (e.g.: new package release), and could even be > integrated > with distutils prompts. I'd prefer not requiring a cell phone. I'm also not a huge fan of SMS over TOTP. This is where Duo Security is most interesting to me, since it provides mechanisms for: * Smart phones (with a nice push UX!) * "Dumb" phones (via SMS) * Literally any phone that can receive phone calls (via Dialing) * Hardware tokens That means that in order for someone to not be able to participate in 2FA they'd have to have absolutely no phone number. -- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
