Skip to content
This repository has been archived by the owner on Nov 26, 2022. It is now read-only.

AUTH TLS negotiation fails when using a ServerSocket #10

Open
charonn0 opened this issue Sep 8, 2017 · 3 comments
Open

AUTH TLS negotiation fails when using a ServerSocket #10

charonn0 opened this issue Sep 8, 2017 · 3 comments

Comments

@charonn0
Copy link
Owner

charonn0 commented Sep 8, 2017

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
Copy link

@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
Copy link
Owner Author

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
Copy link

trippleflux commented Sep 17, 2017

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants