[issue20188] ALPN support for TLS

2015-01-22 Thread Cory Benfield
Cory Benfield added the comment: Updating to note that OpenSSL 1.0.2 has been released[0], which makes this feature supportable. [0]: https://mta.openssl.org/pipermail/openssl-announce/2015-January/19.html -- ___ Python tracker rep

[issue23576] HTTPS reads can block when content length not available and timeout set.

2015-03-03 Thread Cory Benfield
New submission from Cory Benfield: Initially reported on the requests bug list at https://github.com/kennethreitz/requests/issues/2467 In cases when a remote web server sends a non-chunked response that does not have a content length, it is possible to get http.client to hang on a read

[issue23476] SSL cert verify fail for www.verisign.com

2015-03-01 Thread Cory Benfield
Cory Benfield added the comment: My reading of the OpenSSL issue is that there are no negative side effects from turning this on. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23476

[issue23476] SSL cert verify fail for www.verisign.com

2015-02-24 Thread Cory Benfield
Changes by Cory Benfield c...@lukasa.co.uk: -- nosy: +Lukasa ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23476 ___ ___ Python-bugs-list mailing

[issue23476] SSL cert verify fail for www.verisign.com

2015-02-24 Thread Cory Benfield
Cory Benfield added the comment: The problem specifically is that OpenSSL only uses a *root* in the trust store as an anchor. That means any certificate that is signed by another certificate will not terminate the chain of trust. Browsers do better here, by trusting the entirety of the trust

[issue23794] http package should support HTTP/2

2015-03-28 Thread Cory Benfield
Cory Benfield added the comment: I'm happy to talk about bringing hyper's HTTP/2 layer into http.client. It's worth noting that at this point I have no current plans to build a server into hyper, though if there was interest in using hyper as a baseline then I could take a swing

[issue23794] http package should support HTTP/2

