[Python-Dev] Enable Hostname and Certificate Chain Validation

[M.-A. Lemburg]

On 22.01.2014 11:56, Donald Stufft wrote:
> 
> On Jan 22, 2014, at 5:51 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> 
>> On 22.01.2014 11:30, Donald Stufft wrote:
>>> I would like to propose that a backwards incompatible change be made to Python to make
>>> verification of hostname and certificate chain the default instead of requiring it to be opt
>>> in.
>>>
>>> Python 3.4 has made great strides in making it easier for applications to simply turn on these
>>> settings, however many people are not aware at all that they need to opt into this. Most assume
>>> that it will operate similarly to their browser, curl, wget, etc and validate by default and
>>> in the typical style of security related issues it will appear to work just fine however be
>>> grossly insecure.
>>>
>>> In the real world “opt in security” typically translates to just plain old insecure for the
>>> bulk of applications/libraries. I believe that Python has a responsibility to do the right
>>> thing by default here and it is in the best position to do so. The alternative requires every
>>> Python developer who wants to access a secure resource to be educated on the fact that they
>>> need to flip some switch to do what most of them would expect.
>>
>> Such a change would introduce considerable breakage. This would either
>> have to be done using our usual pending deprecation, deprecation, removal
>> dance (over three releases) or be postponed until Python 4.
> 
> I can understand the need for doing the typical deprecation dance, although
> I believe such policies are often overlooked or accelerated for security
> sensitive changes. I do believe that waiting until Python 4 would be doing
> a great disservice to the users of Python though.

Well, it's not really a security issue, since the security features
are present in Python 3.4. It's just that the user has to enable them.

>> Note that several python.org services use CAcerts which would no
>> longer be accessible per default following such a change.
> 
> Not that it has much to do with this proposal, but those services should
> be switched to use certificates that are well trusted.

Oh, it does have to do with the proposal, since it's a prominent
example of services that would no longer work. While we can potentially
change the situation for python.org servers, you have the same issues
with other services which we don't have any influence on.

The change would also disable all services using self-signed
certificates which are very common in internal networks and
for ad-hoc setups. Many routers and other devices use self-signed
certificates when offering HTTPS services.

I think overall, it's good to have default security, but locking out
all certificates which do not have their root CA certs installed
in default installations of systems per default would likely lead to
people seeking other more insecure ways of getting things to work,
rather than asking their admins to add their CA certs to the certificate
chain configuration. So I'm not sure whether raising errors is the
best way to achieve better default security. Perhaps just using
warnings would be better.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 22 2014)
>>> Python Projects, Consulting and Support ...   http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ...       http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/