Probleme FTP avec SSL

[Juuni]

Bonjour, voila j'ai un ptit problème avec mon serveur FTP. Je suis sous Filezilla Serveur, il est hébergé sur un pc de mon réseau local derrière ma freebox qui est configuré en routeur. Filezilla Serveur est configuré en mode passif et j'ai configuré une plage de port. J'ai redirigé sur ma freebox le port 21 ainsi que ma plage de ports vers mon pc hébergeant mon serveur.

Bon, en mode normal(sans cryptage des données) tout fonctionne très bien(connexion, transfert des données...) mais dès que j'active SSL/TLS sa merdouille. Pourtant la configuration me semble correct(en tout cas j'ai tester en local, la connexion SSL/TLS s'effectue bien et les données sont bien cryptées). Quand j'essaye de me connecter à mon serveur via Internet à l'aide de Filezilla Client je configure le mode FTPES-Chiffrement Explicite. La connexion s'effectue bien mais ca bloque lors du listage des données.

Statut :	Connexion sur 81.56.239.249:21...
Statut :	Connexion établie. Attente du message d'accueil...
Réponse :	220 Bienvenue sur le serveur de Màtt!!!
Commande :	AUTH TLS
Réponse :	234 Using authentication type TLS
Statut :	Initialisation TLS...
Commande :	USER matt
Statut :	Vérification du certificat...
Statut :	Connexion TLS/SSL établie.
Réponse :	331 Password required for matt
Commande :	PASS ********
Réponse :	230 Logged on
Commande :	PBSZ 0
Réponse :	200 PBSZ=0
Commande :	PROT P
Réponse :	200 Protection level set to P
Statut :	Connecté
Statut :	Récupération du contenu du répertoire...
Commande :	PWD
Réponse :	257 "/" is current directory.
Commande :	TYPE I
Réponse :	200 Type set to I
Commande :	PORT 172,16,1,69,8,144
Réponse :	200 Port command successful
Commande :	LIST
Réponse :	150 Opening data channel for directory list.
Réponse :	425 Can't open data connection.

Seconde chose que je trouve très bizarre c'est que lorsque je test mon serveur FTP à l'aide du site http://www.g6ftpserver.com/en/ftptest la connexion et le listage des données s'effectues correctement :??:

* About to connect() to 81.56.239.249 port 21
* Trying 81.56.239.249... connected
* Connected to 81.56.239.249 (81.56.239.249) port 21
< 220 Bienvenue sur le serveur de MÃ tt!!!

> AUTH SSL
< 234 Using authentication type SSL
* successfully set certificate verify locations:
* CAfile: d:\www-bin\curl\curl-ca-bundle.crt
CApath: none
* SSLv3, TLS handshake, Client hello (1):
SSLv3, TLS handshake, Server hello (2):
SSLv3, TLS handshake, CERT (11):
SSLv3, TLS handshake, Server finished (14):
SSLv3, TLS handshake, Client key exchange (16):
SSLv3, TLS change cipher, Client hello (1):
SSLv3, TLS handshake, Finished (20):
SSLv3, TLS change cipher, Client hello (1):
SSLv3, TLS handshake, Finished (20):
SSL connection using AES256-SHA
* Server certificate:
* subject: /CN=81.56.239.249/C=33/ST=centre/L=tours/O=plc/OU=bts/emailAddress=matt@free.fr
* start date: 2007-11-01 23:48:40 GMT
* expire date: 2008-10-31 23:48:40 GMT
* common name: 81.56.239.249 (matched)
* issuer: /CN=81.56.239.249/C=33/ST=centre/L=tours/O=plc/OU=bts/emailAddress=matt@free.fr
* SSL certificate verify result: error number 1 (18), continuing anyway.

> USER matt
< 331 Password required for matt

> PASS *****
< 230 Logged on

> PBSZ 0
< 200 PBSZ=0

> PROT P
< 200 Protection level set to P

> PWD
< 257 "/" is current directory.
* Entry path is '/'

> CLNT Testing from http://www.g6ftpserver.com/ftptest from IP 85.68.211.190
< 200 Don't care

> FEAT
< 211-Features:
< MDTM
< REST STREAM
< SIZE
< MLST type*;size*;modify*;
< MLSD
< AUTH SSL
< AUTH TLS
< UTF8
< CLNT
< MFMT
< 211 End

> PASV
* Connect data stream passively
< 227 Entering Passive Mode (81,56,239,249,195,81)
* Trying 81.56.239.249... connected
* Connecting to 81.56.239.249 (81.56.239.249) port 50001

> TYPE A
< 200 Type set to A

