search

charonn0 / RB-FTP

FTP client and server implementations in realbasic
MIT License
10 stars 4 forks source link

AUTH TLS negotiation fails when using a ServerSocket #10

Open charonn0 opened 7 years ago

charonn0 commented 7 years ago

The AUTH verb allows the client to initiate SSL/TLS negotiation on an existing clear-text socket.

However, when the FTP.Server class is used with a ServerSocket, the negotiation fails and clients report unexpected/illegal negotiation packets.

FileZilla:

Error: GnuTLS error -19: An unexpected TLS handshake packet was received.

FTPRush:

error:14092072:SSL routines:ssl3_get_server_hello:bad message type

FlashFXP:

SSL error:141A10F4:SSL routines:ossl_statem_client_read_transition:unexpected message

trippleflux commented 7 years ago

@charonn0 So how we proceed with these?, like on forum, there is seems to be an issue with SSLSocket on serversocket, and xojo looks like not interested in this issue.

charonn0 commented 7 years ago

We'll probably have to wait for Xojo to either fix the ServerSocket/SSLSocket (or explain what we're doing wrong). In the meantime we can still work on getting AUTH TLS working in FTP.Server.

Right now the stumbling block is the PROT P command, which switches the data connection into private mode (TLS). I don't yet understand why it isn't working, but I suspect I'm switching into TLS mode either too early or too late.

trippleflux commented 7 years ago

@charonn0

Like what i was posted on the xojo forum, looks like this log below is self explanatory : 

CONNECT [     0] - Incoming connection request
CONNECT [     0] - FTP Connection request accepted
COMMAND [     0] - AUTH TLS
  REPLY [     0] - 234 Authentication method accepted

CONNECT [     0] - SSL connection using TLSv1/SSLv3 (RC4-MD5)
CONNECT [     0] - SSL connection established
COMMAND [     0] - USER test
  REPLY [     0] - 331 User test, password please

COMMAND [     0] - PASS ***********
CONNECT [     0] - Native user 'test' authenticated
  REPLY [     0] - 230 Password Ok, User logged in

COMMAND [     0] - PBSZ 0
  REPLY [     0] - 200 PBSZ=0

COMMAND [     0] - PROT P
  REPLY [     0] - 200 PROT P OK, data channel will be secured

COMMAND [     0] - PASV
  REPLY [     0] - 227 Entering Passive Mode (127,0,0,1,43,41)

COMMAND [     0] - STOR test.txt
  REPLY [     0] - 150 Opening data connection

CONNECT [     0] - SSL connection using TLSv1/SSLv3 (RC4-MD5)
CONNECT [     0] - SSL data connection established
 SYSTEM [     0] - Successfully stored file at 'c:\ftp\test.txt'
  REPLY [     0] - 226 Transfer complete

COMMAND [     0] - QUIT
CONNECT [     0] - Connection terminated

CONNECT is from FTP Client request while SYSTEM or REPLY is from the FTP Server, as you can see after "PROT P" , FTP Client then requesting PASV (Encrypted on port 21) and then connection changed to PASV as requested by the Client and then Client renegotiating into configured PASV Port after the STOR (send from the client to server in plaintext?) .

Looks like we only need port 21 TLS negotiation in between AUTH TLS command and PASV command, after that we can set back ServerSocket.Secure into False on port 21?. It seems most of the works being done on PASV a.k.a Passive ports.

Looks like if i am using ftprush with only LIST -a command (not MLSD) it works fine?, managed to List all of the folders and files but with MLSD on FlashFXP always failed because of something wrong with PASV implementation and MLSD after PASV and AUTH TLS.