Re: [Python-Dev] Enable Hostname and Certificate Chain Validation
Cory Benfield writes: > I'm overwhelmingly, dramatically +1 on this. There's no good > architectural reason to not use the built-in certificate chains by > default. I'd like to be in favour of backporting this change to earlier > Python versions as well, but it feels just a bit too aggressive. -1 This is just a bit too aggressive, too. I'll guarantee this breaks applications all over Japan, especially in universities because the Ministry of Education uses certificates rooted somewhere nobody's ever heard of, and typically don't bother to ensure the domain name matches the cert being presented. I've even run into such domain-match issues with banks (not banks I deal with any more, of course!) This is quite different from web browsers and other interactive applications. It has the potential to break "secure" mail and news and other automatic data transfers. Breaking people's software that should run silently in the background just because they upgrade Python shouldn't happen, and people here will blame Python, not their broken websites and network apps. I don't know what the right answer is, but this needs careful discussion and amelioration, not just "you're broken, so take the consequences!" ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enable Hostname and Certificate Chain Validation
Donald Stufft writes: > As an additional side note, anecdotal evidence and what not, but > *every* time I bring this up somewhere I get at least one reply > that looks similar to > https://twitter.com/ojiidotch/status/425986619879866368 Hey, wait a cotton-picking minute! Are you telling me that Perl, PHP, and Ruby *do* verify certs by default in their "batteries included" stdlibs, and developers using those languages have been turning that feature off in their code for, like, you know, well, for-EVER man!? (They surely don't leave it on, or my employer would have fixed their broken cert chain and hostnames by now.) If so, that's evidence for the practicality of the proposal, and maybe even for fast-tracking it to catch up. My employer and the Ministry of Education, Culture, Science, and Technology be damned (and they will be). But if it's only the already security-conscious developers and managers who go WTF?, and other environments don't do this by default, I'd consider that a "dangerous curve, slow down" sign. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enable Hostname and Certificate Chain Validation
Am 23.01.14 07:45, schrieb Scott Dial: > Anecdotally, I already know of a system at work that is using HTTPS > purely for encryption, because the authentication is done in-band. So, a > self-signed cert was wholly sufficient. The management tools use a > RESTful interface over HTTPS for control, but you are telling me this > will be broken by default now. What do I tell our developers (who often > adopt the latest and greatest versions of things to play with)? If they play with the newest version before actually using it in production, all is well. You can then tell them that they have four options: - not upgrade to the newest Python release (at least not until they are willing to pursue any of the other alternatives) - update the code to disable cert validation, or explicitly add the self-signed cert as a trusted one programmatically. - update the client system configuration, to add the self-signed certificate as trusted (system-wide or per user). - update the server, to use a cert signed by one of the trusted CAs. Regards, Martin ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enable Hostname and Certificate Chain Validation
On 23 January 2014 22:41, "Martin v. Löwis" wrote: > Am 23.01.14 07:45, schrieb Scott Dial: >> Anecdotally, I already know of a system at work that is using HTTPS >> purely for encryption, because the authentication is done in-band. So, a >> self-signed cert was wholly sufficient. The management tools use a >> RESTful interface over HTTPS for control, but you are telling me this >> will be broken by default now. What do I tell our developers (who often >> adopt the latest and greatest versions of things to play with)? > > If they play with the newest version before actually using it in > production, all is well. You can then tell them that they have > four options: > - not upgrade to the newest Python release (at least not until > they are willing to pursue any of the other alternatives) > - update the code to disable cert validation, or explicitly > add the self-signed cert as a trusted one programmatically. > - update the client system configuration, to add the self-signed > certificate as trusted (system-wide or per user). > - update the server, to use a cert signed by one of the > trusted CAs. Or, depending on the exact transition plan, potentially set: PYTHONSSLDEFAULT=NOVERIFY (akin to the "no, really, don't randomise the hashes" option). That's the kind of question a PEP would be needed to thrash out, though. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enable Hostname and Certificate Chain Validation
On Thu, 23 Jan 2014 01:45:15 -0500 Scott Dial wrote: > > Anecdotally, I already know of a system at work that is using HTTPS > purely for encryption, because the authentication is done in-band. So, a > self-signed cert was wholly sufficient. The management tools use a > RESTful interface over HTTPS for control, but you are telling me this > will be broken by default now. What do I tell our developers (who often > adopt the latest and greatest versions of things to play with)? That the system may be vulnerable to MITM attacks? (depending on how the authentication is done) Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enable Hostname and Certificate Chain Validation
On Thu, 23 Jan 2014 06:02:18 + Kristján Valur Jónsson wrote: > > If not already possible, I suggest that we allow the use of a certificate > validation callback > (it isn't possible for 2.7, I just hacked in one yesterday to allow me to > ignore out-date-failure for certificates.) > Using this, it would be possible to e.g. emit warnings when certificiate > failures occur, rather than deny connection outright. That's a possible transition measure indeed. Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enable Hostname and Certificate Chain Validation
On 2014-01-22 9:33 AM, Donald Stufft wrote:
> For everything but pip, you’d add it to your OS cert store. Pip doesn’t
> use that so you’d have to use the —cert config.
> What if I don't want that self-signed cert to be trusted by all users on
the system?
Specify a client cert and an appropriate CA bundle.
> What if I don't have administrative rights?
Specify an appropriate CA bundle for which there are appropriate permissions.
> How do I do it then? Is this common knowledge for average users? Are we
> trading one big
red box in the documentation for another?
That's really not the case.
Current web browsers are not susceptible to this particular issue.
> Anecdotally, I already know of a system at work that is using HTTPS
> purely for encryption, because the authentication is done in-band. So, a
> self-signed cert was wholly sufficient. The management tools use a
> RESTful interface over HTTPS for control, but you are telling me this
> will be broken by default now. What do I tell our developers (who often
> adopt the latest and greatest versions of things to play with)?
There are layers. OSI layers, if you prefer. It sounds like the
relevant layers here are:
* HTTP
* SSL/TLS
* TCP
A MITM compromise of the channel (e.g. by a rogue security tester
responding with a different SSL certificate that is not signed by a
CA, with a different hostname than requested) renders most 'in-band'
authentication mechanisms (such as HTTP Basic, Digest, and
Cookie-based Sessions) invalid.
'Higher layers' generally operate by sharing tokens as plaintext. With
SSL compromised through a MITM (as allowed by not validating hostnames
by default), said security tester could trivially intercept and modify
any of the requests and responses in the channel.
CWE-300: Channel Accessible by Non-Endpoint ('Man-in-the-Middle')
http://cwe.mitre.org/data/definitions/300.html
To use a bad metaphor: it's like the carrier piegeon stops on the way
home and there's no seal.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enable Hostname and Certificate Chain Validation
> But if it's only the already security-conscious developers and > managers who go WTF?, and other environments don't do this by default, > I'd consider that a "dangerous curve, slow down" sign. Mitigations: **Packaging** * Upgrade setuptools (distribute, zc.buildout) * Avoid easy_install, python setup.py install, and python setup.py develop (until it can be verified that the installed version of setuptools contains VerifyingHTTPSHandler [1]) https://bitbucket.org/pypa/setuptools/history-node/tip/setuptools/ssl_support.py * +1 for Pip install -e vcs+ssh://[email protected]/username/pkgname@semver@egg=pkgname * +1 for Conda * +1 for OS packages **Implementation** * Python < 3.4 : https://pypi.python.org/pypi/backports.ssl_match_hostname **Awareness** * Big red warning boxes: (.. warning:: in RST): Documentation * This must not be easy to test. * http://www.cvedetails.com/vulnerability-list/vendor_id-10210/product_id-18230/Python-Python.html -- Wes Turner On Thu, Jan 23, 2014 at 3:05 AM, Stephen J. Turnbull wrote: > Donald Stufft writes: > > > As an additional side note, anecdotal evidence and what not, but > > *every* time I bring this up somewhere I get at least one reply > > that looks similar to > > https://twitter.com/ojiidotch/status/425986619879866368 > > Hey, wait a cotton-picking minute! > > Are you telling me that Perl, PHP, and Ruby *do* verify certs by > default in their "batteries included" stdlibs, and developers using > those languages have been turning that feature off in their code for, > like, you know, well, for-EVER man!? (They surely don't leave it on, > or my employer would have fixed their broken cert chain and hostnames > by now.) > > If so, that's evidence for the practicality of the proposal, and maybe > even for fast-tracking it to catch up. My employer and the Ministry > of Education, Culture, Science, and Technology be damned (and they > will be). > > But if it's only the already security-conscious developers and > managers who go WTF?, and other environments don't do this by default, > I'd consider that a "dangerous curve, slow down" sign. > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Wrong keyword parameter name in regex pattern methods
Currently there is a mismatch between documented parameter names in some methods of regex pattern object. match(), search(), and fullmatch() (the last was added in 3.4) document first arguments as "string": match(string[, pos[, endpos]]) search(string[, pos[, endpos]]) fullmatch(string[, pos[, endpos]]) But actually they don't accept the "string" keyword parameter, by mistake it is named as "pattern" in the code. findall() and split() document first arguments as "string": findall(string[, pos[, endpos]]) -> list split(string[, maxsplit = 0]) But actually they don't accept the "string" keyword parameter, it is named as "source" in the code. The scanner() method is not documented and also has the "source" parameter. All other methods accepts the "string" argument as documented. The match object returned by match(), search(), fullmatch(), and finditer() methods and generated by the scanner, has the "string" attribute which is equivalent to the argument of these methods. Module level functions which corresponds to these methods have the "string" parameter. Due to all these facts I think that parameter names "pattern" and "source" are accidental mistakes and should be renamed to expected "string". Because this parameter is mandatory, apparently it is always used as positional parameter, and this error was not discovered long time. http://bugs.python.org/issue20283 ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enable Hostname and Certificate Chain Validation
On 01/22/2014 04:15 AM, Donald Stufft wrote: As I’ve said multiple times, I think it’s fine to send it through the deprecation process which is still pretty long and gives people a good chunk of time to update. Agreed. -- ~Ethan~ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enable Hostname and Certificate Chain Validation
On 01/22/2014 05:16 AM, M.-A. Lemburg wrote: On 22.01.2014 13:43, Jesse Noller wrote: Donald is perfectly right: today, it's trivial to MITM an application that relies off of the current behavior; this is bad news bears for users and developers as it means they need domain knowledge to secure their applications by default they may not have. I don't think you need much domain knowledge to insert a single line of code into applications to enable the checks. I find myself on the "dumb user" side of this argument, and I think it is much like the str/unicode transition of 3.0 -- which is it say, there are many who didn't understand unicode until forced to by 3.0, and likewise there will be many who don't understand security until forced to by enabling this new feature. One big difference is it's possible to opt-out of this security feature (which is a good thing, considering all the ill-configured systems out there). -- ~Ethan~ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Wrong keyword parameter name in regex pattern methods
On 1/23/2014 12:22 PM, Serhiy Storchaka wrote: Currently there is a mismatch between documented parameter names in some methods of regex pattern object. match(), search(), and fullmatch() (the last was added in 3.4) document first arguments as "string": match(string[, pos[, endpos]]) search(string[, pos[, endpos]]) fullmatch(string[, pos[, endpos]]) But actually they don't accept the "string" keyword parameter, by mistake it is named as "pattern" in the code. findall() and split() document first arguments as "string": findall(string[, pos[, endpos]]) -> list split(string[, maxsplit = 0]) But actually they don't accept the "string" keyword parameter, it is named as "source" in the code. The scanner() method is not documented and also has the "source" parameter. All other methods accepts the "string" argument as documented. The match object returned by match(), search(), fullmatch(), and finditer() methods and generated by the scanner, has the "string" attribute which is equivalent to the argument of these methods. Module level functions which corresponds to these methods have the "string" parameter. Due to all these facts I think that parameter names "pattern" and "source" are accidental mistakes and should be renamed to expected "string". Because this parameter is mandatory, apparently it is always used as positional parameter, and this error was not discovered long time. http://bugs.python.org/issue20283 I think we should correct the C code before we expose it more with clinic. Otherwise, help(re.x) will conflict with the re docs. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enable Hostname and Certificate Chain Validation
Wes Turner writes: > > But if it's only the already security-conscious developers and > > managers who go WTF?, and other environments don't do this by default, > > I'd consider that a "dangerous curve, slow down" sign. > > Mitigations: > > **Packaging** > > * Upgrade setuptools (distribute, zc.buildout) > * Avoid easy_install, python setup.py install, and python setup.py develop > (until it can be verified that the installed version of setuptools > contains > VerifyingHTTPSHandler [1]) Are you kidding? These *aren't* the apps that I care about breaking, and I know that the PHBs won't pay attention to what I say about fixing their sites and cert chains (believe me, I've tried, and the answer is as Paul Moore says: the users can punch the "go ahead anyway button," what's the big deal here?), they'll just deprecate Python. My question remains: > > Are you telling me that Perl, PHP, and Ruby *do* verify certs by > > default in their "batteries included" stdlibs, and developers using > > those languages have been turning that feature off in their code for, > > like, you know, well, for-EVER man!? I find that hard to believe, given that the security of the network remains broken yet there aren't warnings out to avoid these platforms. (BTW, my employer prides itself on being Matz's alma mater ... they actually might do something if Ruby was breaking things!) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enable Hostname and Certificate Chain Validation
On Jan 23, 2014, at 10:06 PM, Stephen J. Turnbull wrote: > Wes Turner writes: >>> But if it's only the already security-conscious developers and >>> managers who go WTF?, and other environments don't do this by default, >>> I'd consider that a "dangerous curve, slow down" sign. >> >> Mitigations: >> >> **Packaging** >> >> * Upgrade setuptools (distribute, zc.buildout) >> * Avoid easy_install, python setup.py install, and python setup.py develop >>(until it can be verified that the installed version of setuptools >> contains >> VerifyingHTTPSHandler [1]) > > Are you kidding? These *aren't* the apps that I care about breaking, > and I know that the PHBs won't pay attention to what I say about > fixing their sites and cert chains (believe me, I've tried, and the > answer is as Paul Moore says: the users can punch the "go ahead anyway > button," what's the big deal here?), they'll just deprecate Python. > > My question remains: > >>> Are you telling me that Perl, PHP, and Ruby *do* verify certs by >>> default in their "batteries included" stdlibs, and developers using >>> those languages have been turning that feature off in their code for, >>> like, you know, well, for-EVER man!? > > I find that hard to believe, given that the security of the network > remains broken yet there aren't warnings out to avoid these platforms. > (BTW, my employer prides itself on being Matz's alma mater ... they > actually might do something if Ruby was breaking things!) Ruby has verified the peer by default since Ruby 1.9 Go also verifies by default, I’m not aware if PHP or Perl do. - 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 [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enable Hostname and Certificate Chain Validation
On Jan 23, 2014, at 10:09 PM, Donald Stufft wrote: > > On Jan 23, 2014, at 10:06 PM, Stephen J. Turnbull wrote: > >> Wes Turner writes: But if it's only the already security-conscious developers and managers who go WTF?, and other environments don't do this by default, I'd consider that a "dangerous curve, slow down" sign. >>> >>> Mitigations: >>> >>> **Packaging** >>> >>> * Upgrade setuptools (distribute, zc.buildout) >>> * Avoid easy_install, python setup.py install, and python setup.py develop >>> (until it can be verified that the installed version of setuptools >>> contains >>>VerifyingHTTPSHandler [1]) >> >> Are you kidding? These *aren't* the apps that I care about breaking, >> and I know that the PHBs won't pay attention to what I say about >> fixing their sites and cert chains (believe me, I've tried, and the >> answer is as Paul Moore says: the users can punch the "go ahead anyway >> button," what's the big deal here?), they'll just deprecate Python. >> >> My question remains: >> Are you telling me that Perl, PHP, and Ruby *do* verify certs by default in their "batteries included" stdlibs, and developers using those languages have been turning that feature off in their code for, like, you know, well, for-EVER man!? >> >> I find that hard to believe, given that the security of the network >> remains broken yet there aren't warnings out to avoid these platforms. >> (BTW, my employer prides itself on being Matz's alma mater ... they >> actually might do something if Ruby was breaking things!) > > Ruby has verified the peer by default since Ruby 1.9 > > Go also verifies by default, I’m not aware if PHP or Perl do. Oh, Node.js also verifies by default, PHP apparently does not. - 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 [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python 3 marketing document?
Has anyone published a web page or wiki page about what's great about Python 3.x? ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
