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

[boco]

Thanks for testing.

@botg: Could that be a GnuTLS thing, again?

[rossh]

I may have found your bug. Set up a protocol TLS 1.2 at both ends. Capture the failed session on Wireshark. With the Client Hello packet from the client selected, tell Wireshark to interpret it as an SSL packet - Menu - Analyse, Decode as, Select transport, set SSL.

Now see the packet details - SSL Record Layer - Version - its set to SSL 3.0 (0x0300). It probably should be set to TLS 1.2 (0x0303). Further down in the Handshake protocol - Version - it says 0x0303 (TLS1.2). thats in conflict with the outer Version detail.

The rest of the packet seems OK.

It may require that the code needs to check the max protocol to be used, and fill in the Version field to match. Here the client is making a 1.2 connection, but describing itself as talking in 3.0/1.0 protocols. Maybe that's not allowed. Perhaps the two version fields need to agree too.

If I do the same test on an IE browser setting up a normal https / SSL page in TLS 1.2, then it has TLS 1.2 (0x0303) for both the Version fields.

[rossh]

Here is that packet. I adjusted the IP's, but the rest is the same.

Its in hexASCII and needs to be converted to binary.

Save the below into a text file. In WinHex, open and then Edit, Convert HexASCII to Binary. Save as file name Bad_CH.pcapng

In Wireshark open above, Menu - Analyze, Decode as, Select transport, set SSL.

Code: Select all

0A0D0D0A900000004D3C2B1A01000000FFFFFFFFFFFFFFFF0300380036342D6269742057696E646F77732053657276657220323030382052322053657276696365205061636B20312C206275696C64203736303104002D0044756D7063617020312E382E36202853564E205265762034383134322066726F6D202F7472756E6B2D312E38290000000000000090000000010000009400000001000000FFFF0000020032005C4465766963655C4E50465F7B34344338393736352D363733332D343944412D413541462D3039374434354334313943427D000009000100060000000C00380036342D6269742057696E646F77732053657276657220323030382052322053657276696365205061636B20312C206275696C6420373630310000000094000000040000009C00000001001700173BBF3A61313336332E672E616B616D61692E6E6574000001001700173BBF2A61313336332E672E616B616D61692E6E6574000001001500C074F2147777772E737461727473736C2E636F6D0000000001001800A5FE635361313630332E67312E616B616D61692E6E65740001001800A5FE631861313630332E67312E616B616D61692E6E657400000000009C00000006000000040100000000000025D90400F49E1DE1E4000000E4000000D4AE52C11FA4000D669578000800450000D60E9340007506370B0102030409080706083F00DD001407F3BB77EF885018FAA4EA89000016030000A9010000A50303515701E49349352CB21DB3E17BD03E838DD411D205421D3F5992A924801B3776000044C024C00AC02CC023C009C02BC014C030C027C013C02F006B00390088006700330045009E006A0038008700400032004400A20066003D00350084003C002F0041009C000501000038000500050100000000FF0100010000230000000A00080006001800190017000B00020100000D0010000E050105030601060304010402040304010000050000006C0000000000000025D90400D195CDE101001C00436F756E746572732070726F76696465642062792064756D706361700200080025D904007AA4BEDE0300080025D90400D195CDE1040008000E05000000000000050008000000000000000000000000006C000000

Even RFC 5246 in appendix E, talks about the troubles surrounding this issue.

[botg]

If you look at the earlier dump:

0000000A 16 03 00 00 a9 01 00 00 a5 03 03 51 51 c9 40 5e ........ ...QQ.@^

GnuTLS, as invoked by FileZilla, requests use of TLS 1.2 (03 03).


Note that the SSL3 record layer version (03 00) does not matter here, it is in fact this is perfectly valid behavior:

E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0

Earlier versions of the TLS specification were not fully clear on
what the record layer version number (TLSPlaintext.version) should
contain when sending ClientHello (i.e., before it is known which
version of the protocol will be employed). Thus, TLS servers
compliant with this specification MUST accept any value {03,XX} as
the record layer version number for ClientHello.

