veeso / suppaftp

a super FTP/FTPS client library for Rust with support for both passive and active mode
Apache License 2.0
121 stars 31 forks source link

Problem setting up TLS -> bad server or bad client? #43

Closed svet-b closed 1 year ago

svet-b commented 1 year ago

I'm connecting to an FTP server on an industrial device. In the course of setting up TLS, the following exchange takes place:

[DEBUG suppaftp::sync_ftp] Connecting to server
[DEBUG suppaftp::sync_ftp] Established connection with server
[DEBUG suppaftp::sync_ftp] Reading server response...
[TRACE suppaftp::sync_ftp] CC IN: [50, 50, 48, 32, 86, 120, 87, 111, 114, 107, 115, 32, 70, 84, 80, 32, 115, 101, 114, 118, 101, 114, 32, 40, 86, 120, 87, 111, 114, 107, 115, 32, 86, 120, 87, 111, 114, 107, 115, 53, 46, 53, 46, 49, 41, 32, 114, 101, 97, 100, 121, 46, 13, 10]
[TRACE suppaftp::sync_ftp] Code parsed from response: service ready for new user (220)
[DEBUG suppaftp::sync_ftp] Server READY; response: Some("220 VxWorks FTP server (VxWorks VxWorks5.5.1) ready.")
[DEBUG suppaftp::sync_ftp] Initializing TLS auth
[TRACE suppaftp::sync_ftp] CC OUT: AUTH TLS
[TRACE suppaftp::sync_ftp] CC IN: [50, 48, 48, 32, 65, 85, 84, 72, 32, 99, 111, 109, 109, 97, 110, 100, 32, 111, 107, 59, 32, 115, 116, 97, 114, 116, 105, 110, 103, 32, 83, 83, 76, 32, 99, 111, 110, 110, 101, 99, 116, 105, 111, 110, 46, 46, 46, 13, 10]
[TRACE suppaftp::sync_ftp] Code parsed from response: command okay (200)

Unfortunately at that point the suppaftp client raises UnexpectedResponse, since it expects Status::AuthOk (234) rather than Status::CommandOk (200) - based on https://github.com/veeso/suppaftp/blob/main/suppaftp/src/sync_ftp/mod.rs#L141.

Not quite sure what to make of that. It's entirely possible that the server is just not spec-compliant. But it would be good to find a way to establish the connection nonetheless. FWIW, wget connects fine and doesn’t seem to complain. Any thoughts? Maybe I’m just connecting improperly in some way?

veeso commented 1 year ago

The server must respond 234 to AUTH command as stated in the RFC https://www.rfc-editor.org/rfc/rfc4217. In particular, this section https://www.rfc-editor.org/rfc/rfc4217#section-12.1 explains the flow and the 234 response makes the client start the TLS negotiation.

Could it be the server actually doesn't support TLS?

svet-b commented 1 year ago

Yeah I suspected the server's behavior is not standards-compliant. And am not surprised, given the nature of the device.

The server does support FTPS - in fact it requires a secure connection - and as I mentioned, I'm able to access data using wget (with an ftps://... URL), and it doesn't seem to complain. But I guess the wget is more lenient towards behavior like this.

Anyway, I was able to work around this using an implicit FTPS connection on another port, which seemed to work without issue (thanks also for the help there!). So on balance, I wouldn't steer you towards accommodating for pathological behavior like this :). Will go ahead and close this.