Can't connect to Windows Server 2012 (IIS 8) FTP when using

[botg]

Also, see appendix D.4: Implementation Pitfalls:

- Do you ignore the TLS record layer version number in all TLS
records before ServerHello (see Appendix E.1)?

Compliant implementations should answer every question in appendix D.4 with yes.

[rossh]

Also, see appendix D.4: Implementation Pitfalls:

- Do you ignore the TLS record layer version number in all TLS
records before ServerHello (see Appendix E.1)?

Compliant implementations should answer every question in appendix D.4 with yes.

Your grasping at straws pal. You know its a big red error to expect your current code method to work here. And it appears you have no code in there to handle any of the further difficulties described in Appendix E.

You need to do a revision, and tidy up this mess.

[botg]

All fine and compliant on my end, I don't need to do anything.

[rossh]

All fine and compliant on my end, I don't need to do anything.

Wrong again. You do NOT comply fully to RFC 5246. If you did, (like in 3.63) then filezilla would be able to talk to all servers in TLS v1.2. If you coded it fully compliant to RFC 5246, it would work properly.

But instead your using weak excuses, poor interpretations, and ignorance, to deliberately make bad and sloppy code, all done as a front to push your platform specific political desires.

As a project admin, you should be above all this crap. Maybe its time for a grown up to take over?

[rossh]

Its interesting to see the version changes difficulties that FilleZilla has had in this TLS 1.2 area.

In 3.6.0.2 it announces itself as TLS 1.0 outer wrapper and 1.2 inner wrapper but Fails the command connection, due to the version conflict.

In 3.53 Its announces itself as TLS 1.2 in both outer and inner wrappers. The command connection completes in TLS 1.2 mode and works well. But the subsequent file upload transfer fails, because of server response error "550 The supplied message is incomplete. The signature was not verified." Seems that Filezilla was missing something at the end of the transfer. The downloads worked.

In 3.52 its announces TLS 1.2 in both the inner and outer wrappers. But dies straight away error -9 (unexpected packet). In fact the sever has sent a FIN on the socket for unknown reason.

*****

So it seems you guys had it close in 3.53. Now in 3.6.x, your going backwards and worse.

[botg]

In 3.6.0.2 it announces itself as TLS 1.0 outer wrapper and 1.2 inner wrapper but Fails the command connection, due to the version conflict.

That's desired. It is permitted by the standard, TLS 1.2 compliant servers MUST handle this. Your server doesn't and thus isn't compliant.

[rossh]

In 3.6.0.2 it announces itself as TLS 1.0 outer wrapper and 1.2 inner wrapper but Fails the command connection, due to the version conflict.

That's desired. It is permitted by the standard, TLS 1.2 compliant servers MUST handle this. Your server doesn't and thus isn't compliant.

No it is NOT. The rules are specific: in attempting a v1.2 connection, you specify 1.2. And it does not make any logical sense to try to avoid this. You cannot get away with wrapping new protocol in an old protocol wrapper - that's just plain dumb.

Your failed attempts to use backward rules in new 1.2 are an invalid approach.

No matter how many times you try to ignore the facts - your Filezilla will not work like this. It never will. But you seem happy with this state of affairs. Sad really. You hold the client software to ransom, just to satisfy your anti-MS rage.

We need a better project admin: someone who actually values working software more than personal agenda's.

[botg]

The facts are in appendix E, it clearly says that using a record layer version of 3,XX is allowed and that TLS 1.2 compliant servers MUST be prepared to handle this.

[rossh]

The facts are in appendix E, it clearly says that using a record layer version of 3,XX is allowed and that TLS 1.2 compliant servers MUST be prepared to handle this.

Except the fault lies in the Client. The client is sending defective and invalid connection requests.

Worse thing is, you know the client doesn't work everywhere because of this. And you don't seem to care.

Resign - your not worthy of the position of project admin.

[botg]

The client is sending a compliant ClientHello. The non-compliant server is discarding a compliant ClientHello. Why should I change the compliant client when it is the non-compliant server that fails to adhere to the standard?

[rossh]

You keep telling your self those lies... Your wishful thinking is not going to save you.
Filezilla does NOT send a compliant message. Filezilla breaks the rules. Garbage out - garbage in. Your filezilla gets rejected because it sends a garbled message.

Your the one with the broken software - your filezilla does not work. You put politics ahead of proper coding, only because it suits your anti-MS campaign. Screw you!

[botg]

Read several of my previous replies and this time contemplate on what's written.

[rossh]

Read several of my previous replies and this time contemplate on what's written.

Here is further evidence to show you have a bug.

If we connect Filezilla client to a Server, on port 990, which is implicit SSL, then guess what.... the client starts with a TLS v1.2 value in both inner and outer wrapper. That's right. Just like the spec says. TLS v1.2 is specified on the inner and outer wrappers. No mixed up confusing backward BS attempts here.

Therefore your not even consistent in your SSL methods. You get it right when its implicit SSL, and flat out wrong and buggy / invalid for the explicit situation.

****

Yes it even connects to a MS FTP server on port 990. But you you still have the same bugs that 3.53 has. A file upload fails because the server sends a error "550 The supplied message is incomplete. The signature was not verified" after the upload. I have no idea why, but it would seem that Filezilla is missing something here.

*****

So I suggest you get your head out of the clouds and fix your bugs.

[botg]

Thanks, implicit FTP over TLS should behaving exactly like explicit FTP over TLS. I'll investigate it further and change implicit FTP over TLS accordingly.

[rossh]

I fixed it.

I hacked your binary and replaced the priorities string value, used the gnutls_priority_set() function. I corrected the error in the config. Now I have a TLS 1.2 connection to an MS FTP server, and using the highest ciphers, and appropriate extension conditions. All of it now PCI compliant. And it still works with my old (9 years) Apache 1.3 server too.

Thanks for not helping with any of this.