Il server FTP non può completare l'handshake SSL (VSFTPD)


1

Sto cercando di configurare un server FTP accessibile da Internet con la crittografia, usando VSFTPD come programma server, su Fedora 25. Nonostante apparentemente abbia impostato tutto correttamente, non posso mai collegarmi al server dall'esterno della mia LAN quando la crittografia è abilitata. Tuttavia, la connessione è possibile se disabilito la crittografia o se mi connetto dalla mia LAN.

Il problema che sto riscontrando è che il server VSFTPD non può completare l'handshake SSL dopo aver ricevuto il comando AUTH da un client. Utilizzando Wireshark, posso vedere che il server sta tentando di inviare più volte quella che sembra la risposta della stretta di mano.

Se aiuta, ecco il rapporto di Wireshark su un client che tenta di connettersi al server:

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
...

Altre informazioni: ho VSFTPD configurato per utilizzare TLSv1 o versioni successive, per lavorare in modalità passiva e con FTPS esplicito e con un certificato RSA autofirmato. Non credo che ci sia un problema con il mio certificato, dato che sono in grado di utilizzare lo stesso certificato per ospitare un server https con httpd, a cui posso accedere dall'esterno della mia LAN. Quindi il problema deve essere in qualche modo correlato a VSFTPD.

Ho anche impostato il mio router e firewall per inoltrare e accettare la porta 21 per le connessioni della porta di controllo ftp. Ho anche impostato VSFTPD per avere la porta 2048 come unica porta dati PASV, ma per qualche ragione non ho avuto bisogno di inoltrare quella porta sul mio router per far funzionare le connessioni FTP non crittografate ... e inoltre, l'errore che sto riscontrando è comunque, prima che la porta dati venga coinvolta.

Qualcuno ha idea di come risolvere questo problema? C'è qualcosa di ovvio che mi manca qui?


1
Suggerisci di attivare il log di debug su VSFTPD e cerca il motivo lì. Per riferimento: access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/…
Oleg

Grazie. Quando accendo la registrazione e il debug SSL, il mio file vsftpd.log aggiunge queste righe ogni volta che viene tentata una connessione e fallisce: CONNECT: Client "::ffff:<client-ip>" DEBUG: Client "::ffff:<client-ip>", "SSL_accept failed: error:00000000:lib(0):func(0):reason(0)"
mr_johnson22

Risposte:


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

Quello che vedi non è l'handshake TLS. L'handshake TLS verrebbe avviato dal client, il che non è il caso qui. Quello che invece vedi è una ritrasmissione dell'ultima risposta del server, ovvero 234 Proceed with negotiation.\r\nesattamente 31 byte.
Ciò significa che il server non riceve alcun ACK dal client a questa risposta e quindi lo sta ritrasmettendo, ovvero il comportamento comune delle connessioni TCP su ACK mancante.

La domanda è perché il server non sta ricevendo l'ACK. Non è chiaro dalla tua domanda se l'acquisizione dei pacchetti è stata eseguita sul lato client o server, ma suppongo che sia stata eseguita sul lato server. In questo caso, suppongo che ci sia un firewall tra client e server che compromette la connessione:
poiché FTP è un protocollo con porte dinamiche per il trasferimento di dati e queste porte dinamiche vengono scambiate all'interno della connessione di controllo, un firewall deve avere un testo chiaro accedere alla connessione di controllo per scoprire quali porte dinamiche vengono utilizzate e aprire queste porte. Se la connessione di controllo è crittografata (AUTH TLS) ciò non è più possibile, quindi alcuni firewall tentano di bloccare esplicitamente o inavvertitamente l'uso di TLS. E quello che vedi potrebbe essere il risultato di questo.


Sì, il registro di Wireshark è stato eseguito sul lato server. Inoltre, ho appena provato a stabilire una connessione FTP dopo aver disattivato brevemente i miei firewall e lo stesso errore si è verificato, quindi questo probabilmente non è un problema di firewall dopo tutto ... ma forse c'è un firewall su Internet LTE del mio telefono, che ho sto usando come mio client FTP.
mr_johnson22,

@ mr_johnson22: ... Internet LTE del mio telefono ... - non è improbabile. Le connessioni mobili utilizzano spesso IPv4 privato combinato con NAT, nel qual caso deve essere eseguita anche la gestione speciale di FTP. Basta confrontare l'IP client che vedi sul server con l'indirizzo IP che il tuo telefono ha avuto per vedere se è così. Vedi anche en.wikipedia.org/wiki/Carrier-grade_NAT
Steffen Ullrich

Questo spiega le cose. (Il mio server FTP vede lo stesso IP che ha il mio telefono, ma potrei mancare qualcosa.) Ho anche fatto qualche ricerca e sembra che alcuni client / firewall blocchino FTPS con certificati autofirmati. Userò invece SFTP.
mr_johnson22
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.