Dima Tisnek added the comment:
Hopefully pep-466 resolves this for 2.x series.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5639
___
___
Dima Tisnek added the comment:
+dstufft is absolutely right.
SNI needs to be enabled on lower level than user python code. if it is,
requests and most other http client libs get it for free without dependencies.
--
___
Python tracker
Antoine Pitrou added the comment:
Nick: rather than direct users to use requests, we should direct them to use
Python 3, which has had SNI support for 3+ years now.
If client programs choose to remain on Python 2, it's *their* fault, not
Python's.
--
Dima Tisnek added the comment:
Antoine, was Python 2.x a mistake?
I don't think so.
SNI is not a language feature, it's not even a python extension feature.
It's a feature of and existing protocol and the underlying library.
--
___
Python tracker
Antoine Pitrou added the comment:
Antoine, was Python 2.x a mistake?
Really, can you stop arguing about this?
If you want to know what Python considers features and bug fixes, then
get acquainted with the development process instead of bickering.
--
Nick Coghlan added the comment:
I'm currently discussing some options with Donald and Christian. While it's
annoying that a developer from a certain large corporate user of Python (a
director of the PSF, no less) is whining at volunteers on the internet
instead of actually helping by encouraging
Antoine Pitrou added the comment:
I'm missing some context to appreciate your message, Nick, but please note that
SNI is not in itself a security feature. It just enables interoperability with
TLS virtual hosts (aka. hosting several TLS-enabled domains behind a single IP
and port).
Donald Stufft added the comment:
It's somewhat of a grey area of security feature. It's not directly a security
feature but if you don't have SNI and you hit a site that requires it then your
error message is going to be something like what people run into with PyPI[1]
which is Cannot verify
Antoine Pitrou added the comment:
Understood, but that's no different from trying to connect with an old Windows
or MSIE version (which I'm sure will also fail on some websites).
Client-side SNI support has been added in Python 3.2, and 3.4 is now out.
People who migrated their code to Python
STINNER Victor added the comment:
Please discuss the Python 2 documentation in a new issue, this one is now
closed and so hidden from the list of bugs.
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5639
Nick Coghlan added the comment:
I'd be happy to add a disclaimer to the Python 2.7 docs directing users to use
the requests module instead (https://pypi.python.org/pypi/requests).
People *really* *really* *really* should be using requests on the client side
when doing HTTP/HTTPS in Python 2.x
Donald Stufft added the comment:
To be clear, to get SNI with requests on 2.x you need requests, pyopenssl,
ndg-httpsclient, and pyasn1 (which also pulls in cryptography, six, cffi, and
pycparser). So that's 8 dependencies to get SNI on Python 2.x.
At least it's doable but it's kind of really
Sam Gleske added the comment:
Are you kidding me? I can't believe SNI isn't being backported to python 2.x.
This is ridiculous in my opinion. The bug fix needs to be back ported.
--
nosy: +sag47
versions: +Python 2.7, Python 3.1
___
Python
Mark Nottingham added the comment:
This is *not* a feature request, it's a bug fix in the underlying protocols.
Client sides that do not send SNI are actively hurting the Web and the Internet
by constraining the deployment of TLS.
The closest analogy would be if Python's HTTP client side
Dima Tisnek added the comment:
Is this really not going into Python2 series?
It's not a Python feature or a language feature, it's a matter of exporting
OpenSSL feature.
Furthermore it's a matter of security, same as support for session tickets is a
matter of performance.
SNI was first
Antoine Pitrou added the comment:
It's not a Python feature or a language feature, it's a matter of
exporting OpenSSL feature.
It's a feature regardless (from our POV), and Python 2.x has been in bug fix
mode for a long time now. Please understand that this is how our release
process works.
Changes by Mark Kubacki wm...@hurrikane.de:
Removed file: http://bugs.python.org/file30757/python-2.7.5-tlssni.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5639
___
Changes by Mark Kubacki wm...@hurrikane.de:
Added file: http://bugs.python.org/file30778/python-2.7.5-tlssni.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5639
___
Changes by Mark Kubacki wm...@hurrikane.de:
Removed file: http://bugs.python.org/file30778/python-2.7.5-tlssni.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5639
___
Changes by Mark Kubacki wm...@hurrikane.de:
Added file: http://bugs.python.org/file30779/python-2.7.5-tlssni.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5639
___
Changes by Mark Kubacki wm...@hurrikane.de:
Added file: http://bugs.python.org/file30757/python-2.7.5-tlssni.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5639
___
Mark Kubacki added the comment:
Python 2.7 is still used in production.
Given the scarcity of IPv4-addresses — and with CDNs (think: Amazon, Akamai,
EdgeCast…) starting to offer HTTP+SSL — the need for SNI arises in order to
avoid pitfalls such as shared certificates.
The lack of ubiquitous
Antoine Pitrou added the comment:
Mark, thanks for the patch. However, unless exceptional situations, we don't
backport features to bugfix branches.
The next Python 2.7 version will probably not be released before 2014, so even
if your patch were integrated, widespread deployment would still be
Mark Kubacki added the comment:
Antoine, thank you for the heads-up. As long as I've reminded distribution
maintainers of this issue and this or a similar patch (always send a
server_hostname with TLS, if one is missing) will be integrated (please do!)
I've accomplished my goal.
BTW, today
Dolf Andringa dolfandri...@gmail.com added the comment:
And python3? Any idea which version the patch will be included there?
This might be a good reason to finally take action on migrating my code from
python 2.7 to python 3.
On 11 August 2011 18:49, Antoine Pitrou rep...@bugs.python.org
Antoine Pitrou pit...@free.fr added the comment:
And python3? Any idea which version the patch will be included there?
It was included in Python 3.2.
--
versions: -Python 2.6, Python 2.7
___
Python tracker rep...@bugs.python.org
Dolf Andringa dolfandri...@gmail.com added the comment:
I see the patch has been applied python3 in r85793, but is there any chance
there will also be patches for python 2.6 or 2.7? And if so, what release of
python (any version) might this patch be included in?
--
nosy:
Antoine Pitrou pit...@free.fr added the comment:
I see the patch has been applied python3 in r85793, but is there any
chance there will also be patches for python 2.6 or 2.7
No, Python 2 only receives bug fixes.
--
___
Python tracker
Antoine Pitrou pit...@free.fr added the comment:
Committed with docs in r85793.
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5639
Antoine Pitrou pit...@free.fr added the comment:
Here is a patch for py3k, including http.client and urllib support.
--
Added file: http://bugs.python.org/file19327/sni.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5639
Changes by Scott Tsai scottt...@gmail.com:
--
nosy: +scott.tsai
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5639
___
___
Python-bugs-list
Antoine Pitrou pit...@free.fr added the comment:
Python's main job is to make it *possible* to do things. It's the
application developer's job to decide what things should be done.
It would be entirely appropriate, though, for a higher-level interface
(for example, the httplib module) to
Daniel Black dan...@cacert.org added the comment:
msg106323 - Author: Antoine Pitrou (pitrou) Date: 2010-05-22 20:17
I quite like your proposed alternative here. Not sure when/if I'll get to
implement this.
msg106324 - Author: Jean-Paul Calderone (exarkun) Date: 2010-05-22 22:17
Sorry I
Antoine Pitrou pit...@free.fr added the comment:
ctx = ssl.SSLContext(ssl.PROTOCOL_TLSv1)
ctx.set_tlsext_host_name(foo.bar)
Well, the hostname should be specific to a connection, so I'm not sure it makes
sense to set it on the context.
(besides, the OpenSSL APIs only allow it to be set on
Jean-Paul Calderone exar...@twistedmatrix.com added the comment:
Sorry I don't like this as much. I believe following the RFC for TLS SNI
should be implicit and not something the programmer need to put effort into
achieving. I acknowledge this approach does go against some explicit
Jean-Paul Calderone exar...@twistedmatrix.com added the comment:
Nope, I checked before making the suggestion. There's an SSL_CTX_ version of
this API (in addition to the SSL_ version).
Sorry, I just checked again, and it seems you're right. Perhaps I saw
Antoine Pitrou pit...@free.fr added the comment:
The patch probably needs refreshing now that first SSL contexts are in.
I wonder whether a combined boolean/string flag is really the best solution.
I think we could instead enable SNI by default and add an optional
server_hostname to set the
Jean-Paul Calderone exar...@twistedmatrix.com added the comment:
Here's another possible approach:
ctx = ssl.SSLContext(ssl.PROTOCOL_TLSv1)
ctx.set_tlsext_host_name(foo.bar)
skt = ctx.wrap_socket(socket.socket())
skt.connect(bar.baz)
This makes it obvious what the SNI hostname is and what the
Changes by Jesús Cea Avión j...@jcea.es:
--
nosy: +jcea
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5639
___
___
Python-bugs-list mailing list
Antoine Pitrou pit...@free.fr added the comment:
Too late for 2.7 now, but looks like a good idea.
--
nosy: +pitrou
priority: - normal
stage: - patch review
versions: -Python 2.7
___
Python tracker rep...@bugs.python.org
Daniel Black dan...@cacert.org added the comment:
Hey Phil,
(Sorry for dropping this, lost available time)
know the feeling :-(
use of SNI needs to be something that can be disabled
maybe. See small rational below:
and people need to be able to connect to host A while supplying host B
This
Phil Pennock python-...@spodhuis.org added the comment:
wrapssl(server_hostname=True/False/String) looks good to me.
Your arguments for enabling by default are compelling, for P3k.
--
___
Python tracker rep...@bugs.python.org
Daniel Black dan...@cacert.org added the comment:
The small deficiency with these patches is that the specified
server_hostname is almost always the hostname that is used in the socket
pair of connect. Is it appropriate to grab the hostname value and use it
in the SNI extension header?
Phil Pennock python-...@spodhuis.org added the comment:
(Sorry for dropping this, lost available time)
I see your point. OTOH, use of SNI needs to be something that can be
disabled and people need to be able to connect to host A while supplying
host B, not necessarily using IP addresses for
Daniel Black dan...@cacert.org added the comment:
patch against TRUNK (2.7) with self tests and doco. Essentially the same
code as pdp with a SSLv2 check before using the SNI extension.
Contains some spacing cleanups that where highlighted by vim.
--
nosy: +grooverdan
Added file:
Daniel Black dan...@cacert.org added the comment:
py3k version
--
Added file: http://bugs.python.org/file14809/python-3K-74602-ssl_client_sni.path
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5639
Changes by Daniel Black dan...@cacert.org:
--
versions: +Python 2.7, Python 3.2 -Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5639
___
Daniel Black dan...@cacert.org added the comment:
current self tests cannot fully test the existence of the SNI extension
as there is no server side support.
This client script run with argument sni.velox.ch will show the Great!
Your client its ClientHello: sni.velox.ch on the output.
New submission from Phil Pennock python-...@spodhuis.org:
With TLS it is possible to have the client use an extension (defined in
RFC 4366, and RFC 3546 before that) to indicate to the server which
hostname it believes it is talking to. The server can then choose TLS
certificates accordingly.
Phil Pennock python-...@spodhuis.org added the comment:
Note: this previous work is client-side only, as noted in the body of
the report. I'll look into what's needed for clean server-side support too.
--
___
Python tracker rep...@bugs.python.org
50 matches
Mail list logo
