On Tue, 2 Sep 2014 22:16:18 +0000 (UTC) Alex Gaynor <alex.gay...@gmail.com> wrote: > > > Furthermore, "disable verification" is a nonsensical thing to do with TLS. > > > > It's not. For example, if you have an expired cert, all you can do > > AFAIK is to disable verification. > > It really is a nonsensical operation, accepting any random TLS certificate > without pinning or use of a certificate authorities makes a valid connection > completely indistinguishable from a MITM attack.
It's still distinguishable from a passively-eavesdroppable clear-text connection, though. > This whole scenario seems to be predicated on a siutation where: You have a > peer whose certificate you can't change, and you have a piece of code you > can't > change, and you're going to upgrade your Python installation, and you want to > talk to this peer, and you need to use an encrypted channel, but don't really > care if it's being MITM'd. It doesn't seem to me that this is reasonably > Python's responsibility to deal with the fact that you have no ability to > upgrade any of your infrastructure, except your Python version. Oh, I agree that whoever upgrades their Python version should be able to fix any of their applications should they start failing. That's why I don't want to let new command-line options and environment variables proliferate in the name of damage control. Regards Antoine. _______________________________________________ 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
