Stéphane Bortzmeyer<p><a href="https://mastodon.gougere.fr/tags/IETF" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IETF</span></a> </p><p>Argh, le futur RFC sur l'exportation des clés <a href="https://mastodon.gougere.fr/tags/TLS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>TLS</span></a> (SSLKEYLOGFILE), qui avait été approuvé, a été retiré de la file d'attente des RFC. Vu le retard pris, il fallait lui ajouter les derniers trucs (notamment <a href="https://mastodon.gougere.fr/tags/ECH" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ECH</span></a>). </p><p>Bref, ce n'est pas encore normalisé. (Alors que c'est crucial pour le déboguage, cf. mon talk à Capitole du Libre <a href="https://cfp.capitoledulibre.org/cdl-2022/talk/P79YC7/" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">cfp.capitoledulibre.org/cdl-20</span><span class="invisible">22/talk/P79YC7/</span></a> )</p>
#ech
0 posts0 participants0 posts today
Replied in thread
#curl Encrypted Client Hello (#ECH) support is progressing: https://github.com/curl/curl/pull/11922 - Encrypted Client Hello ensures that the server name is not visible in clear text during the TLS connection establishment. This is great for #privacy as it will make it harder to track which sites are visited, at least if the sites are hosted on some shared IP addresses.
There of course are also counterarguments against ECH in certain settings. For example some #IDS solutions that inspect SNI of TLS connections made by compromised hosts would get reduced visibility. It is likely that some orgs will take steps to block ECH in their networks.
GitHubECH experimental by sftcd · Pull Request #11922 · curl/curl
Replied in thread
@CCC this gives me renewed energy for continuing to work on #TLS #EncryptedClientHello (#ECH).
Replied in thread
@ianonymous3000 @privacytests @mullvadnet @torproject unless those browsers have enabled Encrypted Client Hello (#ech) as well, then all this is just #fake #privacy. And please, #DNS resolution should be provided by the OS and that should make it encrypted. Not browsers or each application.
As part of #ISRG's work towards memory-safe infrastructure for the internet, @cpu has opened a merge request that implements TLS ECH support on the client side:
https://github.com/rustls/rustls/pull/1718
We agree that "the ECH spec is very challenging to implement and required a lot of trial/error" and we are working with #DEfO to help implementers. Please reach out if that is you:
https://defo.ie/#contact
GitHubWIP: Encrypted Client Hello support (client only) by cpu · Pull Request #1718 · rustls/rustls
For people asking why Encrypted Client Hello is so important:
Even if you are using DOH (or ODoH), your ISP can see what websites your visiting (and then sell to NSA) by inspecting the certificate SNI field. Even with Encrypted SNI (ESNI), there are artifacts of the TLS session establishment leaked that can be used for TLS Fingerprinting - things like ALPN, and cipher suite.
TechCrunch · NSA is buying Americans' internet browsing records without a warrant | TechCrunch"Web browsing records can reveal sensitive, private information about a person based on where they go on the internet," said Sen. Ron Wyden.
@Codeberg as part of https://defo.ie, we are assisting free software projects of all kinds to implement #EncryptedClientHello (#ECH). This would hide the domain that users are connecting to, e.g. codeberg.org, *.codeberg.page, etc. If you are interested, let me know and I'll see what we can do to help.
defo.ieDeveloping ECH for OpenSSL (DEfO) - welcome to defo.ie
Our #HKPE (RFC9180) implementation shipped by #OpenSSL has been audited, and passed with flying colors: "Auditors did not identify any directly exploitable vulnerabilities". Nice work, Stephen Farrell!
https://7asecurity.com/blog/2023/12/defo-2-openssl-hpke-pr-security-audit/
https://www.opentech.fund/security-safety-audits/defo-2-openssl-hpke-pr-security-audit/
7ASecurity Blog · DEfO-2 OpenSSL HPKE PR Security Audit - 7ASecurity BlogDEfO-2: OpenSSL's ECH implementation passed a security audit by 7ASecurity, addressing privacy concerns. No exploitable vulnerabilities found, & 10 low-severity issues were fixed in the latest release.
We hit a major new milestone our DEfO partnership project to accelerate adoption of #TLS Encrypted ClientHello (#ECH): Stephen Farrell made a pull request to #OpenSSL with a complete, working implementation: https://github.com/openssl/openssl/pull/22938
GitHubECH-PR by sftcd · Pull Request #22938 · openssl/openssl
Replied in thread
@U039b interesting, nice approach. Have you looked at how to do that with #ECH? It uses a new public key that is generated using https://www.rfc-editor.org/rfc/rfc9180.html
Also, will that work with apps that use #SafetyNet etc so they refuse to run on rooted devices? It seems for those apps, we still need a way to use something like #MITMproxy, e.g. inserting a custom CA cert. But the ECH key is not related to any CA cert.
If you have detailed questions about ECH, please ask here or on https://matrix.to/#/#ech-dev:matrix.org
www.rfc-editor.orgRFC 9180: Hybrid Public Key Encryption
This document describes a scheme for hybrid public key encryption (HPKE).
This scheme provides a variant of public key encryption of arbitrary-sized
plaintexts for a recipient public key. It also includes three authenticated
variants, including one that authenticates possession of a pre-shared key
and two optional ones that authenticate possession of a key encapsulation
mechanism (KEM) private key. HPKE works for any combination of an asymmetric
KEM, key derivation function (KDF), and authenticated encryption with
additional data (AEAD) encryption function. Some authenticated variants may not
be supported by all KEMs. We provide instantiations of the scheme using widely
used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key
agreement, HMAC-based key derivation function (HKDF), and SHA2.
This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.
One thing about #EncryptedClientHello (#ECH) that I'm a little worried about is that it will make #MITM inspection of #TLS traffic harder to the point where it might restrict lots of important kinds of inspection. When the software we use is not #FreeSoftware, then we cannot see what it is doing by reading the source code. We need to inspect the network traffic. So it is very important that it is possible to inspect traffic that uses ECH as well, despite that middleware companies will abuse this