You
?found out that the problem is with the server
Interesting. How did you do that?
Did you opened a case with Microsoft support or did you guess what the
root cause of the problem is?
Joerg
Moderator: Project members
?found out that the problem is with the server
Oh really? I don't believe you have looked at this issue in depth at all. I think you have just decided on the (its broken) excuse, because it conveniently fits in with your anti-MS stance.botg wrote:I have listened to all your concerns and found out that the problem is with the server. I gave you the correct solution, which is to fix the server. What else can I do?
Your analysis coupled with careful study of the TLS specifications is what I base my results on.I have the answer, because I HAVE gone to the trouble of identifying exactly what makes it all fall apart.
So you have never taken anyone up on the offer to test against a real server, or to run different configs to work out which part on the GNUTLS is failing, or to watch the traffic at the packet level and sort out which part of the protocol causes the problems, etc. etc. Basically you have no interest at all in making this work properly?botg wrote:Your analysis coupled with careful study of the TLS specifications is what I base my results on.I have the answer, because I HAVE gone to the trouble of identifying exactly what makes it all fall apart.
Taken many offers but never got any credentials.rossh wrote:So you have never taken anyone up on the offer to test against a real server
Plenty interest, but no access to an affected server.or to run different configs to work out which part on the GNUTLS is failing, or to watch the traffic at the packet level and sort out which part of the protocol causes the problems, etc. etc. Basically you have no interest at all in making this work properly?
You presented the ClientHello record layer version number issue as fact, why should I doubt that?Therefore you have no factual test basis to make your claim of a server defect. How interesting.
Please rephrase that. Anti-broken-server campaign it is. If it were FileZilla Server that were not following specs, I would be just as zealous (and of course I would fix the server).And how perfect for your little anti-MS campaign hey?
OP here. No need for a flame war guys. Has Microsoft been notified of this?botg wrote:Taken many offers but never got any credentials.rossh wrote:So you have never taken anyone up on the offer to test against a real server
Thank you, I now know why this is happening. It actually has nothing to do with the ClientHello and the used record layer version number.gbaotic wrote:Anyway, I have just sent botg credentials for my IIS 8 FTP server, and I sincerely hope it gets fixed one way or another.
The server certainly did not agree to the extension requesting strong signing algorithms.- Some cases where a server does not agree to an extension are error
conditions, and some are simply refusals to support particular
features. In general, error alerts should be used for the former,
and a field in the server extension response for the latter.
Thanks for the update. However, that does not explain why FileZilla connects just fine to IIS 7.5 (and lower) FTP service (Explicit FTP over TLS) using certificates with the identical RSA-SHA1 signature algorithm. I'm not that well into crypto, but all the certificates I could find around me, including the self-signed one on my FTP server, have the "sha1RSA" signature algorithm.botg wrote:I wonder what the security implications of allowing RSA-SHA1 are. At least better alternatives are available in as specified in rfc4055. I suppose I can allow the RSA-SHA1 signature algorithm again, but from a security standpoint it leaves no good feeling, SHA1 collisions will probably make the news in just a few years.
Okay. So what's the plan in making this work?botg wrote:Only TLS 1.2 supports specifying which signature algorithm to use.
botg wrote:I'm thinking of enabling it in the next version. Probably be out this month still.
Agreed. IIRC, with 3.5.3 I could establish FTPES connection normally, but file transfers did not work properly.rossh wrote:botg wrote:I'm thinking of enabling it in the next version. Probably be out this month still.
Its nice to see you looking into this...
But I think your only half way there. Did you try a file send and receive? I think you will find the old problem of 3.5.3 where the server closes the socket abruptly, because the client did not give a required / expected response at the end of the transfer. The client then deems this as a failure and deletes the file.
FileZilla never deletes partial transfers.rossh wrote:The client then deems this as a failure and deletes the file.