[Python-Dev] PYTHONHTTPSVERIFY env var

[Nick Coghlan]

On 11 May 2015 at 19:22, M.-A. Lemburg <mal at egenix.com> wrote:
> On 11.05.2015 11:13, Nick Coghlan wrote:
>> I wouldn't be opposed to seeing that as an upstream Python 2.7.x
>> feature, but agreement amongst redistributors on using a file-based
>> approach is the main outcome I'm looking for.
>
> Can't we have both ?

I'd strongly advise against it, as we're deliberately increasing the
attack surface area here by providing a potential path to carry out a
downgrade attack on the HTTPS certificate verification by forcing it
back to the old behaviour.

The main existing environment variable based attack vector would be to
manage to run a process with administrative privileges and
SSL_CERT_DIR and/or SSL_CERT_FILE pointing to a certificate written to
a user or world-writable directory by the attacker. Providing a "don't
verify HTTPS" flag at the interpreter level would let an attacker skip
the first step of writing the certificate file to disk somewhere,
making a system compromise harder to detect. (An especially paranoid
SSL implementation would disallow reading certs from locations that
allow write access to non-administrative users, but I don't believe
OpenSSL is that paranoid)

By contrast, the configuration file shouldn't provide a new attack
vector (or simplify any existing attack vector), as if you have the
permissions needed to modify the config file, you likely also have the
permissions needed to modify the system certificate store, and the
latter is a *far* more interesting attack vector than a downgrade
attack solely against Python.

Thus the environment variable based off switch is neither necessary
(as an administrator controlled configuration file can do the job),
nor sufficient (it can't handle the -E switch), *and* it represents an
increase in the attack surface area relative to a Python
implementation without the capability.

> I don't think that we can wait for a whole PEP process to
> run through

Matrix multiplication made it through the PEP process in 8 days. If we
do this as a redistributor recommendation rather than attempting to
get it into upstream Python 2.7, we could potentially propose you take
on the role of BDFL-Delegate and mark it as Accepted as soon as the
two of us agree on a common approach.

The reason I think that's a reasonable way forward is because we
already know there are folks opposed to making the change upstream. If
the PEP just provides recommendations for redistributors that *do*
decide to provide a "global off switch" to revert to the old
behaviour, then the perspective of the folks opposed to the feature is
respected by the fact that this is a feature some redistributors *may*
choose to add to provide a smoother migration path to more secure
default HTTPS handling, rather than something upstream provides by
default.

I assume the Debian, Ubuntu and Suse folks won't care, as they have
all already decided against backporting the change to their long term
support releases where the compatibility break would pose a problem
(and I can certainly sympathise with that perspective given the
dependency on backporting the PEP 466 SSL changes first, and the work
involved in seeking consensus on a smoother migration path from the
old default to the new one).

It would be nice to hear from ActiveState, Enthought & Continuum
Analytics as well, but if they don't chime in here, I don't see any
particular need to go chasing them explicitly.

>to fix this regression in 2.7.9.

We made the decision when PEP 476 was accepted that this change turned
a silent security failure into a noisy one, rather than being a
regression in its own right. PEP 493 isn't about disagreeing with that
decision, it's about providing a smoother upgrade path in contexts
where letting the security failure remain silent is deemed to be
preferred in the near term.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia