Changes by Cory Benfield <c...@lukasa.co.uk>:
--
nosy: +Lukasa
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29870>
___
__
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
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
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
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
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.
Changes by Cory Benfield <c...@lukasa.co.uk>:
--
nosy: +Lukasa
status: pending -> open
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
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
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
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>
Changes by Cory Benfield <c...@lukasa.co.uk>:
--
nosy: +Lukasa
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue17305>
___
__
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
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
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
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
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
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
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
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>
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
Changes by Cory Benfield <c...@lukasa.co.uk>:
--
nosy: +Lukasa
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27766>
___
__
Changes by Cory Benfield <c...@lukasa.co.uk>:
--
nosy: +Lukasa
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27744>
___
__
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
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() #
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
Changes by Cory Benfield <c...@lukasa.co.uk>:
--
nosy: +Lukasa
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27706>
___
__
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
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
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
Changes by Cory Benfield <c...@lukasa.co.uk>:
--
nosy: +Lukasa
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27288>
___
__
Changes by Cory Benfield <c...@lukasa.co.uk>:
--
nosy: +Lukasa
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27292>
___
__
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 &
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
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
Changes by Cory Benfield <c...@lukasa.co.uk>:
--
nosy: +Lukasa
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27266>
___
__
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
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
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
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,
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
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
Cory Benfield added the comment:
Uh, sorry, I meant #26839.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27250>
___
___
Pyth
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
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
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
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
Changes by Cory Benfield <c...@lukasa.co.uk>:
--
nosy: +Lukasa
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26970>
___
__
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
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 <
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
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
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
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
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 <
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
90 matches
Mail list logo
