O servidor FTP não pode concluir o handshake SSL (VSFTPD)

Question

Estou tentando configurar um servidor FTP com criptografia, usando VSFTPD como o programa servidor, no Fedora 25. Apesar de aparentemente configurar tudo corretamente, eu nunca consigo conectar ao servidor de fora da minha LAN quando criptografar está ativado. No entanto, a conexão é possível se eu desabilitar a criptografia ou se eu conectar de dentro da minha LAN.

O problema que estou tendo é que o servidor VSFTPD não pode completar o handshake SSL depois de receber o comando AUTH de um cliente. Usando o Wireshark, posso ver que o servidor está tentando enviar o que parece ser a resposta do handshake várias vezes.

Se isso ajudar, aqui está o relatório do Wireshark de um cliente tentando se conectar ao servidor:

From    Info
------  ----
Client  64423 → 21 [ACK] Seq=1 Ack=1 Win=13952 Len=0 TSval=996262 TSecr=3062736173
Server  Response: 220 (vsFTPd 3.0.3)
Client  64423 → 21 [ACK] Seq=1 Ack=21 Win=13952 Len=0 TSval=996281 TSecr=3062736371
Client  Request: AUTH TLS
Server  21 → 64423 [ACK] Seq=21 Ack=11 Win=29056 Len=0 TSval=3062736436 TSecr=996282
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
Server  [TCP Retransmission] 21 → 64423 [PSH, ACK] Seq=21 Ack=11 Win=29056 Len=31 TSval=3062737214 TSecr=996282
Server  [TCP Retransmission] 21 → 64423 [PSH, ACK] Seq=21 Ack=11 Win=29056 Len=31 TSval=3062737214 TSecr=996282
Server  [TCP Retransmission] 21 → 64423 [PSH, ACK] Seq=21 Ack=11 Win=29056 Len=31 TSval=3062737214 TSecr=996282
...

Outras informações: Eu tenho o VSFTPD configurado para usar TLSv1 ou superior, para trabalhar no modo passivo & com FTPS explícito e com um certificado RSA auto-assinado. Eu não acho que haja um problema com o meu certificado, já que eu posso usar o mesmo certificado para hospedar um servidor https com httpd, que eu posso acessar de fora da minha LAN muito bem. Então, o problema deve estar relacionado ao VSFTPD de alguma forma.

Também defini meu roteador & firewall para encaminhar & aceite a porta 21 para conexões de porta de controle do ftp. Eu também configurei o VSFTPD para ter a porta 2048 como a única porta de dados PASV, mas por algum motivo eu não precisei encaminhar essa porta em meu roteador para permitir que conexões FTP não criptografadas funcionassem ... e além disso, a falha que estou tendo é acontecendo antes que a porta de dados seja envolvida, de qualquer forma.

Alguém tem alguma idéia de como corrigir isso? Há algo óbvio que estou perdendo aqui?

    

Answer 1

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

O que você vê não é o handshake TLS. O handshake TLS seria iniciado pelo cliente, o que não é o caso aqui. Em vez disso, o que você vê é uma retransmissão da última resposta do servidor, ou seja, 234 Proceed with negotiation.\r\n , que é exatamente 31 bytes.
Isso significa que o servidor não recebe nenhum ACK do cliente para essa resposta e, portanto, está retransmitindo-o, ou seja, o comportamento comum de conexões TCP na falta de ACK.

A questão é por que o servidor não está recebendo o ACK. Não está claro a partir de sua pergunta se a captura de pacotes foi feita no lado do cliente ou do servidor, mas suponho que isso foi feito no lado do servidor. Nesse caso, meu palpite é que existe algum firewall entre o cliente e o servidor que adultera a conexão:
Como o FTP é um protocolo com portas dinâmicas para transferência de dados e essas portas dinâmicas são trocadas dentro da conexão de controle, um firewall precisa ter acesso de texto claro à conexão de controle para descobrir quais portas dinâmicas são usadas e abrir essas portas. Se a conexão de controle for criptografada (AUTH TLS), isso não será mais possível, portanto, alguns firewalls tentam bloquear o uso de TLS de forma explícita ou inadvertida. E o que você vê pode ser o resultado disso.