TLS clients that wish to negotiate with older servers MAY send any
value {03,XX} as the record layer version number. Typical values
would be {03,00}, the lowest version number supported by the client,
and the value of ClientHello.client_version. No single value will
guarantee interoperability with all old servers, but this is a
complex topic beyond the scope of this document.

Assuming the problem is just the SSL3 record layer version, I see no reason to act on my side. The server needs to be fixed.

[rossh]

If you look at the earlier dump:

0000000A 16 03 00 00 a9 01 00 00 a5 03 03 51 51 c9 40 5e ........ ...QQ.@^

GnuTLS, as invoked by FileZilla, requests use of TLS 1.2 (03 03).


Note that the SSL3 record layer version (03 00) does not matter here, it is in fact this is perfectly valid behavior:



Assuming the problem is just the SSL3 record layer version, I see no reason to act on my side. The server needs to be fixed.

No. You have the SAME fault as in the earlier dump. The outer wrapper says SSL 3.0, and the inner wrapper says TLS 1.2. This is contrary to how the IE and MS does it in my other test. It will specify 1.2 in both.

Placing your trust in "MAY" statement, is a weak excuse. Better code will result if you follow the SHOULD definitions.

Code: Select all

/...I see no reason to act on my side. The server needs to be fixed.

This kind of ignorance, will not fix your problems. Its also offensive and highlights a naive approach to your coding styles. Wake up. If you want your program to function in a fully TLS 1.2 and secure world, then you are going to have to catch up to reality.

I can see I wasted my time here. thanks.

[botg]

If the standard allows it, it's not wrong. What is not wrong does not need to be fixed. What needs to be fixed is a piece of software that does not handle what the standard allows.

One can work around a problem or one can fix the problem at the root. I prefer doing the latter whenever possible.

If you want your program to function in a fully TLS 1.2 and secure world, then you are going to have to catch up to reality.

It already works in a fully TLS 1.2 and secure world. Provided the server has been implemented correctly.

[rossh]

This naive utopian view of yours - its silly. Your not inventing anything new here - just trying to fit into the existing servers and practices that have been with us for years. At the end of the day - all we want is a client that works, with all servers. TLS 1.2 is quite old, but only recently started to be adopted, including Filezilla. But you seem to have an agenda for some other purpose.

MS is not going to change a server code just to suit your sloppy coding desires. The RFC is very specific about the issues you will encounter with your current coding methods. In fact RFC 5246 Appendix E has three paragraphs discussing this very issue and finishes with the warning "No single value will guarantee interoperability with all old servers....". Yet your program tries to do just that - sends out conflicting version methods, and fails because of it. Doh!

You hold the RFC in high regard, but then ignore the warnings, difficulties it describes, and its suggested methods on this very issue. What makes you such a hypocrite?

[botg]

My agenda: Follow the standards, don't do workarounds.

Tell me what's wrong with the handshake FileZilla sends by quoting the part of the standard that says how to do it.

I'll answer this for you: You cannot. There's nothing wrong with the handshake.

If your server cannot handle proper handshakes, then your server needs to be fixed or replaced, simple as that. I"m not going to work around an implementation problem in your server, only to potentially break compatibility with other servers. IIS is only one of many servers, it is not special.

Here's what's wrong with your server:

Thus, TLS servers
compliant with this specification MUST accept any value {03,XX} as
the record layer version number for ClientHello.

Please contact Microsoft and let them know about this problem with their server.

[rossh]

There is NO work around required. You simply MUST send accurate information for a TLS 1.2 connection about the protocol your using. How simple is that? i.e follow the RFC and stop trying to misinterpret them.

Your a fool if you think MS is going to change anything, just for you. Of course we realize that you know MS wont change, and you are just taking a position for the sake of argument. All the public needs is a program that works, but that seems to give way to your preference for personal posturing.


********

0/ Your making a TLS 1.2 connection by choice. You MUST specify this in the Record layer version field.

1/ Your current approach is to send conflicting data, and then hope you can get away with it. That's wrong, and extremely poor coding. The rules do not allow you to do this in a TLS 1.2 connection.

