EldoS | Feel safer!

Software components for data protection, secure storage and transfer


Posted: 07/01/2011 07:02:00
by John Daintree (Priority Standard support level)
Joined: 10/18/2010
Posts: 20

I'm getting a frequent, but not totally predictable error when receiving data on the ElSimpleSSLClient object.

I am able to receive data from the (encrypted) socket, but every now and again (i.e. it's not always the same place in the data) I get an error thrown.

The OnError function is called, and has been called from SBClient.TElSecureClient.TLS1ParseOnRecordLayer, which has been given the following parameters:

TLS1ParseOnRecordLayer(byte[] Buffer = {byte[0x00010000]}, int Size = 0x00000015, SBSSLCommon.TSSL3ContentType ContentType = ctApplicationData, int DTLSEpoch = 0x00000000, long DTLSSeqNum = 0x0000000000000000);

If I look at the Buffer in the debugger its first 0x15 bytes are:

Buffer {byte[0x00010000]} byte[]
[0x00000000] 0x01 byte
[0x00000001] 0x50 byte
[0x00000002] 0x71 byte
[0x00000003] 0xe5 byte
[0x00000004] 0x55 byte
[0x00000005] 0x9b byte
[0x00000006] 0x42 byte
[0x00000007] 0x93 byte
[0x00000008] 0xe1 byte
[0x00000009] 0x82 byte
[0x0000000a] 0xce byte
[0x0000000b] 0x4e byte
[0x0000000c] 0x32 byte
[0x0000000d] 0x96 byte
[0x0000000e] 0xd1 byte
[0x0000000f] 0x5f byte
[0x00000010] 0x9f byte
[0x00000011] 0x44 byte
[0x00000012] 0x38 byte
[0x00000013] 0x89 byte
[0x00000014] 0xd9 byte
[0x00000015] 0xe7 byte

The server side of this is running a gnutls library for its encryption, which is the same library we've used reliably elsewhere without this problem.

The error code passed to OnError is 0x12802 (ERROR_SSL_BAD_RECORD_MAC).

I've about reached the limit of my knowlege on this, any suggestions anyone?

Posted: 07/01/2011 07:13:44
by Vsevolod Ievgiienko (Team)

Thank you for contacting us.

Try to disable TLS 1.2 using ElSimpleSSLClient.Versions property.
Posted: 07/01/2011 07:21:17
by Eugene Mayevski (Team)

The fact that gnutls client worked with gnutls server proves only that they have been tested with each other. Unfortunately this doesn't say that the server itself doesn't have issues.

Now let's narrow down the problem. To do this please answer the following questions:

1) does the problem happens during handshake (i.e. no data have been transferred) or after some data have been received/sent?

2) do you have this problem in silverlight code? If yes, please check the same scenario with test desktop application. This will tell us if the problem is specific to silverlight sockets (I think it is) or with protocol itself

3) is it possible for us to see this problem (ie. can it be reproduced on our side somehow or maybe you can give a test project with access to your server)?

Sincerely yours
Eugene Mayevski
Posted: 07/01/2011 07:29:36
by John Daintree (Priority Standard support level)
Joined: 10/18/2010
Posts: 20

It's already disabled. In fact I tried enabling it after sending this report, but it still failed. The options I've set are:

bUseSSL2 = false;
bUseSSL3 = true;
bUseTLS1 = true;
bUseTLS11 = false;
bUseTLS12 = false;

Posted: 07/01/2011 07:53:02
by John Daintree (Priority Standard support level)
Joined: 10/18/2010
Posts: 20

Hi Eugene,

Handshake has succeeded and I have sent and received data on the socket. This is a silverlight application. It'll take me a while to create a desktop application but I'll get on to it. I may also be able to send you the silverlight app that you could try, but I'll try a desktop solution first.

Posted: 07/01/2011 08:06:22
by Eugene Mayevski (Team)

Yes, please check with desktop solution. I suspect that it's a problem of messed packets in Silverlight's asynchronous socket implementation, but I am afraid that this is a problem of Silverlight itself and we will have to look for some workaround.

Sincerely yours
Eugene Mayevski



Topic viewed 837 times

Number of guests: 1, registered members: 0, in total hidden: 0


Back to top

As of July 15, 2016 EldoS business operates as a division of /n software, inc. For more information, please read the announcement.

Got it!