On Jan 22, 2014, at 6:45 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> 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). I was actually talking to a Debian maintainer about the likelihood of making this change there earlier today :) If I fail at making this change in upstream I’ll be lobbying downstream and then we’ll just have different behaviors based on where you get your Python from which I think stinks. > > 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. Most of those add their private CAs to the system cert stores which would still work fine. I don’t think this change is one that users would be very upset about. We received very positive feedback in doing similar for Pip and we did break things for a few people. > > 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. Again speaking to the packaging tools, the switch to verifying SSL was very well tolerated, it was other changes that are unrelated this this proposal that have caused the bulk of the issues. > > 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. Calling this a “boil the ocean” type task is facetious. Yes securing the web as a whole would be like boiling the ocean, but enabling TLS validation by default is like basic 101 level. > > 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. This would be OK, obviously i’d prefer it to happen on as quickly as timeline as possible but like I said earlier I can totally see the need to have the deprecation process. > > 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 :) If a PEP is required for this I’ll write one. I have no idea what changes need a PEP or not and I default to not writing one because it’s easier :) > > 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!). Absolutely, the situation in 3.4 is way better, but it still relies on the people using the API to even know there is a problem and they get zero warning that they are likely doing it wrong. > > Cheers, > Nick. > > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ----------------- 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
