On Tue, Nov 24, 2015 at 10:08 AM, Paul Moore email@example.com wrote:
I'm not actually sure that it's the place of this PEP to even comment on what the long term answer for such environments should be (or indeed, any answer, long term or not). I've argued the position that in some organisations it feels like security don't actually understand the issues of carefully balancing secure operation against flexible development practices,
I agree with this.
but conversely it's certainly true that in many organisations, they *have* weighed the various arguments and made an informed decision on how to set up their internal network. It's entirely possible that self-signed certificates are entirely the right decision for their circumstances. Why would a Python PEP be qualified to comment on that decision?
I don't quite agree with this but it's probably moot in the face of the previous and certain cornercases. Self-signed certs work just fine with the backports to python-2.7.9+ but you have to add the ca to the clients. An organization that has weighed the arguments and made an informed decision to use self-signed certs should either do this (to prevent MITM) or they should switch to using http instead of https (because MITM isn't a feasible attack here). The cornercases come into play because you don't always control all of the devices and services on your network. The site could evaluate and decide that MITM isn't a threat to their switch's configuration interface but that interface might be served over https using a certificate signed by their network vendor who doesn't give out their ca certificate (simply stated: your security team knows what they're doing but your vendor's does not).
In my opinion, we should take all of the value judgements out of this paragraph, and just state the facts. How about:
""" In order to provide additional flexibility to allow infrastructure administrators to provide the appropriate solution for their environment, this PEP offers a way for administrators to upgrade to later versions of the Python 2.7 series without being forced to update their existing security certificate management infrastructure as a prerequisite. """
* python-2.7.9+ doesn't give you flexibility in this regard so organizations do have to update their certificate management infrastructure. The cornercase described above becomes something that has to be addressed at the code level. Environments that are simply misconfigured have to be fixed. So in that regard, a value judgement does seem appropriate here. the judgement is "Listen guys, this PEP advises redistributors on how they might provide a migration path for you but it *does not bandaid the problem indefinitely*. So long term, you have to change your practices or you'll be out in the cold when your redistributor upgrades to python-2.7.9+"
* Your proposed text actually removes the fix that I was adding -- this version of the paragraph implies that if your environment is compatible with the redistributors' python-2.7.8 (or less) then it will also be compatible with the redistributors' python-2.7.9+. That is not true. Whether or not we take out any value judgement as to the user's present environment this paragraph needs to be fixed to make it clear that this only affects redistributor's packages which have backported pep 476 to python-2.7.8 or older. Once the redistributor updates to a newer python sites which relied on this crutch will break.