EldoS | Feel safer!

Software components for data protection, secure storage and transfer

HTTPS on Compact Framework (CE 5/6) - VERY SLOW

Posted: 02/16/2015 10:20:18
by Jean Philippe (Basic support level)
Joined: 05/15/2014
Posts: 10

I don't see real difference between the first and the following requests.

But when I look at the implementation, it creates a new client thread for each request. Could this be related to that sample ?

private void ListenForClients()
m_tcpListener = new TcpListener(IPAddress.Any, m_port);

while (true)
TcpClient client;

client = m_tcpListener.AcceptTcpClient();
catch (Exception)

ClientThread clientThread = new ClientThread(this, client, m_certStorage,
m_sslMode, m_basePath);

ThreadStart job = new ThreadStart(clientThread.Execute);
Thread thread = new Thread(job);
Posted: 02/16/2015 14:52:04
by Ken Ivanov (Team)

Hi Jean-Philippe,

While the slowdown generally might be related to thread management somehow, I don't think that's the case in your particular scenario (as you only establish one or two test connections). We will try to reproduce the slowdown issue locally and get back to you shortly.

BTW, do the test connections come from a local (relatively to the CF device) network interface or from the outer network?

Posted: 02/18/2015 04:13:58
by Jean Philippe (Basic support level)
Joined: 05/15/2014
Posts: 10

Hi Ken,

I'm in debug mode over usb (with activesync).
But I request web page with a web browser on the ethernet ip of the board.

This is the only application running. We are not running our embedded application for testing now. (that supports only unsecured http for now)

Thank you for your analyses,
Best regards,
Posted: 02/18/2015 08:24:55
by Ken Ivanov (Team)

Hi Jean-Philippe,

We've measured the times of operations performed on different TLS negotiation stages and came to a conclusion that the lion's share of the protocol negotiation time is consumed by asymmetric cryptographic primitives (such as RSA, EC and DHE computations). While remaining unnoticed on more powerful desktop and server platforms, these operations slow the things down significantly on older and less powerful WinCE platform - it is just too old for modern key lengths. SecureBlackbox sample certificate carries a 2048 bit key, which is twice as long as a de-facto standard of 1024 bit being used at the time the platform was released.

We still can do something to reduce the load put on the CPU of the device. The solution is pretty straightforward - to decrease the number of heavy cryptographic operations per session. This can be achieved by only leaving performance-effective cipher suites enabled:

for (short i = SBSSLConstants.Unit.SB_SUITE_FIRST; i <= SBSSLConstants.Unit.SB_SUITE_LAST; i++)
    server.set_CipherSuites(i, false);
                server.set_CipherSuites(SBSSLConstants.Unit.SB_SUITE_RSA_AES128_SHA, true);

The 'effective' (from WinCE viewpoint) cipher suites are given below:


Besides, if your requirements allow you to do so, you might consider using a server certificate with shorter key length (but at least 1024 bits). This will also help speed the things up.




Topic viewed 2057 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!