Il giorno 10/feb/2013, alle ore 12:45, M.-A. Lemburg <m...@egenix.com> ha scritto:
> Giovanni Bajo wrote: >> Il giorno 10/feb/2013, alle ore 00:43, M.-A. Lemburg <m...@egenix.com> ha >> scritto: >> >>> On 10.02.2013 00:13, Stephen Thorne wrote: >>>> Hello, >>>> >>>> One of my concerns with the recent pip dramas that have seen some excellent >>>> and timely action from catalog-sig and others, is that 'setuptools' is >>>> still widely distributed and used instead of distribute/pip. >>> >>> Just as data point: distribute isn't using HTTPS either and the >>> distribute bootstrap site doesn't work with HTTPS: >>> >>> http://python-distribute.org/ >>> >>> (https://python-distribute.org/ gives >>> "Error code: ssl_error_rx_record_too_long" in Firefox) >>> >>> By redirecting the PyPI main and mirror sites from HTTP to HTTPS >>> you can "upgrade" older installations. >> >> Alas, this redirection wouldn't fix the main issue, because a MITM can still >> proxy the connection, swallow the redirection, and insert a malware in the >> downloaded package. The only way to really fix it is to patch all PyPI >> clients, including distribute. > > The main problem at the moment is transferring passwords in > plain text :-) Exactly, and if you add HTTPS redirection, an attacker can still intercept the password in clear text while it's transmitted by the client. This is what I am saying: if you add HTTP->HTTPS redirection on the server, you are *not* fixing the main problem with old client at all. They are just as vulnerable as they are today. This is called ssl-stripping attack. The attacker intercept the first HTTP request, and forward it to the server; the server sends a 3xx redirect response, but the attacker *does not* forward it to the client; instead, they follow the redirection themselves, and estabilish a HTTTPS conneciton to the server. At this point, the server sends the real (redirected) content; the attacker gets the response (unwrapping SSL), and send it back as response to the client, that believes it's a clear-text response to the original request; moreover, they grep any existing HTTPS links in the request, and change them into HTTP, so the client will never estabilish a direct HTTPS connection by following a link. At this point, the attacker is talking HTTP to the client and HTTPS to the server, which means that they can intercept passwords in the cleartext. > >>> An alternative approach would be to make people more aware of >>> the possibility to configure the PyPI site URL in a distutils >>> config file (even globally) and changing the URL from HTTP >>> to HTTPS there: >>> >>> * distutils config files: >>> >>> http://docs.python.org/2/install/index.html#inst-config-files >>> >>> * setuptools: >>> >>> http://peak.telecommunity.com/DevCenter/EasyInstall#configuration-files >>> http://peak.telecommunity.com/DevCenter/EasyInstall#command-line-options >>> (the option is called --index-url) >>> >>> * distribute: >>> >>> http://pythonhosted.org/distribute/easy_install.html#configuration-files >>> http://pythonhosted.org/distribute/easy_install.html#reference-manual >>> (the option is called --index-url) >> >> >> The problem with this approach is that Python standard library does not >> validate SSL certificates. So even if you force a urllib-based tool to >> access PyPI through https, it doesn't help at all in case of a MITM attack. > > I know, but it's already a lot better than using HTTP (see above) :-) Again, I can't see how it is better. An attacker can do a MITM SSL proxy with an invalid certificate, the client will accept it, and thus read the passwords in plain text of the user. So, both of these baind-aids do *not* solve the "i will intercept the password" problem. I'm not saying that they should not be done. I'm saying that you shouldn't believe they give *any* security to old clients. -- 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
_______________________________________________ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