2015-04-03 Thread Cory Benfield
Cory Benfield added the comment: figure out some kind of adapter interface in order to facilitate swapping between 1.1 and 2 (This can start with a clean HTTP/1.1 interface) I've been thinking about this a lot with hyper, and I'm about to start work on it (having just finished an alpha

[issue24107] Add support for retrieving the certificate chain

2015-05-01 Thread Cory Benfield
New submission from Cory Benfield: In order to perform HTTP Public Key Pinning (HPKP), it's necessary to have access to every certificate in the certificate trust chain. This is because the pinned key may actually be an intermediate or root certificate, rather than the leaf certificate

[issue23794] http package should support HTTP/2

2015-04-13 Thread Cory Benfield
Cory Benfield added the comment: I spoke to some people after my PyCon talk about this, and agreed that it would be a good idea to split out the framing and HPACK stuff from hyper to make it easier for people like aiohttp to prototype. The framing layer is already available from PyPI[0

[issue23989] Add recommendation to use requests to the documentation, per summit

2015-04-17 Thread Cory Benfield
Changes by Cory Benfield c...@lukasa.co.uk: -- nosy: +Lukasa ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23989 ___ ___ Python-bugs-list mailing

[issue24363] httplib fails to handle semivalid HTTP headers

2015-06-03 Thread Cory Benfield
Cory Benfield added the comment: It is obvious that this case could be treated as a folded (continuation) line. But in general I think it would be better to ignore the erroneous line, or to record it as a defect so that the server module or other user can check it. Just to clarify

[issue24363] httplib fails to handle semivalid HTTP headers

2015-06-03 Thread Cory Benfield
Cory Benfield added the comment: While we're here and I'm recommending to drop as little data as possible: we need to be really careful about not exposing ourselves to any kind of data smuggling attack here. It's really important that we don't let attackers construct bodies of requests

[issue24363] httplib fails to handle semivalid HTTP headers

2015-06-02 Thread Cory Benfield
Cory Benfield added the comment: This is one of those bugs that's actually super tricky to correctly fix. The correct path is to have the goal of conservatively accepting as many headers as possible. Probably this means looking ahead to the next few lines and seeing if they appear to roughly

[issue23670] Modifications to support iOS as a cross-compilation target

2015-07-27 Thread Cory Benfield
Changes by Cory Benfield c...@lukasa.co.uk: -- nosy: +Lukasa ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23670 ___ ___ Python-bugs-list mailing

[issue24667] OrderedDict.popitem() raises KeyError

2015-07-19 Thread Cory Benfield
Changes by Cory Benfield c...@lukasa.co.uk: -- nosy: +Lukasa ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24667 ___ ___ Python-bugs-list mailing

[issue25529] Provide access to the validated certificate chain in ssl module

2015-11-01 Thread Cory Benfield
New submission from Cory Benfield: I’m currently working on adding support for HPKP to the Requests and urllib3 modules. HPKP (HTTP Public Key Pinning), specified in RFC 7469, is an extension to HTTP that allows a web server to specify a whitelist of public keys that are valid for TLS

[issue17849] Missing size argument in readline() method for httplib's class LineAndFileWrapper

2015-09-03 Thread Cory Benfield
Cory Benfield added the comment: Martin, the idea of simply rejecting the LifeAndFileWrapper HTTP/0.9 fallback for _tunnel feels reasonable to me, that can work. Let me whip up an alternative patch that does that. -- ___ Python tracker <

[issue17849] Missing size argument in readline() method for httplib's class LineAndFileWrapper

2015-09-02 Thread Cory Benfield
Cory Benfield added the comment: Martin: as noted in the comments on this issue, I believed the specific test case did not match any of the problems people were encountering: it was just the least bad way to trigger the specific flow that was being encountered. In practice for these issues

[issue17849] Missing size argument in readline() method for httplib's class LineAndFileWrapper

2015-09-02 Thread Cory Benfield
Cory Benfield added the comment: Ok, new patch now attached. -- Added file: http://bugs.python.org/file40328/readline_2.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue17849] Missing size argument in readline() method for httplib's class LineAndFileWrapper

2015-09-03 Thread Cory Benfield
Cory Benfield added the comment: Ok, version three of the patch is now available. -- Added file: http://bugs.python.org/file40345/readline_3.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue25672] set SSL_MODE_RELEASE_BUFFERS

2015-11-20 Thread Cory Benfield
Cory Benfield added the comment: Thanks for the updated info Marc-Andre. Yeah, while generally speaking OpenSSL doesn't ship betas, it does provide them as tarballs. I have a beta of 1.0.2 floating around somewhere on my machine that I was using for ALPN testing back in 2014, and so I can

[issue25672] set SSL_MODE_RELEASE_BUFFERS

2015-11-20 Thread Cory Benfield
Cory Benfield added the comment: Good idea Benjamin. I've uploaded a second patch that adjusts the check to be a runtime one, rather than a compiled one. -- Added file: http://bugs.python.org/file41091/ssl2.patch ___ Python tracker <

[issue25672] set SSL_MODE_RELEASE_BUFFERS

2015-11-19 Thread Cory Benfield
Cory Benfield added the comment: Ok, I've just uploaded an initial draft of the patch for review. -- keywords: +patch Added file: http://bugs.python.org/file41083/ssl.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.p

[issue25672] Unconditionally set SSL_MODE_RELEASE_BUFFERS

2015-11-19 Thread Cory Benfield
New submission from Cory Benfield: Originally raised by Ben Bangert on the python-dev mailing list. It turns out that OpenSSL has a mode setting, SSL_MODE_RELEASE_BUFFERS, that can be set by a call to SSK_CTX_set_mode. This mode can potentially reduce connection overhead by nearly 18kB *per

[issue25672] Unconditionally set SSL_MODE_RELEASE_BUFFERS

2015-11-19 Thread Cory Benfield
Cory Benfield added the comment: Oh, one further requirement: we should *not* set this mode for OpenSSL releases 1.x through 1.0.1g, which have a NULL pointer dereference vulnerability (CVE 2014-0198). Thanks to Marc-Andre Lemburg for spotting this. See also: https://www.rapid7.com/db

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

2016-06-09 Thread Cory Benfield
Cory Benfield added the comment: > But Theodore Ts'o said on the tracker: if you call getrandom() and don't pass > in GRND_RANDOM, it's equivalent to /dev/urandom. So, if getrandom is > available, getrandom(flags=0) will always work and never block. Can we please try to be clear a

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

2016-06-09 Thread Cory Benfield
Cory Benfield added the comment: > Those say that if you call getrandom(GRND_NONBLOCK) before the entropy > pool has been initialized, it will return EAGAIN, but any time you read > from /dev/urandom you will always get random data. Yeah, so this is why the crypto folks were all u

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

2016-06-09 Thread Cory Benfield
Changes by Cory Benfield <c...@lukasa.co.uk>: -- nosy: +Lukasa ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27266> ___ __

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

2016-06-09 Thread Cory Benfield
Cory Benfield added the comment: > It looks like people don't read what I'm writing :-( I'm reading you, Victor, but you and I aren't disagreeing, so I'm not trying to convince you. =) I'm trying to convince Larry. -- ___ Python tracker &

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

2016-06-07 Thread Cory Benfield
Cory Benfield added the comment: > So you are intentionally accepting a new vector for DoS attacks, and calling this non-reduced security? This is only a DoS vector if you can hit the server so early in the boot process that it doesn't have enough entropy. The *second* enough entropy has b

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

2016-06-08 Thread Cory Benfield
Cory Benfield added the comment: > If you read #25003, it's clear that /dev/urandom is a well-known UNIX > facility with well-known, predictable behavior. One behavior that I'll draw > particular attention to now: it will never block. If the system is low on > entropy,

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

2016-06-08 Thread Cory Benfield
Cory Benfield added the comment: I have never seen it block in person, but I also wouldn't expect to. OS X's blocking guarantees are the same as FreeBSD's: that is, both /dev/random and /dev/urandom block until sufficient entropy has been gathered at startup and then never block again

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

2016-06-07 Thread Cory Benfield
Cory Benfield added the comment: > Python hash randomization only happens once. So it's not a matter of how > early we try the attack, it's a matter of how early we seed Python hash > randomization. Sorry Larry, I was insufficiently clear (relying on context from earlier). I tota

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

2016-06-08 Thread Cory Benfield
Cory Benfield added the comment: > What I'm trying to avoid here is the surprising situation where someone is > using Python on a system where /dev/urandom will never block, and > os.urandom() blocks. At this point I literally do not understand what issue we're trying

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

2016-06-08 Thread Cory Benfield
Cory Benfield added the comment: > You're right, it's remotely possible that on platforms where /dev/urandom > could block, Python startup could therefore also block. And I'm not > proposing we fix that, as so far nobody has reported it as a problem. > > This suggests to

[issue27250] Add os.urandom_block()

2016-06-07 Thread Cory Benfield
Cory Benfield added the comment: Marc-Andre: No. See the discussion in the related issue #27249 for more. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue27250] Add os.urandom_block()

2016-06-07 Thread Cory Benfield
Cory Benfield added the comment: Uh, sorry, I meant #26839. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27250> ___ ___ Pyth

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

2016-06-07 Thread Cory Benfield
Cory Benfield added the comment: This patch explicitly violates several of the documented constraints of the Python standard library. For example, random.SystemRandom uses os.urandom to generate its random numbers. SystemRandom is then used by the secrets module to generate *its* random

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

2016-06-07 Thread Cory Benfield
Cory Benfield added the comment: Victor Stinner: I found that comment to be pretty patronising, but I'm assuming that wasn't the intent. However, your characterisation of my comment was not as I intended it: when I said "because it can block", I meant because on almost every syst

[issue27250] Add os.urandom_block()

2016-06-07 Thread Cory Benfield
Cory Benfield added the comment: Let me make the security person argument even though you've dismissed it in your original post: Security should be on by default and opted out of, not the other way around. If the obvious choice is insecure then users who aren't careful enough won't notice

[issue27288] secrets should use getrandom() on Linux

2016-06-11 Thread Cory Benfield
Changes by Cory Benfield <c...@lukasa.co.uk>: -- nosy: +Lukasa ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27288> ___ __

[issue27292] Warn users that os.urandom() can return insecure values

2016-06-11 Thread Cory Benfield
Changes by Cory Benfield <c...@lukasa.co.uk>: -- nosy: +Lukasa ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27292> ___ __

[issue26970] Replace OpenSSL's CPRNG with system entropy source

2016-05-06 Thread Cory Benfield
Changes by Cory Benfield <c...@lukasa.co.uk>: -- nosy: +Lukasa ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26970> ___ __

[issue27766] Add ChaCha20 Poly1305 to SSL ciphers

2016-08-15 Thread Cory Benfield
Changes by Cory Benfield <c...@lukasa.co.uk>: -- nosy: +Lukasa ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27766> ___ __

[issue27766] Add ChaCha20 Poly1305 to SSL ciphers

2016-08-15 Thread Cory Benfield
Cory Benfield added the comment: Yup. So for Requests at least, the fix is easy: because OpenSSL kindly just quietly ignores cipher suites it doesn't know about we can unconditionally add it to the requests/urllib3 cipher string. In the first instance we'll just do it statically, and then we

[issue27744] Add AF_ALG (Linux Kernel crypto) to socket module

2016-08-12 Thread Cory Benfield
Changes by Cory Benfield <c...@lukasa.co.uk>: -- nosy: +Lukasa ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27744> ___ __

[issue27568] "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI scripts

2016-07-19 Thread Cory Benfield
Cory Benfield added the comment: I like this patch a great deal, I'll happily review it with docs and tests. -- nosy: +Lukasa ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue27568] "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI scripts

2016-07-19 Thread Cory Benfield
Cory Benfield added the comment: Ok, so I've taken a preliminary look at this patch. It looks good to me! I have one question: right now the patch as written will blow away not just HTTP_PROXY, but also any other mixed-case spelling of that name (e.g. HtTp_PrOxY) in a CGI environment. That's

[issue27716] http.client truncates UTF-8 encoded headers

2016-08-09 Thread Cory Benfield
Cory Benfield added the comment: Simple repro case: import http.client conn = http.client.HTTPConnection('pl.bab.la') conn.request("GET", '/slownik/angielski-polski/') resp = conn.getresponse() resp.read() #

[issue27716] http.client truncates UTF-8 encoded headers

2016-08-09 Thread Cory Benfield
New submission from Cory Benfield: Originally reported as Requests issue #3485: https://github.com/kennethreitz/requests/issues/3485 On Python 3, http.client uses the email module to parse its HTTP headers. The email module, for better or worse, requires that it parse headers as *text

[issue27716] http.client truncates UTF-8 encoded headers

2016-08-09 Thread Cory Benfield
Cory Benfield added the comment: Honestly, David, everything's a mess on this front. The authoritative document here is RFC 7230 Section 3.2.4 (https://tools.ietf.org/html/rfc7230#section-3.2.4). The last paragraph of that section reads: Historically, HTTP has allowed field content

[issue27706] Random.seed, whose purpose is purportedly determinism, behaves non-deterministically with strings due to hash randomization

2016-08-08 Thread Cory Benfield
Changes by Cory Benfield <c...@lukasa.co.uk>: -- nosy: +Lukasa ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27706> ___ __

[issue23794] http package should support HTTP/2

2016-06-30 Thread Cory Benfield
Cory Benfield added the comment: It occurs to me that I should update this issue to mention that the HTTP/2 parser I spoke about above now exists, and has existed for some time, as hyper-h2. It's available on PyPI: https://pypi.python.org/pypi/h2 It's fully spec-compliant, and already used

[issue27766] Add ChaCha20 Poly1305 to SSL ciphers

2016-08-15 Thread Cory Benfield
Cory Benfield added the comment: Update for Requests+urllib3 is here: https://github.com/shazow/urllib3/pull/947 Update for Twisted is here: https://twistedmatrix.com/trac/ticket/8760 -- ___ Python tracker <rep...@bugs.python.org>

[issue27766] Add ChaCha20 Poly1305 to SSL ciphers

2016-08-15 Thread Cory Benfield
Cory Benfield added the comment: Christian: Certainly I'd like to be able to use that API from within urllib3 and Twisted. Having something public would be really convenient. Of course, it'd be good if OpenSSL exposed something useful here, but in the absence of that Python would

[issue29136] Add OP_NO_TLSv1_3

2017-01-25 Thread Cory Benfield
Cory Benfield added the comment: For those who want to keep track, the relevant OpenSSL ticket for configuring TLSv1.3 cipher suites is https://github.com/openssl/openssl/issues/2276. -- nosy: +Lukasa ___ Python tracker <rep...@bugs.python.

[issue27850] Remove 3DES from cipher list (sweet32 CVE-2016-2183)

2016-09-08 Thread Cory Benfield
Cory Benfield added the comment: Thanks for your response Larry. I think it cleared up my understanding a bit, and I'm (extremely!) sympathetic to your desire to not get any closer to this problem than you have to. I think it may be worth, in future, defining what effort will be made

[issue28022] SSL releated deprecation for 3.6

2016-09-08 Thread Cory Benfield
Cory Benfield added the comment: 10/10, yes. I will happily provide code review for this. -- nosy: +Lukasa ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue22450] urllib doesn't put Accept: */* in the headers

2016-09-09 Thread Cory Benfield
Cory Benfield added the comment: So, leaping in on the Requests side of things for a moment, two notes. Firstly: copying curl is rarely a bad thing to do, especially for a behaviour curl has had for a long time. However, in this case the stronger argument is that just because the RFCs say

[issue27850] Remove 3DES from cipher list (sweet32 CVE-2016-2183)

2016-09-07 Thread Cory Benfield
Cory Benfield added the comment: > Future OpenSSLs don't affect Python 3.4, as Python 3.4 won't be upgraded to > them. Can I get a clarification on this, please, Larry? I just want to confirm I understand what your meaning is here. My reading of this is that for OpenSSL Python d

[issue27850] Remove 3DES from cipher list (sweet32 CVE-2016-2183)

2016-08-24 Thread Cory Benfield
Cory Benfield added the comment: As another data point, I just pushed a PR to remove HIGH from urllib3/requests for exactly this reason, and Twisted already doesn't use it. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.p

[issue27850] Remove 3DES from cipher list (sweet32 CVE-2016-2183)

2016-08-24 Thread Cory Benfield
Cory Benfield added the comment: +1 from me, Requests, urllib3, and Twisted are all removing 3DES cipher suites from our default list. -- nosy: +Lukasa ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue28570] httplib mishandles unknown 1XX status codes

2016-10-31 Thread Cory Benfield
Cory Benfield added the comment: 101 should probably be special-cased, because in that case the underlying protocol is being totally changed. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue28570] httplib mishandles unknown 1XX status codes

