On Sat, Jun 29, 2024 at 9:37 PM Max Nikulin <maniku...@gmail.com> wrote: > > On 30/06/2024 03:45, Jeffrey Walton wrote: > > On Sat, Jun 29, 2024 at 4:13 PM Lee wrote: > >> > >> [...] Debian firefox does NOT allow one to do > >> TLS intercept - ie. this does not work: > >> C:\UTIL>cat firefox-tlsdecode.bat > >> set SSLKEYLOGFILE=C:\Users\Lee\AppData\Local\Temp\FF-SSLkeys.txt > >> start C:\"Program Files\Firefox\Firefox.exe" > [...] > > I'm not sure who your complaint is against -- Debian, Firefox or > > Linux. I'm also not sure that it is a valid complaint. > > I do not mind to see a link stating that the appropriate logger is > really disabled. Certainly dumping of TLS session keys may be disabled > through a compile time flag similar to enforcing signatures for add-ons. > It may be default Firefox configuration for release builds or some line > in Debian build rules. It still might be some mistake during attempts to > enable the logger. I have read about this approach but I have never > tried it in action. > > > Firefox uses its own certificate store. > > It is relevant to active traffic interception you described (a proxy). > Lee prefers passive traffic sniffing and it requires cooperation from a > peer to get session keys. Each case has its own advantages.
As far as I know, the browsers support active interception. That is, "interception is a valid use case" for the browsers to support Dataloss Prevention (DLP) programs. The browsers do that through the use of interception proxies and root CA's used in the DLP program. Browsers do not support the passive capture/replay that OP wants. That is, they don't support exporting the premaster secret or the derived master secret. The browsers use tortured logic to arrive at "interception is a valid use case". They hang it off of the W3C's Design Principles and Priorities of Constituencies. The browser's argument goes as such: if a user did not want to be intercepted, then the CA certificate used for interception would not be present in the certificate store. Since the proxy's interception certificate is present in the store, the user wants to be intercepted. (You can't make this shit up). A corollary to "interception is a valid use case" is, webapps can never be sure they have a secure channel. Therefore, webapps can only handle low value data. Higher value data should be handled by hybrid and native apps. > At first it was not clear to me that having TLS private key (copied from > the server) is not enough for passive traffic decryption. Diffie-Hellman > key exchange scheme allows to generate secret keys even over public > channel... Correct. You also need ClientHello.random and ServerHello.random since the master secret is computed from (https://datatracker.ietf.org/doc/html/rfc5246#section-8.1): master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random) [0..47]; Something some folks don't realize is, ClientHello.random and ServerHello.random are also used for key transport schemes like RSA, when the client encrypts the premaster secret and sends it to the server. The ClientHello.random and ServerHello.random are present to ensure both sides contribute to the master secret. Otherwise, only the client would contribute to the master secret in a key transport scheme. > The main purpose of TLS certificates (public keys in the > browser or system store) is to confirm that there is no attacker in > between that blocks packets from the client and establishes its own > connection to the server. No, not quite. Interception is a valid use case under the browser's security model. You can achieve what you are getting at, but you need to use hybrid and native apps that practice host public key pinning. You need hybrid and native apps because they can usually obtain the host's public key. But the browsers don't expose the host public key to the webapp. So webapps have no way to perform pinning. You can't even get the public key from a WebSocket. > Encryption of email messages using a public > key is a different case. Session keys are required to debug TLS > applications. Email transport security is an absolute mess due to opportunistic encryption and smart hosts. About the best you can do is, encrypt and sign the message, and send it over an insecure channel. Jeff
