Allow ChaCha20 type ciphers to avoid crippling servers without AES hardware acceleration

[fakuivan]

The chacha20 family of ciphers are not considered insecure, and are an order of magnitude more efficient on servers that do not provide hardware acceleration for AES encryption (like all the raspberry pi models). Wireguard uses this cipher, it has been thoroughly analyzed and considered to be secure, so I see no reason why ChaCha20 should not be added to this list:

https://github.com/haiwen/seadroid/blob/da6bc0cc96a2fd081439bf2ad32565b422160b6c/app/src/main/java/com/seafile/seadroid2/ssl/SSLSeafileSocketFactory.java#L112-L148

This could be a massive performance buff for Raspberry Pi 4s running seafile with https on a gigabit lan.

Link to this topic in the forums: https://forum.seafile.com/t/use-chacha-encryption-algorithms-instead-of-aes-for-https/14201/5

[fakuivan]

I'll suggest this source for filtering out insecure cipher suites https://wiki.mozilla.org/Security/Server_Side_TLS, It includes ChaCha20, even for very stringent security requirements.

[fakuivan]

Unfortunately this was not enough to fix the issue, seadroid seems to not be able to parse the certificate or get any of its parameters thus it prompts me to authorize this "unknown" certificate. The default android certificate store is able to handle connections using these ciphers, as google chrome and Firefox do not have any problems connecting to the site, so we should check on the custom logic that has been put into seadroid to handle certificate exceptions for things like self signed certs and make sure those are also compatible.

Here's a screenshot (Spanish) if what this error looks like:

[AlbertWeichselbraun]

Adding TLS 1.3 support to the app should fix this. There is even a corresponding pull request available (#913), that would fix the problem once it gets merged.