[Python-Dev] Request for pronouncement on PEP 493 (HTTPS verification backport guidance)

[Paul Moore]

On 24 November 2015 at 18:37, Toshio Kuratomi <a.badger at gmail.com> wrote:
> 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).

There's an assumption (which is untrue for the big organisations I'm
familiar with) that security are involved with the full stack -
typically in my experience "corporate security" set rules that are
filtered down through many layers, and development teams have no
influence on those decisions - conversely, the people setting security
policies aren't aware of the details of development day to day needs.

It's easy to say that users just click on the "allow" button in their
browser if they want to use self-signed certificates, but not have any
viable solution for automation code that doesn't use a browser - and
such automation code is "not corporately supported", so policy won't
get updated to address the disconnect.

> 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).

This sounds like a similar situation to what I described above. I'm
not sure I'd see these as corner cases, though - they are pretty much
day to day business in my experience :-(

>> 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.
>> """
>
> Two notes:
>
> * 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+"

Hmm, maybe I misread the PEP (I only skimmed it - as I say, Linux is
of limited interest to me). I thought that the environment variable
gave developers a "get out" clause. Maybe it's not what we want them
to do (for some value of "we") but isn't that the point of the PEP?

Admittedly if distributions don't *implement* that part of the PEP
(and I understand Red Hat haven't) then people are still stuck. But
"this PEP offers a way" is not incompatible with "your vendor didn't
implement the PEP so you're still stuck, sorry"...

> * 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.

Sorry for that. Certainly getting the facts right is crucial, and it
looks like my suggestion didn't do that. But hopefully someone can fix
it up (if people think it's a good way to go).

Paul