2016-10-31 Thread Cory Benfield
New submission from Cory Benfield: Long story short http.client does not tolerate non-100 or 101 status codes from the 1XX block in a sensible manner: it treats them as final responses, rather than as provisional ones. Expected behaviour ~~ When http.client

[issue28453] SSLObject.selected_alpn_protocol() not documented

2016-10-16 Thread Cory Benfield
Cory Benfield added the comment: Yeah, probably! There aren't many protocols with defined ALPN identifiers, but we should still probably explain how this works. Do you want me to write them? -- ___ Python tracker <rep...@bugs.python.org>

[issue17305] IDNA2008 encoding missing

2016-10-12 Thread Cory Benfield
Changes by Cory Benfield <c...@lukasa.co.uk>: -- nosy: +Lukasa ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17305> ___ __

[issue28938] match_hostname treats SAN IP address as DNS name and fails to check CN then

2016-12-11 Thread Cory Benfield
Changes by Cory Benfield <c...@lukasa.co.uk>: -- nosy: +Lukasa status: pending -> open ___ Python tracker <rep...@bugs.python.org> <http://bugs.pyt

[issue29870] ssl socket leak

2017-03-22 Thread Cory Benfield
Changes by Cory Benfield <c...@lukasa.co.uk>: -- nosy: +Lukasa ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29870> ___ __

