[Python-Dev] Enable Hostname and Certificate Chain Validation

[Jesse Noller]

> On Jan 22, 2014, at 5:30 AM, "M.-A. Lemburg" <mal at egenix.com> wrote:
> 
>> 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.

I have to concur with Donald here - in the case of security, especially language security which directly impacts the implicit security of downstream applications, I should not have to opt in to the most secure defaults.

Yes; this potentially breaks applications relying on insecure / loose defaults. However it changes the model to "you are by default, explicitly secure" then relying on the domain knowledge of an application developer to harden their application.

When, if this changes, an application breaks, it will be in a plainly obvious way which can quickly be resolved.

Donald is perfectly right: today, it's trivial to MITM an application that relies off of the current behavior; this is bad news bears for users and developers as it means they need domain knowledge to secure their applications by default they may not have.


> 
>>> 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/
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/jnoller%40gmail.com