0 votes
by (120 points)

Hello Support Team,

we want to buy your Legacy Lib for TLS communication, but we want to try it first and have dwonlaoed your trail version.
We try to get the TlsSocket running on a Windows Embedded Compact 2013 system, but at the moment without any effort.
We setup an Apache Server with SSL functionality on Windows 10 system and want to connect from the Winodws Embedded Compact System to the Apache Server.
The conection itself is working, but when i run the command socket.Negotiate() the function will not return and the application freezes.
Below you can see the Log which i copied from the Windows Embedded Compact 2013 system from your library.

Can you help and tell me what iam donig wrong? Or do you have a test scenario, which i can try to execute?

Thank you in advance

Best regards,

Markus

LOG:

2022-10-18 08:30:38 Opening log file.
2022-10-18 08:30:38 INFO FileLogWriter(1)[33030594] Info: Assembly: Rebex.Common R5.9 for .NET Compact Framework 3.9
2022-10-18 08:30:38 INFO FileLogWriter(1)[33030594] Info: Platform: Windows CE 8.0.6294 32-bit; CLR: 3.9.19085.0
2022-10-18 08:30:38 DEBUG FileLogWriter(1)[33030594] Info: Culture: en; windows-1252
2022-10-18 08:30:38 INFO TlsClientSocket(1)[33030594] Info: Assembly: Rebex.Tls R5.9 for .NET Compact Framework 3.9 (Trial)
2022-10-18 08:30:38 INFO TlsClientSocket(1)[33030594] Info: Platform: Windows CE 8.0.6294 32-bit; CLR: 3.9.19085.0
2022-10-18 08:30:38 DEBUG TlsClientSocket(1)[33030594] Info: Culture: en; windows-1252
2022-10-18 08:30:39 DEBUG TlsSocket(52839839)[33030594] TLS: Enabled cipher suites: 0x000F3DF7EBE00640.
2022-10-18 08:30:39 DEBUG TlsSocket(52839839)[33030594] TLS: Applicable cipher suites: 0x00003C002BE00640.
2022-10-18 08:30:39 DEBUG TlsSocket(52839839)[33030594] TLS: Some ephemeral Diffie-Hellman ciphers are enabled. These might be slow on legacy platforms.
2022-10-18 08:30:39 DEBUG TlsSocket(52839839)[33030594] TLS: Some AES/GCM ciphers are enabled. These might be slow on legacy platforms.
2022-10-18 08:30:39 DEBUG TlsSocket(52839839)[33030594] TLS: HandshakeMessage:ClientHello was sent.
2022-10-18 08:30:39 DEBUG TlsSocket(52839839)[33030594] TLS: HandshakeMessage:ServerHello was received.
2022-10-18 08:30:39 INFO TlsSocket(52839839)[33030594] TLS: Negotiating TLS 1.2, RSA, AES with 256-bit key in GCM mode, AEAD.
2022-10-18 08:30:39 DEBUG TlsSocket(52839839)[33030594] TLS: The server supports secure renegotiation.
2022-10-18 08:30:39 DEBUG TlsSocket(52839839)[33030594] TLS: HandshakeMessage:Certificate was received.
2022-10-18 08:30:39 DEBUG TlsSocket(52839839)[33030594] TLS: HandshakeMessage:ServerHelloDone was received.
2022-10-18 08:30:39 DEBUG TlsSocket(52839839)[33030594] TLS: Verifying server certificate ('E=xxxxx, CN=xxxxx, OU=RnD, O=xxxx, L=xxxx, S=NRW, C=DE').
2022-10-18 08:30:39 DEBUG TlsSocket(52839839)[33030594] TLS: Certificate verification result: Accept
2022-10-18 08:30:39 DEBUG TlsSocket(52839839)[33030594] TLS: HandshakeMessage:ClientKeyExchange was sent.
2022-10-18 08:30:39 DEBUG TlsSocket(52839839)[33030594] TLS: CipherSpec:ChangeCipherSpec was sent.
2022-10-18 08:30:39 DEBUG TlsSocket(52839839)[33030594] TLS: HandshakeMessage:Finished was sent.

Applies to: Rebex TLS

1 Answer

0 votes
by (134k points)

Hello,

You don't seem to be doing anything wrong, but before I delve into details of a common cause of these kinds of issues, please try these:

  1. Try Connect/Negotiate with our test server at test.rebex.net:443. Does that work?
  2. Try Connect/Negotiate with Rebex TLS R5.9 Trial for Windows from a simple .NET Framework 3.5 console app. Does that work?
  3. If it does, try limiting the set of supported ciphers to match Windows Embedded Compact 2013:

var socket = new TlsClientSocket();
socket.Parameters.AllowedSuites = (TlsCipherSuite)0x00003C002BE00640;
...
socket.Connect(...);
socket.Negotiate();

The results of these experiments will hopefully point us in the right direction.


Now, let's look into your log. It looks like TLS negotiation started successfully, but then the client got stuck while waiting for the server's Finished message, which never arrived (the call should eventually time out if TlsSocket.Timeout has been set).

The problem is somewhat unusual - usually, when the TLS server doesn't accept client's TLS negotiation attempt, it closes the connection after receiving the ClientHello message. But in this case, the server responded and actually started the TLS negotiation.

The TLS client announced support for the following TLS ciphers in its ClientHello message:

RSA_WITH_3DES_EDE_CBC_SHA
RSA_WITH_AES_128_CBC_SHA
RSA_WITH_AES_256_CBC_SHA
DHE_RSA_WITH_3DES_EDE_CBC_SHA
DHE_RSA_WITH_AES_128_CBC_SHA
DHE_RSA_WITH_AES_256_CBC_SHA
RSA_WITH_AES_128_CBC_SHA256
RSA_WITH_AES_256_CBC_SHA256
DHE_RSA_WITH_AES_128_CBC_SHA256
DHE_RSA_WITH_AES_256_CBC_SHA256
RSA_WITH_AES_128_GCM_SHA256
RSA_WITH_AES_256_GCM_SHA384
DHE_RSA_WITH_AES_128_GCM_SHA256
DHE_RSA_WITH_AES_256_GCM_SHA384

(To get this list, cast the number from 'Applicable cipher suites' log entry to TlsCipherSuite.)

Notably, this lacks any ECDHE ciphers because Windows Embedded Compact 2013 still does not support them in a way required by TLS 1.2). For details on this limitation, see Elliptic Curve Cryptography support in Rebex SSH and Rebex TLS.

This is increasingly becoming a problem, because many TLS 1.2 servers are being configured to require ECDHE ciphers. To work around this, we published a set of plugins that add support for them. Please try adding and initializing the Rebex.Castle plugin to your .NET CF application and give it a try. (But try the three experiments from the beginning first - if you are unable to connect using the desktop version of Rebex TLS, it's unlikely that .NET CF version would work.)

by (120 points)
Hello,

thank you very much for your quick reply. We got it working now! We found that the problem was the debugger, which is connnected over Ethernet. If detach the te debugger, the connection is working fine.
So thank you again for your help, we have already sent a message that you will make us an offer for this library.

Best regards,

Markus
by (134k points)
Thanks for letting us know!
...