[issue29781] SSLObject.version returns incorrect value before handshake.

2017-03-10 Thread Cory Benfield
Cory Benfield added the comment: I updated the test script to try with a file-descriptor set and OpenSSL returns TLSv1.2 for that one as well. This strongly suggests that OpenSSL's SSL_get_version documentation is somewhat misleading, and that an SSL object will return a version even when

[issue29781] SSLObject.version returns incorrect value before handshake.

2017-03-10 Thread Cory Benfield
New submission from Cory Benfield: The SSLObject object from the ssl module has a version() method that is undocumented. A reasonable assumption for the behaviour of that method is that it would follow the behaviour of the same method on SSLSocket(), which has the following documentation

[issue29781] SSLObject.version returns incorrect value before handshake.

2017-03-10 Thread Cory Benfield
Cory Benfield added the comment: A quick test reveals that Python 3.5 is also affected. -- versions: +Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue29781] SSLObject.version returns incorrect value before handshake.

2017-03-10 Thread Cory Benfield
Cory Benfield added the comment: This actually appears to be an outcome of OpenSSL's logic. I've attached a smallish C file that, when run against OpenSSL 1.0.2 on my machine, prints "TLSv1.2". This seems like a behaviour we'll have to work around in Python to get the outcome we

[issue19996] httplib infinite read on invalid header

