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.
Seems like it’s possible to use Volley with okhttp by providing a custom HttpStack:
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.
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.)
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?
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.
It’s not on the fork’s changelog as it was already solved in december '18.
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?!
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.
Soo, it’s been a few months and I would like to come back to @calmh’s proposal of changing the default elliptic curve for the certificate(s).
I have been thinking back and forth with this and I would like to share my final thoughts on this here.
First a clarification: I previously stated in March that Syncthing generates a ECDSA certificate with P-521: This is incorrect. Syncthing generates the cert with P-384, but prefers P-521 for the Diffie-Hellman. We need to differentiate between curves used in the cert and curves supported in the ECDHE handshake.
Summing up some things about elliptic curves:
Curve P-521 is dead. Really dead. It has practically never been used and quite a few implementations, including Chrome removed supported for P-521 in 2015. The NSA never even included it in their “Suite B” paper, which started some discussions about the topic in 2013.
Syncthing certificate(s) use P-384, so let’s talk about P-384: This curve is more supported, but is still not the most ideal curve:
P-384 (and P-256) are both NIST curves engineered by the NSA. There have and will probably always be discussions whether the NSA has backdoors in these curves. I don’t know which position to support in this regard.
The website SaveCurves (authors: Daniel J. Bernstein and Tanja Lange) both list possible issues with the NIST curves P-384 and P-256 (both fail the SafeCurves requirements).
On the other hand, curves like P-384 and P-256 are not considered generally unsafe (especially P-256 is the most common curve):
Mozilla has recently updated their recommendations for server side TLS. Regarding elliptic curves there haven’t been much changes: They still recommend P-256 for certificates because it’s the most supported. They say however that they don’t prefer P-384 (which syncthing uses) over P-256, because of “negligable improvements to security” (and probably hard- and software support).
The major change on Mozilla’s recommendations was however that they started to include (and prefer) curve Curve25519 in the ECDHE list: This curve passes the SafeCurves requirements from the website above, which the NIST curves do not. The major issue with this curve is that it is too new (standardized in 2016 in RFC 7748) and support is only there in modern enviroments.
Curve25519 is used in GPG, Signal, WhatsApp, Tor, I2P and iOS (and others).Syncthing currently prefers the following curves in the ECDHE handshake (in order): P-521, P-384, P-256.
The curves 256 and 384 should already cover 99% (or more) of ECC implementations. I think it would only be reasonable to replace P-521 with Curve25519, because P-521 is dead and the other curve could even offer more security (even though the bitlength is smaller).
For the certificate the decision is harder:
Currently, P-384 is used. This has pretty much the same security as P-256, but P-256 definetly has a greater support. The Android issue which this post was originally about showed that Android 7.0 only supported P-256. Changing syncthing’s default curve in certificates to this would solve this issue (mostly) and would also follow best practices found in the world wide web (almost every ECDSA cert found in the wild is P-256, some are Curve25519).
Switching from 384 to 256 sounds therefore reasonable, but could result in a security loss - altough experts say this should be negligible. If security is top priority, Curve25519 should be preferred. But this doesn’t solve the compatibility issues (and might even worse them).
The third option is the easiest one: Since there are no real security vulnerabilities, just staying with P-384 is also a solution.
Edit 2: I haven’t looked at the elliptic curve support in Go, so I don’t what’s currently possible in Go and what not. I just assumed Go behaves similar to a modern web browser - those support all curves named (except for our dead friend P-521).
Edit: Sorry, accidentally posted this while I was still writing.
I am very sorry for reviving the old topic, but I have a related question, and I though it might be acceptable to ask is it here.
On Android 4.4, I have this spammed in the logs:
2020-04-25 03:49:58 Exiting backoff state.
2020-04-25 03:49:58 Relay listener (dynamic+https://relays.syncthing.net/endpoint) starting
2020-04-25 03:49:58 Listen (BEP/relay): Get https://relays.syncthing.net/endpoint: dial tcp: lookup relays.syncthing.net on [::1]:53: read udp [::1]:57529->[::1]:53: read: connection refused
2020-04-25 03:49:58 Relay listener (dynamic+https://relays.syncthing.net/endpoint) shutting down
2020-04-25 03:49:58 c.S.listenerSupervisor: Failed service 'dynamic+https://relays.syncthing.net/endpoint' (1.000000 failures of 2.000000), restarting: true, error: "{dynamic+https://relays.syncthing.net/endpoint dynamic+https://relays.syncthing.net/endpoint} returned unexpectedly", stacktrace: [unknown stack trace]
2020-04-25 03:49:58 Relay listener (dynamic+https://relays.syncthing.net/endpoint) starting
2020-04-25 03:49:58 Listen (BEP/relay): Get https://relays.syncthing.net/endpoint: dial tcp: lookup relays.syncthing.net on [::1]:53: read udp [::1]:47089->[::1]:53: read: connection refused
2020-04-25 03:49:58 Relay listener (dynamic+https://relays.syncthing.net/endpoint) shutting down
2020-04-25 03:49:58 c.S.listenerSupervisor: Failed service 'dynamic+https://relays.syncthing.net/endpoint' (1.999879 failures of 2.000000), restarting: true, error: "{dynamic+https://relays.syncthing.net/endpoint dynamic+https://relays.syncthing.net/endpoint} returned unexpectedly", stacktrace: [unknown stack trace]
2020-04-25 03:49:58 Relay listener (dynamic+https://relays.syncthing.net/endpoint) starting
2020-04-25 03:49:58 Listen (BEP/relay): Get https://relays.syncthing.net/endpoint: dial tcp: lookup relays.syncthing.net on [::1]:53: read udp [::1]:44681->[::1]:53: read: connection refused
2020-04-25 03:49:58 Relay listener (dynamic+https://relays.syncthing.net/endpoint) shutting down
2020-04-25 03:49:58 Entering the backoff state.
2020-04-25 03:49:58 c.S.listenerSupervisor: Failed service 'dynamic+https://relays.syncthing.net/endpoint' (2.999652 failures of 2.000000), restarting: false, error: "{dynamic+https://relays.syncthing.net/endpoint dynamic+https://relays.syncthing.net/endpoint} returned unexpectedly", stacktrace: [unknown stack trace]
and also:
I am guessing that the problem is the lack of support for TLS 1.2 in the old version of Android. My question then is - should I disable both relays and global discovery? They seem not to be working anyway, and I also hope to reduce the log spam this way.
It seems your dns servers don’t return an address for those hostnames. Could be an issue with dns server, could be your government blocking stuff. Nothing todo with tls
Hmm, that is kind of unexpected. I imagined that TLS would be the culprit, as I have no such errors on my Windows devices, and they use exactly the same wireless Internet connection.
The government here does indeed censor and block and lot of “stuff”, so this is a very good point, but I would expect to have these errors on all my devices then.
I will re-check my DNS settings, and see if there is any difference. If not, then I will create a new topic about the issue.
The syncthing app is written in Go which ships it’s own TLS stack, that’s mostly independent from the OS. The android wrapper is what can be problematic, but afaik the wrapper isn’t involved in discovery 'n stuff.
Indeed the error message suggests DNS is not working correctly.
