-1

From following link: Decrypting TLS with Netsh/WireShark

I found its pretty easy to segregate the keys file from tcp requests and later decrypt with WireShark.

Are there any reliable/bullet-proof methods that can prevent such decryption of TLS 1.3 on the client?

How those tcp packet traces segregate the keys from overall traffic?

Improve this question
2
  • 2
    You only have those keys because your machine has those keys. You are asking how to secure the network connection from the client that created the network connection. that doesn't make sense. And you misquote the blog you linked to. Nothing is "broken" in the blog... And nothing in the blog is suggesting MITM.
    – schroeder ♦
    Commented Jun 30 at 13:19
  • 2
    "... prevent such decryption of TLS 1.3 on the client?" - the client is the endpoint of the encrypted communication and as such must be able to decrypt the traffic. What you are asking instead is to prevent some other process on the client than the TLS using application to decrypt the traffic. If you want to prevent decryption from an attacker you need to prevent the client system from getting compromised. If you instead want to prevent decryption by the owner of the device - then you would take crucial control over the device away from the owner (which can no longer by called owner then)
    – Steffen Ullrich
    Commented Jun 30 at 13:34

1 Answer 1

Reset to default
2

Maybe this isn't clear from the video, but none of the techniques that have been shown have anything to do with an attack or malicious behavior. This is about a legitimate user configuring their TLS client to save the client key material to a file, so that network traces can later by decrypted. Note that the user has already seen the same network traffic as plaintext, so decrypting the traces doesn't expose any new sensitive information – it's just helpful for debugging and analysis.

Since there's no attack, there's also nothing to prevent. You might as well ask: How do we prevent a bank customer from using their card and PIN to withdraw money from their own account?

Of course there are all kinds of attacks against TLS, but the video has nothing to do with that.

The reason why it's so easy to decrypt the traffic in this case is because TLS clients are purposely designed to support the feature of saving key material to a file, and TLS itself is a standardized, well-known protocol. Neither of these facts should be in any way problematic.

Improve this answer
4
  • But incase if I connect to a public wifi, would they be able to sniff and save my keys [even if I don't use any VPNs or any sort of precautionary measures]. Though I didn't much deeply looking into it in a tech-sense until now..
    – Shyam R
    Commented Jun 30 at 18:44
  • 1
    @ShyamR: No, a public wi-fi cannot get your TLS keys from the network traffic. This is exactly the scenario which TLS is designed for: You want to securely communicate with a server over an insecure network. TLS 1.3 solves this problem with the Diffie-Hellman key agreement algorithm (which also has an elliptic-curve variant), or with a pre-shared key between client and server. In both cases, the network traffic never reveals the encryption keys.
    – Ja1024
    Commented Jun 30 at 19:05
  • @ShyamR To perform a man-in-the-middle attack against TLS, an attacker has to find and exploit a suitable vulnerability first. For example, they might try to compromise your device or use social engineering to make you ignore TLS warnings. Unless this succeeds, the TLS-encrypted traffic is safe.
    – Ja1024
    Commented Jun 30 at 19:08
  • Note that in the tutorial, the author doesn’t simply record and decrypt the network traffic. His first step is to set the SSLKEYLOGFILE environment variable on the client device, so that the browser saves the TLS key to that file. This of course requires access to the client device, either by being the legitimate user or by compromising the device.
    – Ja1024
    Commented Jun 30 at 19:32

Not the answer you're looking for? Browse other questions tagged .