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
@U039b ECH just affects ClientHello, the rest of the TLS session should remain the same. If the ClientHelloInner cannot be decrypted, then the actual domain name remains hidden. That could be important with CDNs, e.g. is the client app connecting to badtracker.com or cloudflare-ech.com? In that case, it might be possible to get the domain name by MITMing the DNS but not guaranteed. The client could store IP addresses to avoid leaking DNS to avoid detection. I think Facebook's app does this.
@U039b For HTTP that would require things work without the Host: header, I wonder if any CDNs would use the domain name from ClientHelloInner if Host: was missing?
@eighthave I don't know.
@U039b FYI it should be possible for MITMproxy or things like it to work with ECH, but they will need to intercept the DNS and know how to process HTTPS RR types.
@eighthave Ok, thank you for this detail.
@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.