[Python-Dev] Enable Hostname and Certificate Chain Validation
wes.turner at gmail.com
Thu Jan 23 08:24:38 CET 2014
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
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:
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')
To use a bad metaphor: it's like the carrier piegeon stops on the way
home and there's no seal.
More information about the Python-Dev