[Python-Dev] Enable Hostname and Certificate Chain Validation

Benjamin Peterson benjamin at python.org
Wed Jan 22 15:39:48 CET 2014


On Wed, Jan 22, 2014, at 04:15 AM, Donald Stufft wrote:
> 
> On Jan 22, 2014, at 6:58 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> > On 22 January 2014 21:36, Donald Stufft <donald at stufft.io> wrote:
> >> On Jan 22, 2014, at 6:30 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> >>> 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.
> > 
> > You need to remember that *Python is fundamentally not an
> > application*. We don't control the interaction with the user,
> > application developers do, and every decision we make has to take that
> > into account.
> > 
> > The kinds of decisions that an application like a web browser or a
> > package installer can make aren't necessarily available to a runtime.
> > We had to be cautious even with the initial hash randomisation change
> > to avoid breaking currently working applications.
> 
> The same could be said for requests, it’s fundamentally not an
> application
> and can’t control the interaction with the user and yet it validates TLS
> by
> default just fine.

Speaking of requests, I think another way to address this issue would be
import a requests-like APIs into the stdlib (something which should
happen anyway) and make that verify certificates by default. This would
address the casual urllib-type usecase of fetching files over http/ftp
etc. (I expect most people using their own protocols over raw TLS
already know to force certificate verification.)


More information about the Python-Dev mailing list