AUTH TLS: problem with PROT P when not supported by server
Hi.
I just want to mention that I've noticed a problem with the way flashfxp implements the PROT command, as part of the AUTH TLS mechanism.
If you specify you want secure file listing and/or secure file transfers (upload/download), flashfxp sends the 'PROT P' command. However, if the server refuses to negotiate tls on the ftp-data channel, giving any of the following replies, flashfxp doesn't seem to honor/accept this reply.
500 Syntax error, command unrecognized.
504 Command not implemented for that parameter.
534 Request denied for policy reasons.
536 Requested PROT level not supported by mechanism.
537 Command protection level not supported by security mechanism.
What would be expected after such a reply is that the client backs off and reports this to the user, perhaps disconnecting the ftp session too. Or, as a failover, it could revert to 'PROT C'. Even if this would probably break compliance to the standards and even pose security problems, it could be more convenient for the end user.
However, what flashfxp actually seems to do is that it rather ignores the server's reply, and it proceeds to try to negotiate TLS over the ftp-data session.
From my short testing on this with directory lists, I just noticed that some times flashfxp will manage to produce a valid dir list, some times it won't. It seems to do better on smaller ones, but I'm not sure I can be any more specific than that.
|
Linear Mode
