Server Response: 234 Proceed with negotiation. Server [TCP Retransmission] 21 → 64423 [PSH, ACK] Seq=21 Ack=11 Win=29056 Len=31 TSval=3062736822 TSecr=996282
То, что вы видите, не является рукопожатием TLS. Рукопожатие TLS будет запущено клиентом, что здесь не так. Вместо этого вы видите повторную передачу последнего ответа сервера, то 234 Proceed with negotiation.\r\nесть ровно 31 байт.
Это означает, что сервер не получает ACK от клиента на этот ответ и, следовательно, он ретранслирует его, то есть обычное поведение соединений TCP при пропущенном ACK.
Вопрос в том, почему сервер не получает ACK. Из вашего вопроса не ясно, был ли захват пакета выполнен на стороне клиента или сервера, но я предполагаю, что это было сделано на стороне сервера. В этом случае я полагаю, что между клиентом и сервером существует некий брандмауэр, который вмешивается в соединение:
поскольку FTP - это протокол с динамическими портами для передачи данных, и эти динамические порты обмениваются внутри управляющего соединения, брандмауэр должен иметь чистый текст доступ к управляющему соединению, чтобы узнать, какие динамические порты используются, и открыть эти порты. Если управляющее соединение зашифровано (AUTH TLS), это больше невозможно, поэтому некоторые брандмауэры пытаются явно или непреднамеренно заблокировать использование TLS. И то, что вы видите, может быть результатом этого.