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

[pcheng31]

Look: We know there's a bug somewhere - it might be with Filezilla it could be with IIS. Either way - we know what the solution is - and clearly many other FTP clients have implemented work arounds for it.

The user doesn't really care if the bug is with IIS, all the user cares about is 1) he can't fix the server - because he's not an admin and 2) it doesn't work.

What would be wrong with implementing a fix for this behaviour? Many people implement fixes for things that don't work quite right every day. If your car doesn't start with the headlights on are you going to sit there are keep starting it with the headlights on? No, you're going to turn off the headlights, start your car, and then turn your headlights back on. It'd be nice if we could fix this.

This is turning into the same story as issue 4672. We know there's a problem, and we know the workaround - but no-one seems to have implemented it.

Look at it another way - if the road is blocked by a asteroid, are you going to keep going down the road saying: "But road safety standards say to drive down the road!" or are you going to just detour on the shoulder? Sure you can stop and wait for the Department of Transportation to come out and move the asteroid, but really it would be easier to just drive on the shoulder. If you haven't noticed many people are just downgrading to 3.5.2 or switching to another client.

Also are you saying that 3.5.2 works because you were doing the ClientHello negotiation "wrong" and have now "fixed" it?

Thanks again.

[botg]

Doesn't RFC 5246 also say:

A TLS 1.2 client who wishes to negotiate with such older servers will
send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
ClientHello.client_version. If the server does not support this
version, it will respond with a ServerHello containing an older
version number. If the client agrees to use this version, the
negotiation will proceed as appropriate for the negotiated protocol.

So the way I interpret this part of the RFC is for a TLS 1.2 Client to negotiate with a server (of unknown version) we start with TLS 1.2 assumed and send a clientHello with (3,3).

Then if the server is not TLS 1.2 compliant and is an older server it should respond with a ServerHello with the highest version supported by the server.

There are two versions. The ClientHello is encapsulated in a record structure which also carries a version. This entire discussion is about the record version of the first packet containing the ClientHello, not the version of the actual ClientHello.


If using FileZilla, a ClientHello with a {3,3} version is sent indicating TLS 1.2 support, encapsulated in a record structure versioned {3,0}. A compliant TLS 1.2 server is required by the specifications (MUST) to ignore the record version of the ClientHello.

Also are you saying that 3.5.2 works because you were doing the ClientHello negotiation "wrong" and have now "fixed" it?

Actually I haven't changed anything in this regard. This is a side-effect of switching to a newer GnuTLS version. FileZilla 3.5.3 used GnuTLS 2.10.4, FileZilla 3.6.0.2 uses GnuTLS 3.1.4. As far as I can tell this change has been done in GnuTLS over 2 years ago during the making of GnuTLS 3.0 and the reason for this change was that indeed, a wrong version was being sent in some cases which is no longer the case. See https://gitorious.org/gnutls/gnutls/com ... c8cd192d62 and https://gitorious.org/gnutls/gnutls/com ... 37ca685f91, this change is correct and the resulting behavior is allowed by the TLS 1.2 specs.

[botg]

presumably because a large proportion of the market has already implemented some fix. Wouldn't it be great if Filezilla could have that fix too?

Please don't confuse a fix with a workaround.


On a related note, has it actually been proven that the record layer version is actually what's triggering a problem? So far we've all been discussing on an unverified claim that the record version is triggering the problem, with the plaintiff claiming it's a bug in FileZilla whereas the specs clearly say that IIS is at fault if it were handle the record version incorrectly.

[mtceegee]

Of the popular FTP clients I've tested, only FileZilla 3.6.0.2 seems to have a problem with post - BEAST exploit changes for Windows Server R2 2008 and above.

The following FTP clients seem to access fine:

1. Dreamweaver CS6
2. Core FTP
3. Cute FTP
4. Smart FTP

If there were some way to ensure MS servers were both PCI compliant and made FileZilla happy, that would be ideal.

[botg]

@mtceegee: You wouldn't by chance be able to provide me with a test account on an affected server?

@boco: I wouldn't mind a shot at tinkering with a space station as long as I don't have to clean up afterwards

[mtceegee]

Hi botg: Let me set one up for you and I'll shoot you credentials offline. Hope that helps.

[pcheng31]

You're right - it's not a fix, but rather a workaround. Regardless: Once we verify the issue (and how can we IIS admins help with this process?) can we (assuming this is the issue) create a workaround for improved compatibility?

Thanks

[ginno88]

The most important question: Is it possible to make changes to FileZilla so that it works with IIS 8 and stays compliant with the RFC? If the answer is yes, then the only reason left not to make the change is that you don't want to do it.

[botg]

Such a change would break compatibility with other servers.

[ginno88]

I would have thought that you were a better programmer than that. I'm sure a halfway decent programmer could make it work with IIS 8 and not break compatibility with other servers, if they wanted to.

[botg]

Nope, not possible. Just fix your broken server.

[rossh]

I would have thought that you were a better programmer than that. I'm sure a halfway decent programmer could make it work with IIS 8 and not break compatibility with other servers, if they wanted to.

You are correct. I managed to make it all work on all the servers I have access to - old and new - utilizing both older and newest protocols.. Sorry, but I'm not sharing - its a private build.

Nope, not possible. Just fix your broken server.

There is a one word answer for this. BS !

We are not interested in your little (naive) attempts to bully MS around. It's a worthless pursuit - no one at MS can here you.

Stop trying to hide behind made up nonsense excuses. Get this thing fixed. Or maybe as the poster above has implied - your not good enough to do it?

[botg]

I managed to make it all work on all the servers I have access to - old and new - utilizing both older and newest protocols.

And what about the plethora of servers you do not have access to?

We are not interested in your little (naive) attempts to bully MS around.

As I have said before, who the server vendor is does not matter. Only thing that matters is that the server doesn't seem to follow the TLS specifications. Thus the server needs to be fixed. Simple as that. Now stop defending a broken server and possibly some failed investment and either fix the server or switch to a different server product.

Get this thing fixed. Or maybe as the poster above has implied - your not good enough to do it?

I'm such a bad programmer. I cannot even waltz into Microsoft headquarters, get access to IIS' source code, make changes in some foreign codebase and release a fixed version. But surely you can, you're so good, you can even recognize me as bad programmer. So be my guest, fix the server!

[j.maletzky]

@Site Admin

Only for the record.

Filezilla doesn't work with Windows Server 2008 R2 and 2012 FTPS-Server, if TLS 1.1 and 1.2 is enabled.

Filezilla WORKS correctly with Windows Server 2008 R2 and 2012, if ONLY TLS 1.1 is enabled AND
the cipher suite priority is changed to TLS_RSA_WITH_RC4_128_SHA on top of the list.

That's our short time workaround.

All your reactions to the problem lead us to advise our users NOT to use your programs
anymore and use alternatives, because you are not willing to listen to your
users and fix this problem and future problems on your side, if you can.


Joerg

[botg]

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?