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

@eighthave It is one of the many reasons why in PiRogue Tool Suite we decided to use another technique enabling TLS traffic decryption. Instead of using MITM proxy, we retrieve encryption keys directly from the device's memory: https://pts-project.org/guides/g8/#tls-traffic-decryption-techniques

@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

@eighthave I already managed to analyze apps using Safety Net. PiRogue comes with a Frida hook preventing root detection.

MITM proxy requires disabling certificate pinning enforced by almost all tracking SDKs. Disabling it requires modifying the app behavior, either by modifying its code or by using Frida hooks (rooted device).

Regarding ECH, the future will teach me if the technique we use in PiRogue works or not. AFAIK, ECH encrypts the handshake but has no impact on TLS encryption keys.