Runtime: TLS 1.2 - Zero length fragment error occurs in .NET Core when spec allows it

[alexkeh]

My team is implementing .NET Core dead connection detection for the Oracle DB. After some idle time, we send a zero length fragment of application data from the server. .NET returns an error via the Oracle data provider.

According to the TLS 1.2 specification (RFC 5246) "Zero-length fragments of Application data MAY be sent as they are potentially useful as a traffic analysis countermeasure." See Section 6.2.1 of the spec. See below for the call stack.

We request .NET Core interpret these message types as TLS zero length fragments instead of requiring the message have a signature. The TLS implementation should just ignore the fragment.

Abbreviated stack:

Oracle.ManagedDataAccess.Client.OracleException (0x80004005): ORA-12570: Network
 Session: Unexpected packet read error
---> OracleInternal.Network.NetworkException (0x80004005): ORA-12570: Network Session: Unexpected packet read error
---> System.IO.IOException: The decryption operation failed, see inner exception.
---> System.ComponentModel.Win32Exception: The supplied message is incomplete. The signature was not verified
   --- End of inner exception stack trace ---
   at System.Net.Security.SslStreamInternal.ReadAsyncInternal[TReadAdapter](TReadAdapter adapter, Memory`1 buffer)
   at System.Net.Security.SslStreamInternal.Read(Byte[] buffer, Int32 offset, Int32 count)
   at System.Net.Security.SslStream.Read(Byte[] buffer, Int32 offset, Int32 count)

[alexkeh]

An additional point from @scotmac that should be noted:

Support for "zero length fragments" is part of the base functionality for TLS 1.2 RFC specification. Thus, .NET Core currently not supporting it is not an enhancement, but instead a bug.

[stephentoub]

Can you please share an isolated repro we can run? This error appears to be coming directly from the OS implementation, which .NET just wraps.

[karelz]

We might be able to call into Windows in a specific way -- needs discussion with OS team.

[davidsh]

We might be able to call into Windows in a specific way -- needs discussion with OS team.

I've sent email to Windows SCHANNEL team asking for guidance.

[davidsh]

@alexkeh

Initial feedback from the Windows SCHANNEL team is that 0-length application_data messages are not currently supported.

Have you tried .NET Core on Linux to see if it works there? On Linux, .NET Core uses OpenSsl mostly (or MacOS specific libraries).

Do you have a simple repro/server that can generate these 0-length messages? That would be useful to help further troubleshooting. Thanks.

[ScotMac]

@davidsh i believe a simple SSL connection, that, after the handshake, just has the client do a read and the server send a application data record of the format: 0x17 0x03 0x03 0x00 0x00
will reproduce the problem.

[karelz]

@ScotMac can you please create such repro and try it on Linux? That would be very helpful. Thanks!

[ScotMac]

@karelz Actually, i believe our test team has tried via our library on Linux. Let me recheck with them and i will let you know the results.

[ScotMac]

It is also failing on .NET Core on linux (openSSL). It appears to fail a slightly different way for each of the different implementations.

• Framework: interprets the TLS Zero Length fragment as a TCP zero length receive (EOF). Note, not necessarily an SChannel issue. Could be a .NET interpretation of the SChannel return causing the problem.

• Core on Windows: Incorrectly looks for a signature, when one is not necessary for a zero length fragment.

• Core on Linux: Decryption code incorrectly looks for "block cipher pad", when it is not necessary for a zero length fragment.

[davidsh]

Core on Linux: Decryption code incorrectly looks for "block cipher pad", when it is not necessary for a zero length fragment.

@bartonjs Can you comment on this? Does OpenSsl on Linux support zero length fragments? Is this scenario possible on Linux or Mac in general?

[bartonjs]

@davidsh No idea. A quick search turned up a bug in a product saying that it works at OpenSSL's layer, but not theirs. We may have a similar problem if we're failing.

When it comes to TLS I'm more a black-box user with a good understanding of what's going on around it.

[wfurt]

we can test more @davidsh when we get runable repro or specific steps to reproduce.

[karelz]

Triage: Test it with the sample from Windows team.