On 22 January 2014 21:21, Paul Moore <p.f.mo...@gmail.com> wrote: > On 22 January 2014 10:30, Donald Stufft <don...@stufft.io> wrote: >> 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. > > Two things: > > 1. To be "like the browser" we'd need to use the OS certificate store, > which isn't the case on Windows at the moment (managing those > certificate bundle files is most definitely *not* "like the browser" - > I'd have no idea how to add a self-certificate to the bundle file > embedded in pip, for example). > 2. Your proposal is that because some application authors have not > opted in yet, we should penalise the end users of those applications > by stopping them being able to use unverified https? And don't forget, > applications that haven't opted in will have no switch to allow > unverified use. That seems to be punishing the wrong people.
Right, the browsers have a whole system of "click through" security to make the web (and corporate intranets!) still usable even when they only accept CA signed certs by default. With a programming language, there's no such interactivity, so applications just break and users don't know why. It's notable that even Linux distros haven't made this change in their system Python builds, and commercial Linux distros have raised paranoia to an art form (since that's a respectable chunk of what their users are paying for). We also have to account for the fact that an awful lot of Python applications are corporate ones relying on perimeter defence for security, or private CAs, or just self-signed certificates that their users have already accepted. There are limits to the amount of backwards incompatible change users will tolerate, and at this point in time we're still trying to get people to accept proper Unicode support. Even the package distribution tools are struggling with the consequences of trying to lock things down by default - every new release of pip currently brings someone else out of the woodwork pointing out they were relying on whichever insecure default we have changed on them this time. Securing the web is a "boil the ocean" type task - Python 3.4 takes us a step closer by making it possible for people to easily use the system certs via ssl.create_default_context() (http://docs.python.org/dev/library/ssl.html#ssl.create_default_context), but "move fast and break things" isn't going to work on this one any more than it does for proper Unicode support or the IPv4 to IPv6 transition. Security concerns are too abstract for most people for them to accept it as an excuse when you tell them you broke their software for their own good. The only before-Python-4 approach I can potentially see working is this: 1. Provide "ssl.create_default_context()" in 3.4 (done) 2. Deprecate the implicit SSL context in 3.5 3. Remove the implicit SSL context in 3.6 4. Make the default context the implicit context in 3.7 It would be slow, but we *could* get there. You *might* even be able to make the case for collapsing steps 3 and 4 together so that the more secure default is brought in as part of 3.6 in 2017. I'd suggest a PEP along those lines, but I think you already have plenty to keep you busy helping to ride herd on the packaging ecosystem :) In the meantime, making it so that it *is* just a single additional function call to get proper TLS security settings in 3.4 is a major step forward (thanks Christian!). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
