[issue37952] Add support for export_keying_material to SSL library
Hans-Christoph Steiner added the comment: We're working on the HTTP Transport Auth draft (https://www.ietf.org/archive/id/draft-schinazi-httpbis-transport-auth-05.html) in the IETF that also needs this method. I would really love to see this land, any advice? If it is just a matter of updating the patch for the current Python, I can probably handle that. -- nosy: +eighthave ___ Python tracker <https://bugs.python.org/issue37952> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37952] Add support for export_keying_material to SSL library
Hans-Christoph Steiner added the comment: I understand the frustrations here, but this is really not a place to vent, since that only harms everyone's interests. When a core maintainer voices concerns or questions, they need to be addressed. This goes for any project. I'll see if I can contribute to https://bugs.python.org/issue43902, that would also work for exporting keying material. -- ___ Python tracker <https://bugs.python.org/issue37952> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43902] ssl module: add getter for SSL_CTX* and SSL*
Hans-Christoph Steiner added the comment:
This general idea sounds nice to have, I hope it can be included.
`ctx._call_with_ctypes("SSL_CTX_set_ciphersuites"...` also sounds totally
workable to me, if that has the best security profile.
Defense in depth is important, but it is not a reason to prevent key
functionality from landing. For example, "export_keying_material" is an RFC
and widely implemented (Go crypto/tls, Rustls, Conscrypt, nodejs, boringssl,
openssl, BouncyCastle, etc see links here
https://github.com/python/cpython/pull/25255#issuecomment-1073256270). It is
used in IETF protocols like SRTP and NTS.
Perhaps that could be a concrete use case here for thinking about the security
profile?
--
nosy: +eighthave
___
Python tracker
<https://bugs.python.org/issue43902>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43547] support ZIP files with zeroed out fields (e.g. for reproducible builds)
New submission from Hans-Christoph Steiner : It is now standard for Java JARs and Android APKs (both ZIP files) to zero out lots of the fields in the ZIP header. For example: * each file entry has the date set to zero * the create_system is always set to zero on all platforms zipfile currently cannot create such ZIPs because of two small restrictions that it introduced: * must use a tuple of 6 values to set the date * forced create_system value based on sys.platform == 'win32' * maybe other fields? I lump these together because it might make sense to handle this with a single argument, something like zero_header=True. The use case is for working with ZIP, JAR, APK, AAR files for reproducible builds. The whole build system for F-Droid is built in Python. We need to be able to copy the JAR/APK signatures in order to reproduce signed builds using only the source code and the signature files themselves. Right now, that's not possible because building a ZIP with Python's zipfile cannot zero out the ZIP header like other tools can, including Java. -- components: IO, Library (Lib) messages: 389040 nosy: eighthave priority: normal severity: normal status: open title: support ZIP files with zeroed out fields (e.g. for reproducible builds) versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43547] support ZIP files with zeroed out fields (e.g. for reproducible builds)
Hans-Christoph Steiner added the comment: I just found another specific example in _open_to_write(). 0 is a valid value for zinfo.external_attr. But this code always forces 0 to something else: if not zinfo.external_attr: zinfo.external_attr = 0o600 << 16 # permissions: ?rw--- -- ___ Python tracker <https://bugs.python.org/issue43547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43547] support ZIP files with zeroed out fields (e.g. for reproducible builds)
Hans-Christoph Steiner added the comment: > - For full reproducible builds you may have to write files to zipfiles in a > well-defined order. That already works fine now, we've been doing that with Python for years. But that leaves it up to the implemented to do. I suppose zipfile could provide a method to sort entries, but that's out of scope for this issue IMHO. -- ___ Python tracker <https://bugs.python.org/issue43547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45567] Support TLS Encrypted ClientHello (ECH)
New submission from Hans-Christoph Steiner : The next version of the IETF-standardized TLS protocol is known as Encrypted ClientHello (ECH) [1] formerly known as Encrypted SNI (ESNI). This ticket collects information for ECH support, and tracks which APIs have to be added to Python in order to implement ECH in Python's ssl module. ECH is built on top of TLSv1.3 and completes the unfinished work from the TLSv1.3 effort. It is now in draft-13 and there are many implementations that are interoperating. ECH is working for openssl[2], boringssl[3], nginx, Apache HTTPD, lighttpd, HAProxy, Conscrypt[4], curl, and more. There is work underway in Firefox [5] and Chromium [6]. It has been sketched out for OkHTTP [7]. Early versions of the standard, known as ESNI, have been deployed in Firefox releases and some production web services. ECH works in conjunction with the new DNS RR Types HTTPS and SVCB [8]. This means that DNS needs to be handled a bit differently. As far as I understand it, the ssl module has to gain additional features: 1. HTTPS/SVCB DNS queries for setting up TLS connection with ECH. 2. A way to provide ECH Config Lists as bytes directly to ssl clients. 3. A callback that gets called whenever ECH negotiation fails and the server offers a "Retry Config". 4. A method to ensure encrypted DNS is used so all metadata is encrypted. OpenSSL does not implement the necessary APIs yet. Stephen Farrell's development OpenSSL fork [9] implements ECH and has been used in Apache HTTPD, nginx, lighttpd, HAProxy, and curl implementations. The TLS WG maintain a page with information about other implementations: https://github.com/tlswg/draft-ietf-tls-esni/wiki/Implementations [1] https://www.ietf.org/archive/id/draft-ietf-tls-esni-13.html [2] https://github.com/openssl/openssl/issues/7482 [3] https://bugs.chromium.org/p/boringssl/issues/detail?id=275 [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1725938 [6] https://bugs.chromium.org/p/chromium/issues/detail?id=1091403 [6] https://github.com/google/conscrypt/issues/730 [7] https://github.com/square/okhttp/issues/6539 [8] https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-07.html [9] https://github.com/sftcd/openssl -- assignee: christian.heimes components: SSL messages: 404732 nosy: christian.heimes, eighthave priority: normal severity: normal status: open title: Support TLS Encrypted ClientHello (ECH) type: enhancement ___ Python tracker <https://bugs.python.org/issue45567> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45567] Support TLS Encrypted ClientHello (ECH)
Hans-Christoph Steiner added the comment: I agree with all you say, but I think it is important to not rule out handling HTTPS/SVCB DNS here. It can happen at a later stage though. What you propose works great for the first step. If handling the DNS is punted to some external library, that means that each client app will have to implement this itself, and its non-trivial. In that scenario, very few clients will implement it. This makes me believe that this should be implemented in the core. Granted, its an open question whether the ssl module is the right place. For example, it could makes more sense to handle HTTPS/SVCB DNS in the HTTP libs (urllib, requests, etc), but that means non-HTTP uses (XMPP, Matrix, etc) will be disadvantaged. -- ___ Python tracker <https://bugs.python.org/issue45567> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