2013-12-16 Thread Cory Benfield
Changes by Cory Benfield c...@lukasa.co.uk: -- components: Library (Lib) nosy: Lukasa priority: normal severity: normal status: open title: httplib infinite read on invalid header type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

[issue19996] httplib infinite read on invalid header

2013-12-16 Thread Cory Benfield
New submission from Cory Benfield: Initially spotted on Requests GitHub bugtracker: https://github.com/kennethreitz/requests/issues/1804 On receiving an HTTP response with an invalid header, httplib stops parsing the headers and attempts to receive the rest of the message as body content

[issue19996] httplib infinite read on invalid header

2013-12-16 Thread Cory Benfield
Cory Benfield added the comment: The easiest way to 'fix' the DoS problem is to throw an exception if an invalid header is parsed. That's a backwards-compatibility problem though: things that previously 'worked' now won't. That presumably limits the ability to back-apply this fix to 2.7.7

[issue19996] httplib infinite read on invalid header

2013-12-16 Thread Cory Benfield
Cory Benfield added the comment: Maybe. If we do it we have to apply that timeout to all the socket actions on that HTTP connection. This would have the effect of changing the default value of the timeout parameter on the HTTPConnection object from socket._GLOBAL_DEFAULT_TIMEOUT to whatever

[issue19996] httplib infinite read on invalid header

