Android and TLS1.2


(Simon) #21

Thanks again for the confirmation. I guess that confirms the “solution” is to disable TLS on 4.x and 7.0.


(Bt90) #22

A unix socket isn’t an option? Seems like syncthing already supports it.


(Simon) #23

No idea, after all it’s android not linux (meaning there will be gotchas and problems all the way). In any case it’s definitely nothing to be consider for 0.10.18.


(Bt90) #24

In any case it’s definitely nothing to be consider for 0.10.18.

For sure but it might be worth to check it for future releases. The android library seems to have support for them and it looks like connections to sockets in the filesystem namespace are possible. (read: non-public socket which can be guarded by filesystem permissions).

A first test would be to start the daemon with unix socket enabled pointing to a location in the private storage of the app.


(Simon) #25

Can you test whether https://github.com/syncthing/syncthing-android/pull/1281 works on 7.0? And/or https is still working on other android versions. The apk can be downloaded here: https://build.syncthing.net/repository/download/SyncthingAndroid_Build/34898:id/apk/debug/app-debug.apk


#26

I already commented yesterday on the github issue, just confirming it here:

The proposed pull request works as intended. However, I think this solution should rather be a temporary workaround instead of a permanent one. We’ve already seen a few suggestions on this thread proposing possible solutions.

If anyone has ideas on how the current situation can be improved, I’m open to hear them. I have some Java experience and would write some code if needed.


(Bt90) #27

Seems like it’s possible to use Volley with okhttp by providing a custom HttpStack:


(Catfriend1) #28

Hi, I’m currently working to find a more a accurate solution to the Android app’s TLS problem. To shed some light, I’ve made a comparison between what an android virtual device (emulator) 7.0 supports less than one with 5.1.

Android 7.0

Summary

SSL_RSA_WITH_3DES_EDE_CBC_SHA SSL_RSA_WITH_RC4_128_MD5 SSL_RSA_WITH_RC4_128_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 TLS_ECDHE_ECDSA_WITH_RC4_128_SHA TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 TLS_ECDHE_RSA_WITH_RC4_128_SHA TLS_EMPTY_RENEGOTIATION_INFO_SCSV TLS_FALLBACK_SCSV TLS_PSK_WITH_AES_128_CBC_SHA TLS_PSK_WITH_AES_256_CBC_SHA TLS_PSK_WITH_RC4_128_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384

Android 5.1

Summary

SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 SSL_DH_anon_WITH_3DES_EDE_CBC_SHA SSL_DH_anon_WITH_DES_CBC_SHA SSL_DH_anon_WITH_RC4_128_MD5 SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA SSL_DHE_DSS_WITH_DES_CBC_SHA SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA SSL_DHE_RSA_WITH_DES_CBC_SHA SSL_RSA_EXPORT_WITH_DES40_CBC_SHA SSL_RSA_EXPORT_WITH_RC4_40_MD5 SSL_RSA_WITH_3DES_EDE_CBC_SHA SSL_RSA_WITH_DES_CBC_SHA SSL_RSA_WITH_NULL_MD5 SSL_RSA_WITH_NULL_SHA SSL_RSA_WITH_RC4_128_MD5 SSL_RSA_WITH_RC4_128_SHA TLS_DH_anon_WITH_AES_128_CBC_SHA TLS_DH_anon_WITH_AES_128_CBC_SHA256 TLS_DH_anon_WITH_AES_128_GCM_SHA256 TLS_DH_anon_WITH_AES_256_CBC_SHA TLS_DH_anon_WITH_AES_256_CBC_SHA256 TLS_DH_anon_WITH_AES_256_GCM_SHA384 TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA TLS_ECDH_anon_WITH_AES_128_CBC_SHA TLS_ECDH_anon_WITH_AES_256_CBC_SHA TLS_ECDH_anon_WITH_NULL_SHA TLS_ECDH_anon_WITH_RC4_128_SHA TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_ECDSA_WITH_NULL_SHA TLS_ECDH_ECDSA_WITH_RC4_128_SHA TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDH_RSA_WITH_AES_128_CBC_SHA TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_RSA_WITH_NULL_SHA TLS_ECDH_RSA_WITH_RC4_128_SHA TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_NULL_SHA TLS_ECDHE_ECDSA_WITH_RC4_128_SHA TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_NULL_SHA TLS_ECDHE_RSA_WITH_RC4_128_SHA TLS_EMPTY_RENEGOTIATION_INFO_SCSV TLS_FALLBACK_SCSV TLS_PSK_WITH_3DES_EDE_CBC_SHA TLS_PSK_WITH_AES_128_CBC_SHA TLS_PSK_WITH_AES_256_CBC_SHA TLS_PSK_WITH_RC4_128_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_NULL_SHA256

Ciphers, Android 7.0 doesn’t support but 5.1 does support:

Summary

SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 SSL_DH_anon_WITH_3DES_EDE_CBC_SHA SSL_DH_anon_WITH_DES_CBC_SHA SSL_DH_anon_WITH_RC4_128_MD5 SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA SSL_DHE_DSS_WITH_DES_CBC_SHA SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA SSL_DHE_RSA_WITH_DES_CBC_SHA SSL_RSA_EXPORT_WITH_DES40_CBC_SHA SSL_RSA_EXPORT_WITH_RC4_40_MD5 SSL_RSA_WITH_DES_CBC_SHA SSL_RSA_WITH_NULL_MD5 SSL_RSA_WITH_NULL_SHA TLS_DH_anon_WITH_AES_128_CBC_SHA TLS_DH_anon_WITH_AES_128_CBC_SHA256 TLS_DH_anon_WITH_AES_128_GCM_SHA256 TLS_DH_anon_WITH_AES_256_CBC_SHA TLS_DH_anon_WITH_AES_256_CBC_SHA256 TLS_DH_anon_WITH_AES_256_GCM_SHA384 TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA TLS_ECDH_anon_WITH_AES_128_CBC_SHA TLS_ECDH_anon_WITH_AES_256_CBC_SHA TLS_ECDH_anon_WITH_NULL_SHA TLS_ECDH_anon_WITH_RC4_128_SHA TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_ECDSA_WITH_NULL_SHA TLS_ECDH_ECDSA_WITH_RC4_128_SHA TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDH_RSA_WITH_AES_128_CBC_SHA TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_RSA_WITH_NULL_SHA TLS_ECDH_RSA_WITH_RC4_128_SHA TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_ECDSA_WITH_NULL_SHA TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_RSA_WITH_NULL_SHA TLS_PSK_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_NULL_SHA256

So my question is: Which one are mandatory the app should look for on the Android OS that they are supported to guarantee a successful handshake with Syncthing Web UI and REST API?


(Catfriend1) #29

I’ve optimized the test code further to only analyze differences in regard to TLSv1.2 between Android 5.1 and Android 7.0. Those are missing on 7.0:

So looking at the posts above, this yellow curves seem to the be “the problem for Syncthing” on Android 7.0:

image

Okay, still something seems weird. SSLEngine on Android 7.0 reports those also to be available:

image

How to detect the missing curves? Any ideas @Nummer378 @Bt90 ?


(Catfriend1) #30

Sorry, calling getSupportedCiphers() leads to nowhere. Just compared what SSLEngine on Android 6.0 reports and compared to 7.0. Conclusion: Android 7.0 reports to support everything 6.0 supports plus those ciphers: image


#31

The problem that we’ve discovered on 7.0 is not that the specific ECDSA ciphers are not available, but that they’re partly broken on 7.0:

These links https://community.letsencrypt.org/t/warning-android-7-0-clients-not-browsers-can-only-use-curve-prime256v1/23212 , https://issuetracker.google.com/issues/37122132 - I’ve posted them previously - are stating that in the default TLS implementation of 7.0 every elliptic curve except prime256 is broken.

This affects both ECDHE key agreements and ECDSA signing - both can only be performed with P-256, but syncthing requires P-521 - this curve is not working in the buggy implementation and thus any ECDHE or ECDSA handshake will fail, even though the cipher is supported in theory.

This however is an issue, because: New installs of syncthing generate a ECC certificate with P-521. That means we can only use a suite which uses ECDSA signing with P-521 (the handshake is signed with the key from the certificate). Since the TLS client however is not capable of using this curve, it can’t properly verify the signature, nor generate a signature on it’s own.

Therefore there is simply no cipher which syncthing allows (on new installs) that works in 7.0.

I’ve played around a little with unix sockets, and I’ve come to the conclusion that unix sockets are not an easy solution - there’s no native URL handler for unix sockets, it will likely require pretty big code changes in the URL stuff. Plus I’ve no idea how to get unix sockets working in the webview, so it’s definetly not an easy solution either.


(Jakob Borg) #32

While all this is shitty, it’s also an argument for changing the default to P256 for a negligible, currently unknown (?) loss of crypto strength. We’re not so married to another curve that this can’t be changed as I’m not aware of any known weakness with P256 today.

(P256 is also hardware accelerated on a lot of hardware, which the other curves are not. This doesn’t matter for syncthing which only does infrequent handshakes, but it would matter for the discovery servers.)


#33

May I ask what the current status is on this for Syncthing App, Syncthing Lite and Syncthing-Fork?

The current release notes for Syncthing app say “Fallback to http if https with TLS 1.2 is unavailable (#1255)” On the other two apps there is no mention of this issue.

What are the implications of this for android users? If connections are made with http, does this mean that blocks are transferred unencrypted? Does that mean the relay servers can read the content of the blocks? Is it still safe to use relay servers in this situation?


(Simon) #34

This is almost a non-issue. It was an issue that the app didn’t work at all due to missing/faulty tls on android, but disabling tls on the api locally comes with a small risk (the only known scenario to me is you installing an app that specifically targets syncthing to get access to your shared data, which is unlikely to put iy mildly). connections/transfers have nothing to do with that and are always encrypted.


(Catfriend1) #35

It’s not on the fork’s changelog as it was already solved in december '18.


#36

So “fallback to http” only affects local calls to API on the device itself and not any external connections; “local calls to API” being calls to the Event API and REST API, which allow the Syncthing core service to be controlled from the GUI wrapper. All outgoing connections are TLS encrypted, regardless of this issue.

Good to hear that Syncthing-Fork has been fixed.

What about Syncthing-Lite?!


(Evgeny Kuznetsov) #37

Syncthing Lite has a much bigger problem, as it doesn’t work on 7.0 at all (supposedly, due to the same issue). As far as I know, no fix is in coming any time soon, since there’s not much development happening in ST Lite at all.