Changes by Cory Benfield :
--
nosy: +Lukasa
___
Python tracker
<http://bugs.python.org/issue29870>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
Cory Benfield added the comment:
A quick test reveals that Python 3.5 is also affected.
--
versions: +Python 3.5
___
Python tracker
<http://bugs.python.org/issue29
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
<http://bugs.python.
Changes by Cory Benfield :
--
nosy: +Lukasa
status: pending -> open
___
Python tracker
<http://bugs.python.org/issue28938>
___
___
Python-bugs-list mai
Cory Benfield added the comment:
101 should probably be special-cased, because in that case the underlying
protocol is being totally changed.
--
___
Python tracker
<http://bugs.python.org/issue28
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
<http://bugs.python.org/is
Changes by Cory Benfield :
--
nosy: +Lukasa
___
Python tracker
<http://bugs.python.org/issue17305>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
<http://bugs.python.org/issue28
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 ma
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
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
<http://bugs.python.org/is
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
<http://bugs.python.org/issue27
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 Pytho
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
<http://bugs.python.org/issue27
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, a
Changes by Cory Benfield :
--
nosy: +Lukasa
___
Python tracker
<http://bugs.python.org/issue27766>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Cory Benfield :
--
nosy: +Lukasa
___
Python tracker
<http://bugs.python.org/issue27744>
___
___
Python-bugs-list mailing list
Unsubscribe:
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()
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*:
that
Changes by Cory Benfield :
--
nosy: +Lukasa
___
Python tracker
<http://bugs.python.org/issue27706>
___
___
Python-bugs-list mailing list
Unsubscribe:
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.
T
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
<http://bugs.python.org/is
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 alrea
Changes by Cory Benfield :
--
nosy: +Lukasa
___
Python tracker
<http://bugs.python.org/issue27288>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Cory Benfield :
--
nosy: +Lukasa
___
Python tracker
<http://bugs.python.org/issue27292>
___
___
Python-bugs-list mailing list
Unsubscribe:
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.
--
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 tr
Changes by Cory Benfield :
--
nosy: +Lukasa
___
Python tracker
<http://bugs.python.org/issue27266>
___
___
Python-bugs-list mailing list
Unsubscribe:
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.
>
> Th
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 to s
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 blo
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
> entr
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
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 h
Cory Benfield added the comment:
Uh, sorry, I meant #26839.
--
___
Python tracker
<http://bugs.python.org/issue27250>
___
___
Python-bugs-list mailing list
Unsub
Cory Benfield added the comment:
Marc-Andre: No. See the discussion in the related issue #27249 for more.
--
___
Python tracker
<http://bugs.python.org/issue27
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
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
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 :
--
nosy: +Lukasa
___
Python tracker
<http://bugs.python.org/issue26970>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
<http://bugs.python.org/is
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:
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
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:
Ok, version three of the patch is now available.
--
Added file: http://bugs.python.org/file40345/readline_3.patch
___
Python tracker
<http://bugs.python.org/issue17
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
<h
Cory Benfield added the comment:
Ok, new patch now attached.
--
Added file: http://bugs.python.org/file40328/readline_2.patch
___
Python tracker
<http://bugs.python.org/issue17
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
Changes by Cory Benfield :
--
nosy: +Lukasa
___
Python tracker
<http://bugs.python.org/issue23670>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Cory Benfield :
--
nosy: +Lukasa
___
Python tracker
<http://bugs.python.org/issue24667>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 bo
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.
Jus
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 ro
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 certif
Changes by Cory Benfield :
--
nosy: +Lukasa
___
Python tracker
<http://bugs.python.org/issue23989>
___
___
Python-bugs-list mailing list
Unsubscribe:
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] and
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 f
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
tak
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. To
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
<http://bugs.python.org/issue23
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
Changes by Cory Benfield :
--
nosy: +Lukasa
___
Python tracker
<http://bugs.python.org/issue23476>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
<h
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-dev&m=141333049205629&w=2
However, as Donald has pointed out, this is really only meaningful for servers
and co-operating
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&#
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
<http://bugs.python.org/issue10
Changes by Cory Benfield :
--
nosy: +Lukasa
___
Python tracker
<http://bugs.python.org/issue20188>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Cory Benfield :
--
nosy: +Lukasa
___
Python tracker
<http://bugs.python.org/issue21308>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
Changes by Cory Benfield :
--
nosy: +Lukasa
___
Python tracker
<http://bugs.python.org/issue16037>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 proba
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.
--
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.
--
___
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.
--
A
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
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. Tho
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:
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:
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
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
Changes by Cory Benfield :
--
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
___
Python
90 matches
Mail list logo