2013-12-16 Thread Cory Benfield
Cory Benfield added the comment: An update: in Python 2.7 through 3.3, fixing this should only affect http.client/httplib, because they do most of their header parsing themselves. Fixing this in later versions of Python is more interesting, as http.client got rewritten to use email.parser

[issue19996] httplib infinite read on invalid header

2013-12-16 Thread Cory Benfield
Cory Benfield added the comment: Actually, that might be OK. I don't know the email package at all, but I suspect being able to handle empty header keys (by ignoring them) is a reasonable thing to do in the email case as well. Thoughts

[issue19996] httplib infinite read on invalid header

2013-12-16 Thread Cory Benfield
Cory Benfield added the comment: Alright, here's a patch for the current tip. I'll need to prepare a different patch for earlier versions of Python, which will take me a little while longer to do (maybe not today). I've also signed a contributor agreement, but it doesn't look like that's

[issue19996] httplib infinite read on invalid header

2013-12-18 Thread Cory Benfield
Cory Benfield added the comment: Ok, here's a patch for 2.7 as well. I decided to allow the empty header names in rfc822.py as well, if only because I wanted the changed parsing code to match. If anyone thinks that's an excessive change, I'll happily remove it. -- Added file: http

[issue19996] httplib infinite read on invalid header

2014-01-11 Thread Cory Benfield
Cory Benfield added the comment: Is there anything I can do to help move this forward? I appreciate you're all busy so I'm happy for this to take as long as it takes, I just wanted to make sure it's not blocked behind me. -- ___ Python tracker rep

