[Catalog-sig] PyPI and setuptools

[Giovanni Bajo]

Il giorno 10/feb/2013, alle ore 12:45, M.-A. Lemburg <mal at egenix.com> ha scritto:

> Giovanni Bajo wrote:
>> Il giorno 10/feb/2013, alle ore 00:43, M.-A. Lemburg <mal at 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   ::  rasky at develer.com
Develer S.r.l.  ::  http://www.develer.com

My Blog: http://giovanni.bajo.it






-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4346 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20130210/5c0d4954/attachment.bin>