1

As I understand the original master key, which is used to encrypt the application data is never transmitted over the wire and it is calculated on both client and server individually using a hashing-alike function which takes the following as input:

  1. Client Random
  2. Server Random
  3. Pre-master key encrypted with Server's public key.

If a man-in-the-middle captures the TLS handshake packets and if he somehow has the server's private key, then will he be able to generate the master key? So, is the server's private key the only protection against the man-in-the-middle attack?

What happens in mTLS, where client also shares its certificate(public key)? Will it change the way the master key is generated?

Sir Muffington
  • 1,536
  • 2
  • 11
  • 23
Hemanth
  • 111
  • 4
  • That plain-RSA keyexchange was common in the nineties and noughties, but is now **mostly obsolete**. It was largely replaced by ephemeral Diffie-Hellman (either original/modp or elliptic-curve) post-Snowden (2013) and totally so in TLS1.3 (2018). Also 1.3 (always) adds entire transcript (not just randoms) in the derivation; 1.2 and below now have an option to do so (Extended Master Secret) which is fairly common though not universal among systems not yet doing 1.3. But MitM is active and doesn't try to pass-through keyexchange, so this doesn't matter. – dave_thompson_085 Apr 16 '22 at 00:03

2 Answers2

4

If the attacker has the private key matching the servers certificate and if the attacker can mount an active man in the middle attack, then it can force the client to connect to the MITM attacker and accept the original servers certificate from it. There will be separate key exchanges and thus the encryption keys between client and MITM and between MITM and server will be different, but none of these will know that they connected to the wrong party. The MITM will have access to the plain traffic and can sniff and modify it at will.

If a client certificate is required then the MITM needs also access to the client certificates private key to mount a transparent attack. Without this the TLS handshake between client and MITM will succeed but the handshake between MITM and server hopefully fail since the MITM can only present a certificate not trusted by the server.

Steffen Ullrich
  • 190,458
  • 29
  • 381
  • 434
  • Just summarising to check if my understanding is correct:- 1. In TLS, if server's pkey is compromised, the sniffing of both uplink and downlink traffic is possible. Also, the original data can be modified and both sides will never know that data has been modified. 2. In mTLS, if server's pkey alone is compromised, then sniffing of uplink traffic(from client'e perspective) is possible, whereas sniffing of downlink is not possible. Also, modification of data is not possible because, the uplink traffic never reaches the server and the downlink traffic never reaches the client or MITM attacker. – Hemanth Apr 15 '22 at 19:13
  • plz let me know if my understanding described in the above comment is correct ? – Hemanth Apr 15 '22 at 19:14
  • 1
    @Hemanth: " In TLS, if server's pkey is compromised, the sniffing of both uplink and downlink traffic is possible."* - With the common DH key exchange passive sniffing is not possible. One need to be an active MITM instead, i.e. inferring with the traffic not just sniffing it. With the obsolete RSA key exchange passive sniffing would be possible. – Steffen Ullrich Apr 15 '22 at 19:22
  • @Hemanth: *"In mTLS, if server's pkey alone is compromised, then sniffing of uplink traffic(from client'e perspective) is possible, whereas sniffing of downlink is not possible."* - TLS handshake on uplink will succeed but on downlink will fail. Since application data get only exchanged after TLS handshake this basically makes sniffing of client-server application data impossible. – Steffen Ullrich Apr 15 '22 at 19:24
  • What I meant by "sniffing uplink application data is possible is :- Client --- MITM Attacker ( TLS HS successful). Then client will start sending its uplink traffic thinking that the server is authentic and thus the MITM attacker can sniff (active sniff) the uplink traffic. I hope this understanding of mine is correct. – Hemanth Apr 15 '22 at 19:45
  • @Hemanth Regardless of which kind of encryption is used, an attacker who has the server's private key **can simply pretend to be the server** – user253751 Apr 20 '22 at 10:56
0

If the attacker can only capture packets, it's not a MitM attack but simply eavesdropping. And in this case, in modern TLS with ephemeral keys (DHE, Ephemeral Diffie-Hellman, or ECDHE suites) the communication is safe even if the server private key is subsequently compromised. That's one of the major motivation to only use suites with ephemeral keys, so the compromission of a server down the line doesn't compromise past communications.

Bruno Rohée
  • 5,351
  • 28
  • 39