[Python-Dev] PEP 476: Enabling certificate validation by default! (original) (raw)
Antoine Pitrou solipsis at pitrou.net
Wed Sep 3 00:25:38 CEST 2014
- Previous message: [Python-Dev] PEP 476: Enabling certificate validation by default!
- Next message: [Python-Dev] PEP 476: Enabling certificate validation by default!
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Tue, 2 Sep 2014 22:16:18 +0000 (UTC) Alex Gaynor <alex.gaynor at 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.
- Previous message: [Python-Dev] PEP 476: Enabling certificate validation by default!
- Next message: [Python-Dev] PEP 476: Enabling certificate validation by default!
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]