> LIST
< 150 Connection accepted
* Doing the SSL/TLS handshake on the data stream
* successfully set certificate verify locations:
* CAfile: d:\www-bin\curl\curl-ca-bundle.crt
CApath: none
* SSL re-using session ID
* SSLv3, TLS handshake, Client hello (1):
SSLv3, TLS handshake, Server hello (2):
SSLv3, TLS change cipher, Client hello (1):
SSLv3, TLS handshake, Finished (20):
SSLv3, TLS change cipher, Client hello (1):
SSLv3, TLS handshake, Finished (20):
SSL connection using AES256-SHA
* Server certificate:
* subject: /CN=81.56.239.249/C=33/ST=centre/L=tours/O=plc/OU=bts/emailAddress=matt@free.fr
* start date: 2007-11-01 23:48:40 GMT
* expire date: 2008-10-31 23:48:40 GMT
* common name: 81.56.239.249 (matched)
* issuer: /CN=81.56.239.239/C=33/ST=centre/L=tours/O=plc/OU=bts/emailAddress=matt@free.fr
* SSL certificate verify result: error number 1 (18), continuing anyway.
######################################################################## 100,0%* SSLv3, TLS alert, Client hello (1):
226 Transfer OK
######################################################################## 100,0%-rw-r--r-- 1 ftp ftp 22528 Oct 31 13:06 CV Matt.doc
-rw-r--r-- 1 ftp ftp 42987 Nov 22 14:53 fun001.jpg
-rw-r--r-- 1 ftp ftp 738280070 Oct 30 10:25 This.is.england.2007.DVDRip.VOST.Fr.xvid-JzX-UnitY.avi
-rw-r--r-- 1 ftp ftp 3584 Oct 27 2006 Thumbs.db
* Connection #0 to host 81.56.239.249 left intact


> QUIT
< 221 Goodbye
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):

Bon après pas mal de recherches, d'après ce que j'ai compris le problème est au niveau NAT, le routeur ne peut pas changer l'adresse ip privé en adresse publique (la sienne). Donc si je comprends bien c'est que les paquets arrivent crypter en totalités au routeur(et non uniquement les données comme je le pensais) et donc les paquets sont perdus. Comment le site arrive t-il alors à accèder a mes données? Pourquoi moi je n'y arrive pas?

Merci d'avance pour votre aide car j'avou qu'après moulte recherches je suis dans le brouillard le plus total

[_Glx_]

Tu essayes de te connecter à ton serveur depuis un poste derrière la même box en utilisant l'adresse publique ?

Si c'est le cas c'est normal, et ca explique pourquoi le serveur web arrive à s'y connecter sans soucis. Enfin si tu y arrives sans SSL c'est sûrement pas le cas

Sinon il me semble que Filezilla server ne passe pas en PASV dans les logs.

En utilisant une connexion chiffrée dans le même sous réseau IP ca marche ?

Essaye sinon de passer en SFTP, et non en FTPS (l'inverse?). Dans ce cas au lieu de chiffrer tous les paquets TCP de la session FTP avec SSL, tu fais passer ta connexion FTP dans un tunnel SSL. ca permet de ne "NATer" qu'un seul port sur ta box et de résoudre le problème je pense.

EDIT: vérifie avec une capture de paquets si il y a un échange de paquets au moins pour l'ouverture de la connexion DATA...c'est souvent la que ca bloque, l'ouverture de session chiffrée sur le canal de controle masque à ta box le port choisi pour le canal DATA.

Re-EDIT: Un serveur NATé en mode passif est impossible à mettre en place à moins que le serveur FTP ne modifie l'adresse IP envoyée dans le paquet envoyé en réponse au mode PASV. Il doit y mettre l'adresse IP publique sur laquelle il est joignagle.

Vérifie donc la configuration du mode passif dans Filezilla Server.

[Einstein-Rosen-Podolsky]

pour info le port 21 est pour effectuer la connexion! et le port 20 pour le transfert des données !

[_Glx_]

pour info le port 21 est pour effectuer la connexion! et le port 20 pour le transfert des données !

Dans un fonctionnement en FTP actif oui, le client envoie une requête de connexion au serveur sur le port TCP 21, qui initie une connexion au "client" sur le port TCP 21.

Ceci à pour but d'utiliser 2 ports prédéfinis par la RFC mais l'une des deux connexions se fait en direction du "client". Et accessoirement gérer chaque connexion à un client avec un processus fils et un socket différent du processus père.

En FTP passif, toutes les connexions sont initiées par le client pour résoudre le problème des routeurs/box qui rejètent toute connexion non autorisée dans les règles de NAT. Le routeur frontal du réseau privé ou se situe le serveur FTP, si celui-ci n'est pas sur Internet doit donc inspecter les paquets envoyés par le serveur afin de gérer dynamiquement les règles de NAT et rediriger les futures connexions acceptées par le serveur FTP qui seront initiées par les clients vers le serveur FTP.

Dans le cas d'un chiffrement des paquets avec SSL, le problème c'est que le routeur ne peut plus "lire" les paquets car il n'a pas la clé de déchiffrement. Il fait donc son boulot et bloque les connexions initiées sur les ports fermés.

C'est pour cela qu'on configure des plages de ports TCP > 1024 afin de rediriger quand même tous ces paquets chiffrés que le routeur rejèterait en temps normal.

Le problème c'est qu'une fois le chiffrement en place, le serveur FTP envoie les paquets donnant aux clients le port choisi pour le canal de données avec son adresse IP source, qui est privée (genre 192.168.x.x). Le routeur qui doit remplacer cette adresse IP source par celle de son interface externe/publique ne le fait plus car le paquet est chiffré (je parle ici du contenu du protocole FTP, pas des entêtes des paquets IP).

Au final le logiciel FTP du client initie une connexion sur une adresse IP privée, ce qui conduit à l'échec de la connexion pour le canal de données...

C'est un peu compliqué même moi qui ais déjà fait face à ce problème je suis un peu perdu :) J'espère ne pas avoir dit de bêtise.