0

We have a client and server that works via TLS 1.2 connection. Client connects to server, client checks server's certificate, connection established.

Question - can anyone who read all data packets (except client PC) do read/verification the certificate that server sends to client?

I.e. example:

  • we have 100 connections to different 100 servers
  • 5 servers out of 100 use the same certificate
  • we read all traffic (but can not change it)
  • can we distinguish these 5 servers among others ?
Victor Mezrin
  • 205
  • 3
  • 8

1 Answers1

2

can anyone who read all data packets (except client PC) do read/verification the certificate that server sends to client?

At least up to TLS 1.2 both server and the optional client certificate is transferred in clear text. The encryption starts in these TLS versions only in the last message of the TLS handshake (Finished). Transfer of the certificates is done before that and also the validation is done as part of the handshake. See also How can I extract the certificate from this pcap file?

With TLS 1.3 the situation is different though: encryption starts much earlier in the handshake and both server and optional client certificate are sent encrypted already. Thus it is not possible to get to the certificate just by passively sniffing/capturing the data.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • Wouldn't you be able to capture/extract the server certificate in TLS 1.3 anymore? – 匿名柴棍 Jan 17 '19 at 23:18
  • @匿名柴棍: in TLS 1.3 the certificate is transferred encrypted, i.e. it is not possible to extract it from the pcap anymore. I've updated this (2 year old) answer. – Steffen Ullrich Jan 18 '19 at 05:22
  • Thank you for the update. So you said it’s not possible for “passive” attack. Would it still possible for an “active” attack? Although I am not really knowledgeable enough to tell what would be an active attack look like :( – 匿名柴棍 Jan 18 '19 at 14:11
  • @匿名柴棍: an active MITM attack means that there is no longer an end-to-end-encrypted TLS connection between client and server but a client-to-attacker TLS connection and another attacker-to-server TLS connection. The latter has the original server certificate, the first has a attacker-generated certificate and will this usually cause the client to fail with an certificate validation error (unless he trusts the attacker's CA as in case of "legal" SSL interception done by firewalls or antivirus). Thus in this active MITM the attacker has access to the servers certificate, even with TLS 1.3. – Steffen Ullrich Jan 18 '19 at 14:41
  • Wow. Thank you so much for the explanation. Then if there is an active attacker in the middle, any version of TLS won’t work to protect my privacy, not just 1.3 rite? Cos even with 1.3, both ESNI and encrypted server cert will now known to the MitM. – 匿名柴棍 Jan 18 '19 at 16:53
  • @匿名柴棍: if there is an active man in the middle not only your privacy is at risk. The attacker can also sniff all the data and even modify the data. But like I said, browsers protect against man in the middle attacks since the attacker would need to fake the servers certificate but cannot do this (again, SSL interception like done by company firewalls or local antivirus is technically the same except that the browser trusts the man in the middle). – Steffen Ullrich Jan 18 '19 at 19:18