On Jan 22, 2014, at 6:30 AM, M.-A. Lemburg <m...@egenix.com> wrote: > On 22.01.2014 11:56, Donald Stufft wrote: >> >> On Jan 22, 2014, at 5:51 AM, M.-A. Lemburg <m...@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 explicitly didn’t call it a security issue, but rather a security sensitive change, which it is. This would effectively be making Python more secure by default and removing a security related footgun. > >>> 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. I meant the statement that they should be switched to a well trusted certificate didn’t have much to do with this proposal. > > 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. It will just disable them by default, they can still easily be accessed you’d just need to pass the “do not verify” flag. This clearly indicates that you’re opting out of the S in HTTPS. > > 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. Again it’s not “locking out”, it’s simply “requires explicitly saying I want to not validate”. It’s hard to be more insecure than not verifying. Just about the only other way is to use plaintext but the only real difference there is passive vs attack attacks. However typically if you’re in the situation to do a passive attack you can also do an active attack. So “more insecure” is minorly more insecure while an error is drastically more secure. > > -- > 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/ ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