2/ You are NOT making a connection to an older SSL server ! You are deliberately making a new TLS 1.2 connection. Therefore you cannot apply the rules for "backward connecting to old servers". Your arguments are invalid. You MUST use 1.2 rules, which require a value of 3.3 in the Record Layer Version field.




Just to make sure we get the facts straight......


Note that it says below, for a TLS 1.2 connection, the version is to be 3,3 (0x0303)

Code: Select all

RFC 5246                          TLS                        August 2008

6.2.  Record Layer

   The TLS record layer receives uninterpreted data from higher layers
   in non-empty blocks of arbitrary size.

6.2.1.  Fragmentation

   The record layer fragments information blocks into TLSPlaintext
   records carrying data in chunks of 2^14 bytes or less.  Client
   message boundaries are not preserved in the record layer (i.e.,
   multiple client messages of the same ContentType MAY be coalesced
   into a single TLSPlaintext record, or a single message MAY be
   fragmented across several records).

      struct {
          uint8 major;
          uint8 minor;
      } ProtocolVersion;

<snip>

   version
      The version of the protocol being employed.  This document
      describes TLS Version 1.2, which uses the version { 3, 3 }. 

<snip>

All this below applies to Backward Compatibility with TLS 1.0/1.1 and SSL 3.0 OLD servers. But in our issue, you are connecting to a NEW TLS 1.2 server.

These rules below do NOT apply to a 1.2 connection.

Code: Select all

RFC 5246                          TLS                        August 2008

Appendix E.  Backward Compatibility

E.1.  Compatibility with TLS 1.0/1.1 and SSL 3.0

   Since there are various versions of TLS (1.0, 1.1, 1.2, and any
   future versions) and SSL (2.0 and 3.0), means are needed to negotiate
   the specific protocol version to use.  The TLS protocol provides a
   built-in mechanism for version negotiation so as not to bother other
   protocol components with the complexities of version selection.

   TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use
   compatible ClientHello messages; thus, supporting all of them is
   relatively easy.  Similarly, servers can easily handle clients trying
   to use future versions of TLS as long as the ClientHello format
   remains compatible, and the client supports the highest protocol
   version available in the server.

   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.

   If the version chosen by the server is not supported by the client
   (or not acceptable), the client MUST send a "protocol_version" alert
   message and close the connection.

   If a TLS server receives a ClientHello containing a version number
   greater than the highest version supported by the server, it MUST
   reply according to the highest version supported by the server.

   A TLS server can also receive a ClientHello containing a version
   number smaller than the highest supported version.  If the server
   wishes to negotiate with old clients, it will proceed as appropriate
   for the highest version supported by the server that is not greater
   than ClientHello.client_version.  For example, if the server supports
   TLS 1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will
   proceed with a TLS 1.0 ServerHello.  If server supports (or is
   willing to use) only versions greater than client_version, it MUST
   send a "protocol_version" alert message and close the connection.

   Whenever a client already knows the highest protocol version known to
   a server (for example, when resuming a session), it SHOULD initiate
   the connection in that native protocol.

   Note: some server implementations are known to implement version
   negotiation incorrectly.  For example, there are buggy TLS 1.0
   servers that simply close the connection when the client offers a
   version newer than TLS 1.0.  Also, it is known that some servers will
   refuse the connection if any TLS extensions are included in
   ClientHello.  Interoperability with such buggy servers is a complex
   topic beyond the scope of this document, and may require multiple
   connection attempts by the client.

   Earlier versions of the TLS specification were not fully clear on
   what the record layer version number (TLSPlaintext.version) should
   contain when sending ClientHello (i.e., before it is known which
   version of the protocol will be employed).  Thus, TLS servers
   compliant with this specification MUST accept any value {03,XX} as
   the record layer version number for ClientHello.

   TLS clients that wish to negotiate with older servers MAY send any
   value {03,XX} as the record layer version number.  Typical values
   would be {03,00}, the lowest version number supported by the client,
   and the value of ClientHello.client_version. No single value will
   guarantee interoperability with all old servers, but this is a
   complex topic beyond the scope of this document.

