Ask a Question

TLS 1.3 for Rebex HTTPS Legacy on Windows Mobile devices?

0 votes
by (790 points)

The Rebex HTTPS Legacy library will be “end of life” after 2021-04-13 on the .NET Compact Framework 3.5 according to https://www.rebex.net/kb/legacy-platform-support/

Will we see a version supporting TLS 1.3 before this date?

Devices running Windows Mobile 6.5.3 (or Windows Embedded Handheld) are generally slow and lack AES hardware support, but may be able to do TLS 1.3 with the faster TLS_CHACHA20_POLY1305_SHA256 cipher (compared to TLS_AES_128_GCM_SHA256). This would be quite useful, as AWS and other big content providers added ChaCha20/Poly1305 support recently.

Applies to: Rebex HTTPS, Rebex TLS

1 Answer

0 votes
by (134k points)

Due to small-yet-persistent demand in .NET Compact Framework 3.5, we will continue to provide and maintain .NET CF 3.5 binaries after 2021-04-13 until at least 2022-04-13 as long as your support contract is still active. However, these binaries will no longer be covered by our standard support terms (contact sales@rebex.net to discuss custom support arrangements for end-of-life platforms).

Next year, we plan to add TLS 1.3 support to Rebex HTTPS for .NET Compact Framework 3.9, where our experimental build appears to work without any issues. Unfortunately, the same cannot be said for the .NET CF 3.5 edition, which seems to be pushing a lot of legacy devices over their limits. We plan to publish a new experimental build soon to see how much interest in this there is and how well it works.

However, I am not sure whether our managed Chacha20/Poly1305 implementation would be faster than our AES/GCM on .NET CF, because the AES part is aided by CryptoAPI's native implementation.

by (790 points)
We have various devices from Datalogic and Zebra (former Motorola or Symbol) in production use, differing in age and speed very much. Those are communicating with AWS endpoints, where TLS 1.3 is available using Chacha20/Poly1305 and AES/GCM.

We would be happy to test an experimental build as soon as available, and provide performance data and log files in return.
by (790 points)
We have done a litte performance test here. A slow device is downloading a 3,5 MByte file from Google Drive utilizing Rebex HTTPS Version 2019 R3.5, using different TLS 1.2 ciphers forced by SslAllowedSuites configuration:

Connection secured using cipher: TLS 1.2, RSA with ephemeral ECDH, AES with 128-bit key in GCM mode, AEAD.
Download took 24 seconds

Connection secured using cipher: TLS 1.2, ECDSA with ephemeral ECDH, AES with 128-bit key in GCM mode, AEAD.
Download took 23 seconds

Connection secured using cipher: TLS 1.2, ECDSA with ephemeral ECDH, Chacha20Poly1305 with 256-bit key, AEAD.
Download took 18 seconds

On this device your managed Chacha20/Poly1305 implementation is faster than AES/GCM. Do you think we should compare download speed on more devices?
by (790 points)
edited by
We have repeated the performance test with Rebex HTTPS Version 2019 R3.6 on the same device, getting even better results:

AES with 128-bit key in GCM mode, SHA256: 18 seconds
Chacha20Poly1305 with 256-bit key, SHA256: 14 seconds

On Google Drive, there are some WEAK ciphers still available, just for comparison:
AES with 128-bit key in CBC mode, SHA1: 8 seconds
TripleDES with 168-bit key in CBC mode, SHA1: 6 seconds
by (134k points)
We tried measuring download time of a 100 MB file with Rebex HTTPS 2019 R3.6 on .NET Compact Framework 3.9 and Windows Embedded Compact 2013 running on x86 platform, and AES/GCM is slightly faster than Chacha20/Poly1305 in this environment. The download took 38 seconds for ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, but only 27 seconds with ECDHE_RSA_WITH_AES_128_GCM_SHA256.

So apparently, the platform does make a difference. Based on your results, I guess Chacha20/Poly1305 might be faster on ARM platforms.
...