Faster and more secure TLS
Summary
On Telegram, it was discussed that KDE Connect is using a lot of CPU while sending/receiving files. I believe that this overhead comes from encryption, mostly outdated TLS ciphers.
I enabled and prioritized ChaCha20 for better performance. However, I didn't notice much of a difference before and after on my machines (the original problem didn't affect me either). I created this MR in hopes that it would improve performance for others.
Misc
I also disabled TLS 1.1 and below as they are vulnerable and deprecated. To avoid 0-RTT and minApi problems, I didn't enable TLS 1.3. This means that TLS 1.2 is the only version enabled now (unfortunately, I had to raise the minimum Android version to 4.4.4 for this).
I removed the ECDSA ciphers that were doing nothing (we only have an RSA certificate).
I wanted to remove TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
as it was outdated, but did not because of backwards compatibility for LTS desktop versions.
Benchmarks
These are benchmarks of this patch. I doubt this will show much, since I've already said that this patch doesn't make much of a difference for me. See Telegram for the screenshots from the user who is affected by this problem.
Android -> KDE, Before
Android -> KDE, After
KDE -> Android, Before
KDE -> Android, After
Test Plan
All of the following:
- At least one user must notice a significant performance improvement when sending/receiving files
- It must be possible to connect to the same peers as before this patch
- There shall be no visual or behavioural changes