0

Recently, we have found that our web page occassinally could not be opened. Then we have captured the data packets on both client side and server side and found a very strange phenomenon.

In a TLS communication process, client side sent "client hello" to server, then server replied with "server hello and certificate" and the client side acknowledged. But then the data packets captured on server side shows that the server side had sent "server key exchange and sever hello done" message which did not appear in data packets captured on client side. That could explain why our web page could not be opened as client side was waiting for "server hello done" message. However, in the data packets captured on server side, the "server key exchange" data packet was acknowledged by client side. I am very confused by this issue. Who did acknowledge the "server key exchange" packet? Is it something like a middle man attack?

yifan
  • 163
  • 1
  • 1
  • 11
  • you said that in packet capture you clearly see that the packet is sent by the server to the client IP and port and this packet is not seen in client's packet capture? is it just a regular TCP? – Oleg Feb 11 '19 at 11:48
  • @Oleg, yes, but the server got the corresponding ACK packet. I don't know what happened, is it possible that it was caused by middle man? – yifan Feb 20 '19 at 02:13
  • it could be a proxy in the way or something like this (load balancer etc) – Oleg Feb 20 '19 at 07:48

1 Answers1

0

If the server sends a "ServerHelloDone" message without performing a server key exchange, it suggests that the server is using a cipher suite that doesn't require explicit server key exchange. This is possible in certain scenarios, such as:

RSA Key Exchange: In some cases, the server's public key is already embedded in its certificate, and no additional server key exchange message is necessary. The client can extract the server's public key from the certificate and use it for key exchange and encryption.