On 2014-01-22 9:33 AM, Donald Stufft wrote:
> For everything but pip, you’d add it to your OS cert store. Pip doesn’t
> use that so you’d have to use the —cert config.

> What if I don't want that self-signed cert to be trusted by all users on
the system?

Specify a client cert and an appropriate CA bundle.

> What if I don't have administrative rights?

Specify an appropriate CA bundle for which there are appropriate permissions.

> How do I do it then? Is this common knowledge for average users? Are we 
> trading one big
red box in the documentation for another?

That's really not the case.

Current web browsers are not susceptible to this particular issue.

> Anecdotally, I already know of a system at work that is using HTTPS
> purely for encryption, because the authentication is done in-band. So, a
> self-signed cert was wholly sufficient. The management tools use a
> RESTful interface over HTTPS for control, but you are telling me this
> will be broken by default now. What do I tell our developers (who often
> adopt the latest and greatest versions of things to play with)?

There are layers. OSI layers, if you prefer. It sounds like the
relevant layers here are:

* HTTP
* SSL/TLS
* TCP

A MITM compromise of the channel (e.g. by a rogue security tester
responding with a different SSL certificate that is not signed by a
CA, with a different hostname than requested) renders most 'in-band'
authentication mechanisms (such as HTTP Basic, Digest, and
Cookie-based Sessions) invalid.

'Higher layers' generally operate by sharing tokens as plaintext. With
SSL compromised through a MITM (as allowed by not validating hostnames
by default), said security tester could trivially intercept and modify
any of the requests and responses in the channel.

CWE-300: Channel Accessible by Non-Endpoint ('Man-in-the-Middle')
http://cwe.mitre.org/data/definitions/300.html

To use a bad metaphor: it's like the carrier piegeon stops on the way
home and there's no seal.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to