Il giorno 29/lug/2014, alle ore 00:26, Donald Stufft <don...@stufft.io> 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 >> 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 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. 3) package signing still prevents attacks of package shadowing between multiple indexes 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). 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)? 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. >> 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”. [I’ve cut the rest as we’re reiterating the same 2-3 points discussed above] >> >>> Implement 2FA/Better Authentication >>> ----------------------------------- >>> >>> Absolutely, we don't need a PEP to do this, we just need to do it. It's on >>> my >>> personal TODO list but other things have had higher priority thus far. >> >> Maybe not a PEP, but some discussion is needed. >> >> Would you prefer patches against PyPI or warehouse? Would you evaluate a >> simpler solution >> using a third-party 2FA provider (e.g.: Authy or Duo Security) that could be >> talked into >> a PSF sponsorship, or would you prefer an in-house solution? If in-house, is >> it OK to go >> with a standard OATH TOTP with QR Code for provisioning, or you prefer to >> also have alternatives >> like SMS? How do you propose to handle recovery for a lost token (e.g.: >> stolen smartphone >> with no backup)? Would you ask for the token for all web logins? What about >> package uploads: >> should distutils be modified to also ask for 2FA in interactive mode on the >> terminal, >> to confirm a package release? > > 1. PyPI v Warehouse, if you want to implement it now, PyPI and Warehouse. I > haven't done it yet because I don't want to implement it on PyPI-Legacy and > I'm waiting until Warehouse is deployed. > > 2. I've looked at Duo Security. I'm not completely opposed to it, I know there > are some who are. It has nice feature sets especially with alternative > means of 2FA. > > 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. > 5. If a person has 2FA enabled on their account it should be required for any > web login. Packages should also be able to mandate that a person has 2FA > for > manipulating that package. > > 6. distutils is the hard part here. We can't modify distutils for 2.6, and for > 2.7, 3.2, 3.3, and 3.4 it'll be hard to do. -- Giovanni Bajo :: ra...@develer.com Develer S.r.l. :: http://www.develer.com My Blog: http://giovanni.bajo.it
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
