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:
- Try
Connect/Negotiate with our test server at test.rebex.net:443. Does that work?
- Try
Connect/Negotiate with Rebex TLS R5.9 Trial for Windows from a simple .NET Framework 3.5 console app. Does that work?
- 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.)
