http://convergence.io/ is a useful system. It provides protection against MITM attacks by using network perspective: you ask notary servers located elsewhere on the Internet to verify the certificate of a site you visit. If the notary servers see the same certificate you do then you know the local network is not being attacked; the MITM would have to be on PyPI's side of the network.
http://tack.io/ is another interesting system that allows a site to assert ownership of its own SSL certificate apart from the CA system. These systems are useful in a world where browsers trust hundreds of CAs to vouch for the identity of any site. Tack reminds me of the ssh security model in practice: in ssh, I usually trust keys the first time I see them, and SSH warns me when a host's key changes. This kind of security is very useful in practice; I would be more likely to accept a new SSH key when on my own network than at pycon and I might already have all the keys I need by the time I got there. On Mon, Feb 4, 2013 at 8:35 AM, Donald Stufft <[email protected]>wrote: > On Monday, February 4, 2013 at 8:31 AM, Giovanni Bajo wrote: > > Not that I'm against it doing it on the server side for now, anyway. It'll > still be useful to users manually browsing to PyPI. > > This is where it's important. If you're capable of MITM'ing pip you're > capable of MITM'ing a web browser. It would not be a fun day if a password > (or session cookie) got stolen via a MITM because someone signed on in a > coffee shop (or at Pycon etc). > > > _______________________________________________ > Catalog-SIG mailing list > [email protected] > http://mail.python.org/mailman/listinfo/catalog-sig > >
_______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
