Login  
Search All Forums
Dart Home | PowerTCP Sockets for .NET | Custom Development Reply | PowerTCP Sockets for .NET (Secure and Standard) Topics | Forums   
AuthorForum: PowerTCP Sockets for .NET (Secure and Standard)
Topic: Windows Update 3155464 stops TLS working as expected
iancurtis

From: United Kingdom
Posts: 5
Member Since: 02/18/16
posted May 19, 2016 10:05 AM

Hi,

A recent Windows update has introduced a problem when using TLS 1.0:

https://support.microsoft.com/en-us/kb/3155464

The change introduced in Microsoft Security Bulletin MS16-065 causes the first TLS record after the handshake to be split. This causes the SslStream, WebRequest (HttpWebRequest, FtpWebRequest), SmtpClient, and HttpClient (where based on HttpWebRequest) streams to return a single byte for the first read, immediately followed by the rest (n-1) bytes in successive reads. This behavior change only occurs for applications that use TLS 1.0 + Cipher Block Chaining, but not when they use TLS 1.1 or TLS 1.2.

There are 2 workarounds offered by Microsoft:

1. Switching to TLS1.1 or above. This is not possible below .Net 4.6 (not viable in our case).

2. Change the SslStream.Read implementation (see https://msdn.microsoft.com/en-us/library/system.net.security.sslstream.read(v=vs.110).aspx#Anchor_3). There does not appear to be any obvious way of achieving this with the current TcpAsyncCallback model.

Is there a Dart workaround for this issue?

Thanks,
Ian.
Nick B (Admin)

From: Utica, NY USA
Posts: 576
Member Since: 05/25/10

Extra Support Options
Custom Application Development

posted May 19, 2016 11:10 AM

Hello,

Are you encountering an issue due to this change?

------
-Non-current subscribers must contact sales@dart.com to update subscription and receive continued support as needed.
------

iancurtis

From: United Kingdom
Posts: 5
Member Since: 02/18/16
posted May 19, 2016 11:26 AM

Yes, following the update on the Windows 7 client, the server implementation TcpAsyncCallback handler (readCompleted) is passed only the first byte of the received Data in the first read. The remainder of the Data is passed to the readCompleted handler only when another message is received from the client.
kchildress

From: USA
Posts: 2
Member Since: 05/20/16
posted May 20, 2016 2:41 PM

I am experiencing the same symptoms. I believe the Windows x64 update that caused my problem is KB3142024. This update references the update the original poster references. Windows update is currently not working at the time of this post, so I am unable to investigate further.

This particular update caused several customer installations to stop working. As these installations are in secure environments, this is
Jamie Powell (Admin)

From: Rome, NY USA
Posts: 380
Member Since: 03/13/07

Extra Support Options
Custom Application Development

posted May 20, 2016 5:13 PM

Hello,

Thank you for the additional information. Messages are not guaranteed to be complete, so multiple read operations may be required to receive a full message.

To resolve this, your reading implementation should be designed so that it does not expect messages to be received complete, from a single read operation. ("This is a long test string" may be received in two separate read operations. ie: "This is a lo" and "ng test string") You'll want multiple read operations and to concatenate received data until you've received your full message (delimiters or length pre-pending are often used in various protocols).

This was tested with our included TCP Client and Server samples. When sending a message string to the Server sample from a button on the TCP Client sample with a single Tcp.Write() operation, the Server received both the first byte, and in the subsequent read (ReadAsync()) the rest of the message, without requiring an additional message to be sent to the server by the client.
iancurtis

From: United Kingdom
Posts: 5
Member Since: 02/18/16
posted May 23, 2016 5:59 AM

Hi,
our implementation is based on your asyncronous examples, however the readCompleted delegate is not called after the initial byte of data is received to complete the message. This has changed since the Windows update. I have included our implementation of the StartAsync and readCompleted delegate. I cannot see a difference between this and your examples. This is a critical blocker for our organisation.

public override void StartAsync(TcpBase tcp, bool requireClientCertificate)
    {
      tcpBase = tcp;

      // Authenticate as required
      Authenticate(tcp, requireClientCertificate);

      // Receive first data
      byte[] buf = new byte[MaxSSLPacketSize]; //buffer size is maximum length of ssl packet to ensure entire message block is read at once
      tcp.ReadAsync(buf, 0, buf.Length, new TcpAsyncCallback(readCompleted), null);
    }

void readCompleted(TcpBase tcp, Data data, Exception exception, object state)
    {
      try
      {
        if (data != null)
        {
          //handle the new data
          string message = "";
          incomingDataQueue.Append(data.ToString());

          //create a searchable string
          string idq = incomingDataQueue.ToString();

          if (idq.Contains(EndEnvelope))
          {
            while (idq.Contains(EndEnvelope))
            {
              //we have (at least one) message end tag - we can marshal it/them onto UI thread
              int start = idq.IndexOf(StartEnvelope); //start index of opening StartEnvelope
              int length = ((idq.IndexOf(EndEnvelope) + EndEnvelope.Length) - start); //end index of EndEnvelope

              message = idq.Substring(start, length); //get the message from the queue
              idq = idq.Substring((start + length)); //remove the message from the queue

              incomingDataQueue.Remove(0, (start + length)); //remove the message from the data queue

              //Receive next data
              tcp.ReadAsync(data.Buffer, 0, MaxSSLPacketSize, new TcpAsyncCallback(readCompleted), null);

              //marshal the message to the UI thread
              tcp.Marshal(null, message, null);
            }
          }
          else
          {
            //Receive next data
            tcp.ReadAsync(data.Buffer, 0, MaxSSLPacketSize, new TcpAsyncCallback(readCompleted), null);
          }
        }
      }
      catch (Exception ex)
      {
        tcp.Marshal(ex);
      }
    }

Thanks,
Ian.
kchildress

From: USA
Posts: 2
Member Since: 05/20/16
posted May 23, 2016 9:27 AM

I had buffering capabilities incorporated into my implementation. However, I didn't check for the case when a single byte was received. After checking for this case, my implementation now works as it had previously.
Reply | PowerTCP Sockets for .NET (Secure and Standard) Topics | Forums   
This site is powered by PowerTCP WebServer Tool PowerTCP WebServer for ActiveX