[botg]

It goes both ways: You're a fool if you think I am going to change anything just for IIS, especially since the specs say that I'm doing everything right and that IIS is wrong.

Appendix E applies to both TLS1.2 clients and servers. This section specifies the mechanism for clients to stay compatible with older servers, however for this to work properly, TLS 1.2 servers need to be prepared for clients wishing to do so. The specifications are very clear: TLS 1.2 servers MUST accept {03,XX} as the record layer version number for the ClientHello packet.

[xeon]

Microsoft has a long and proud history of breaking standards, especially when it comes to crypto. This particular problem has been known to them for years now, they just haven't patched it yet.

It's been discussed in detail on the TLS mailing list.

[botg]

My suggestion: Put an Apache as reverse proxy in front of IIS.

[rossh]

It goes both ways:

NO it doesn't. When you read the specs closely, its clear that if you intend a v1.2 connection, then you specify that. When you specify v1.2 on the inner Version, you MUST also specify on the outer version. The specs are clear on this!

But your trying to use the backward rules, but you not making a backward connection. You would only try that if the request for 1.2 was denied.

When you attempt a backward connection, logic dictates that you cannot put a higher version on the inside. If attempting a backwards connection, your inner version cannot logically be higher than the outer version. That just plain common sense.

Now if only want to go with a 1.0 connection (as you are currently communicating) then lock the client down to max v1.0 - inner and outer versions.

You're a fool if you think I am going to change anything just for IIS, especially since the specs say that I'm doing everything right and that IIS is wrong.

Upon review It would seem that MS is correct, and your code is wrong.

But more importantly - Its remarkably offensive and abuse of you position as project admin, to turn this into a anti-MS campaign. All this avoiding the bug fix, because you don't like MS. Grow up! Most people don't give a crap about your utopian views and ideal world nonsense. We just want something that works.

Appendix E applies to both TLS1.2 clients and servers. This section specifies the mechanism for clients to stay compatible with older servers, however for this to work properly, TLS 1.2 servers need to be prepared for clients wishing to do so. The specifications are very clear: TLS 1.2 servers MUST accept {03,XX} as the record layer version number for the ClientHello packet.

Once again you have this WRONG. You are NOT trying to make a 1.1 or 1.0 or 3.0 connection. You are attempting to make a 1.2 connection. This section applies only to 1.2 server that is receiving a 1.1. or lower connection request (not our situation). MS is correct to reject your attempt under this mixed spec attempt, because 1.2 does not allow for mixed spec connections.

[rossh]

Microsoft has a long and proud history of breaking standards, especially when it comes to crypto. This particular problem has been known to them for years now, they just haven't patched it yet.

It's been discussed in detail on the TLS mailing list.

Yes they do ignore things, but in this case, they are correct. Also this is NOT a crypto fault. Its an error in a client when specifying its intended protocol version.

Filezilla cannot request backward version rules, and then try to communicate the newest version specs through that. Logically that's a conflict and an error.

[botg]

Look at the handshake. FileZilla requests TLS 1.2, but allows to fall back to an older version of the server does not support TLS 1.2. There is nothing wrong with it.

NO it doesn't. When you read the specs closely, its clear that if you intend a v1.2 connection, then you specify that. When you specify v1.2 on the inner Version, you MUST also specify on the outer version. The specs are clear on this!

Please point our the relevant text from the specs.

When you attempt a backward connection, logic dictates that you cannot put a higher version on the inside. If attempting a backwards connection, your inner version cannot logically be higher than the outer version. That just plain common sense.

The specs say otherwise in appendix E. When working with protocols, shut off your common sense and follow the specifications.

Its remarkably offensive and abuse of you position as project admin, to turn this into a anti-MS campaign

That's not my intention. If anything, it is a pro-IETF campaign. In this case it is IIS not working according to the specifications, but it could be any other product.

All this avoiding the bug fix, because you don't like MS

I'm not avoiding the bug fix, I just cannot fix this bug as it is not in my product.