Why is file download with Rebx HTTPS on Windows Mobile 6.5.3 so slow?

Question

I am downloading a 4 MB file with the following code:

var client = new Rebex.Net.WebClient();
client.LogWriter = new Rebex.FileLogWriter(logFilePath, Rebex.LogLevel.Debug);
client.DownloadFile(downloadURL, targetFilePath);

Using the latest version of Rebex HTTPS (2018-10-26 Version 2018 R3) on Windows Mobile 6.5.3 devices I get a very low download speed:

16 kB/s on a Zebra MC659B (https://bit.ly/2rtSIZy)
32 kB/s on a Zebra MC67NA (https://bit.ly/2B8KkD5)

There is no difference in speed between downloading from Google Drive or Dropbox, between 3G cellular or Wi-Fi Internet connection. Log file and target file are on the internal flash drive, which is fast enough. Any other components to consider?

According to the Rebex log file, the connection is secured using cipher: TLS 1.2, RSA with ephemeral Elliptic Curve Diffie-Hellman, AES with 128-bit key in GCM mode, AEAD.

Windows Mobile is now called WEHH (Windows Embedded Handheld). The Devices are running WEHH 6.5 Professional AKU 29315 (MC659B) or 29377 (MC67NA). The .NET version is 3.5.9198.0 (should be the latest).

Any idea, why downloading is so slow? Is the Trial version of Rebex HTTPS (testing with that one) slower than the full version?

Answer 1

The trial version has no speed limitation, it has the same performance as full version.

The probable reason for slow performance is using GCM mode to secure the connection.

The selected cipher suite corresponds to following setting:

client.Settings.SslAllowedSuites = TlsCipherSuite.ECDHE_RSA_WITH_AES_128_GCM_SHA256;

Since the cipher suite is selected by the server, please try to limit allowed cipher suites on client = enable only cipher suites using CBC mode.
It can be done like this:

client.Settings.SslAllowedSuites =
    TlsCipherSuite.ECDHE_RSA_WITH_AES_256_CBC_SHA384 |
    TlsCipherSuite.ECDHE_RSA_WITH_AES_128_CBC_SHA256;

Or if you are comfortable with using SHA-1, you can try this:

client.Settings.SslAllowedSuites =
    TlsCipherSuite.ECDHE_RSA_WITH_AES_256_CBC_SHA |
    TlsCipherSuite.ECDHE_RSA_WITH_AES_128_CBC_SHA;

If some setting is not working (you will get "server has closed the connection" exception) it means that the server does not support any of the allowed cipher suites.

Comments

Thank you! I did some tests with different cipher suites:

Using CBC with SHA1 ist five times faster than CGM with SHA256.
I cannot test CBC with SHA256 as recommended, because it is not supported by Google Drive.
There is no significant difference using ECDSA or RSA.
There is no significant difference using ECDHE or not.

The Windows-integrated HTTPS WebRequest (using TLS 1.0, RSA, AES with 128-bit key in CBC mode, SHA1) is two times faster than Rebex HTTPS (using TLS 1.2, RSA, AES with 128-bit key in CBC mode, SHA1). Is this the expected behaviour?

---

The Rebex implementation can be two times slower for these reasons:

1. Rebex is completely written in manged .NET language - system is written in device native language.
2. TLS 1.2 has more demanding computation than TLS 1.0.
3. The speed also depends how the client and server settings fits to each other (e.g. block sizes, buffer sizes, etc.)

I would like to note, that it can be also caused by insufficient measure. Did you measure the performance on operation taking at least 30 seconds? If you for example measured that System finished request in 2 second, but Rebex in 4 seconds, it is insufficient measure for transfer speed diagnosis. This can be caused by slower initialization of Rebex classes.

If you want to compare efficiency of Rebex and System, please measure Rebex in TLS 1.0 as well. To use TLS 1.0, please use this setting:

    client.Settings.SslAllowedVersions = TlsVersion.TLS10;

---

I testet downloading of a 4 MB file from Google Drive using “TLS 1.0, RSA, AES with 128-bit key in CBC mode, SHA1”.

With Rebex HTTPS the process took around 60 seconds.
With Windows-integrated HTTPS the process took around 30 seconds.

The difference between “TLS 1.0, RSA, AES with 128-bit key in CBC mode, SHA1” and “TLS 1.2, RSA, AES with 128-bit key in CBC mode, SHA1” in Rebex HTTPS was very small.

 I will do further comparisons with ECDSA and ECDHE.

---

ECDSA and ECDHE will affect only time spend for TLS negotiation. It doesn't affect transfer speed.

Can you please send Debug log to support@rebex.net for analysis, so we can see timings of TLS negotiation and transfer. Maybe, we spot something unusual.

Debug log can be created like this:

    client.LogWriter = new Rebex.FileLogWriter("/http.log", Rebex.LogLevel.Debug);

Answer 2

You Rebex guys did a great job with the new 2019-03-28 Version 2019 R1. From the Release notes:

Improved performance of AES/GCM ciphers in TLS and SSH protocols on .NET Compact Framework and non-Windows platforms.

On our devices, the new version is 8 to 9 times faster than the last one (2018 R4), downloading a 4 MB file using TLS 1.2, RSA with ephemeral Elliptic Curve Diffie-Hellman, AES with 128-bit key in GCM mode, AEAD.

It is even 10 to 15 percent faster than the Windows-integrated HTTPS library using the unsecure TLS 1.0, RSA, AES with 128-bit key in CBC mode, SHA1.

Thank you very much!

Comments

Thank you for your appreciation. We do our best.