[issue17849] Missing size argument in readline() method for httplib's class LineAndFileWrapper

2014-01-17 Thread Cory Benfield
Cory Benfield added the comment: I've been messing around trying to write a test for this, and it looks like genuinely the only place this can be hit is in _tunnel(). None of the other readline() calls can be hit with the LineAndFileWrapper() wrapping the file descriptor. -- nosy

[issue17849] Missing size argument in readline() method for httplib's class LineAndFileWrapper

2014-01-17 Thread Cory Benfield
Cory Benfield added the comment: Alright, here's a patch. I'm not ecstatic about this test: it's utterly contrived, but it also seems to be the least bad way to reproduce this bug. Let me know if you strongly object and I'll take another swing at it (it'll probably involve extending

[issue16037] httplib: header parsing is unlimited

2014-03-12 Thread Cory Benfield
Changes by Cory Benfield c...@lukasa.co.uk: -- nosy: +Lukasa ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16037 ___ ___ Python-bugs-list mailing

[issue16037] httplib: header parsing is unlimited

2014-03-12 Thread Cory Benfield
Cory Benfield added the comment: I presume Barry's disinclination to merge this to 2.6 with a new exception applies equally to 2.7, which is why this hasn't been merged to 2.7 yet? I'm happy to review an updated 2.7 patch that raises an HTTPException if that's what we need to keep this moving

[issue21308] PEP 466: backport ssl changes

2014-04-19 Thread Cory Benfield
Changes by Cory Benfield c...@lukasa.co.uk: -- nosy: +Lukasa ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21308 ___ ___ Python-bugs-list mailing

[issue20188] ALPN support for TLS

2014-04-28 Thread Cory Benfield
Changes by Cory Benfield c...@lukasa.co.uk: -- nosy: +Lukasa ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20188 ___ ___ Python-bugs-list mailing

[issue10721] Remove HTTP 0.9 server support

2014-06-26 Thread Cory Benfield
Cory Benfield added the comment: To answer your question, Mark, RFC 7230 has removed the expectation that HTTP/1.1 servers will be able to support HTTP/0.9 requests. -- nosy: +Lukasa ___ Python tracker rep...@bugs.python.org http://bugs.python.org

[issue20188] ALPN support for TLS

2014-09-06 Thread Cory Benfield
Cory Benfield added the comment: Updating to mention a concern with ALPN implementation. HTTP/2 requires that a cipher with AEAD be negotiated. However, it also allows for offering a wider range of cipher suites: if an AEAD cipher is not present, this will allow fallback to HTTP/1.1. There's

[issue22638] ssl module: the SSLv3 protocol is vulnerable (POODLE attack)

2014-10-15 Thread Cory Benfield
Cory Benfield added the comment: I don't believe it's in OpenSSL though. There's an outstanding OpenSSL patch: http://marc.info/?l=openssl-devm=141333049205629w=2 However, as Donald has pointed out, this is really only meaningful for servers and co-operating clients. It's not a useful