Reviving Syncthing-Lite: Fix TLS v1.3 compatibility

Hi,

I’ve tried to compile the app and see what the issue is. Indeed, as mentioned in Syncthing lite no longer works.... it’s the TLSV1_ALERT_PROTOCOL_VERSION error.

I’ll see if that can be bumped to TLSv1.3 somehow. But my first attempt to compile on modern Android Studio failed for hours, not being able to fix all issues (hundreds of errors). I’ve now managed to get a working APK on Android studio dated back to Dec’2018.

Another thing that’s making me feel uncomfortable is, I’ve switched in a repo for the now officially unavailable ANKO dependency that still hosts it.

maven { url “https://artifactory.appodeal.com/appodeal-public/” }

Maybe a coincidential sighting, but after my first build where all those modules associated with it were loaded into the Android java buildEnv by gradle, I’ve noticed this running process on my build machine:

C:\WINDOWS\explorer.exe /factory,{75dff2b7-6936-4c06-a8bb-676a7b00b24b} -Embedding

If you put the string into Google, there are warnings that this may be an exploit indicator, as Explorer.exe is running below the “svchost.exe” process. Oh my :frowning: .

If someone is reading this and likes to help me migrating the kotlin project and dependencies to a recent Android Studio build, we could work together. Please contact me. I’ve already re-written some classes to build using currently supported dependencies, like AppIntro (continued in a fork on github) and sf4j.

As well if anyone has a hint for me, how that “old java 1.8 compiled thingy” using gradle 4.6 could get TLS v1.3 activated.

failed to connect to DeviceAddress(deviceId=DeviceId(deviceId=RF2FVSV), instanceId=null, address=relay://services.ff3l.net:22067, producer=UNKNOWN, score=2108, lastModified=Tue Jul 01 10:23:34 GMT 2025)
javax.net.ssl.SSLHandshakeException: Read error: ssl=0x76a898c39858: Failure in SSL library, usually a protocol error
error:1000042e:SSL routines:OPENSSL_internal:TLSV1_ALERT_PROTOCOL_VERSION (external/boringssl/src/ssl/tls_record.cc:592 0x76aa28cb8c60:0x00000003)
at com.android.org.conscrypt.SSLUtils.toSSLHandshakeException(SSLUtils.java:356)
at com.android.org.conscrypt.ConscryptEngine.convertException(ConscryptEngine.java:1127)
at com.android.org.conscrypt.ConscryptEngine.unwrap(ConscryptEngine.java:912)
at com.android.org.conscrypt.ConscryptEngine.unwrap(ConscryptEngine.java:740)
at com.android.org.conscrypt.ConscryptEngine.unwrap(ConscryptEngine.java:705)
at com.android.org.conscrypt.ConscryptEngineSocket$SSLInputStream.processDataFromSocket(ConscryptEngineSocket.java:896)
at com.android.org.conscrypt.ConscryptEngineSocket$SSLInputStream.-$$Nest$mprocessDataFromSocket(Unknown Source:0)
at com.android.org.conscrypt.ConscryptEngineSocket.doHandshake(ConscryptEngineSocket.java:236)
at com.android.org.conscrypt.ConscryptEngineSocket.startHandshake(ConscryptEngineSocket.java:218)
at com.android.org.conscrypt.ConscryptEngineSocket.waitForHandshake(ConscryptEngineSocket.java:609)
at com.android.org.conscrypt.ConscryptEngineSocket.-$$Nest$mwaitForHandshake(Unknown Source:0)
at com.android.org.conscrypt.ConscryptEngineSocket$SSLInputStream.read(ConscryptEngineSocket.java:833)
at java.io.DataInputStream.readFully(DataInputStream.java:203)
at java.io.DataInputStream.readInt(DataInputStream.java:394)
at net.syncthing.java.bep.connectionactor.HelloMessageHandler.receiveHelloMessage(HelloMessageHandler.kt:63)
at net.syncthing.java.bep.connectionactor.ConnectionActor$createInstance$1$invokeSuspend$$inlined$use$lambda$1$2.invokeSuspend(Instance.kt:50)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:32)
at kotlinx.coroutines.DispatchedTask$DefaultImpls.run(Dispatched.kt:235)
at kotlinx.coroutines.DispatchedContinuation.run(Dispatched.kt:81)
at kotlinx.coroutines.scheduling.Task.run(Tasks.kt:94)
at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:586)
at kotlinx.coroutines.scheduling.CoroutineScheduler.access$runSafely(CoroutineScheduler.kt:60)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:732)
Caused by: javax.net.ssl.SSLProtocolException: Read error: ssl=0x76a898c39858: Failure in SSL library, usually a protocol error
error:1000042e:SSL routines:OPENSSL_internal:TLSV1_ALERT_PROTOCOL_VERSION (external/boringssl/src/ssl/tls_record.cc:592 0x76aa28cb8c60:0x00000003)
at com.android.org.conscrypt.NativeCrypto.ENGINE_SSL_read_direct(Native Method)
at com.android.org.conscrypt.NativeSsl.readDirectByteBuffer(NativeSsl.java:570)
at com.android.org.conscrypt.ConscryptEngine.readPlaintextDataDirect(ConscryptEngine.java:1088)
at com.android.org.conscrypt.ConscryptEngine.readPlaintextData(ConscryptEngine.java:1072)
at com.android.org.conscrypt.ConscryptEngine.unwrap(ConscryptEngine.java:869)
... 20 more
2 Likes

I don’t really remember but I think I used 1.27.12 just fine a year ago. I used it on a daily basis so the syncthing last seen date was 2025-04-13. I really hope that is the syncthing lite version and not the full fat syncthing I installed on it later. All my “servers” are really just windows 10 machines I VNC to. They were running auto updating versions installed using the Syncthing trayzor exe.

Did you fix it that quickly? You said you could connect just fine.

1 Like

By no means am I a programmer so I couldn’t help you :sweat_smile: But thank you for spearheading the diagnosis. Your efforts are greatly appreciated for looking into it though. It would be cool if syncthing lite was re-born.

Not seeing anything obvious in the 1.18.0-to-1.18.1 diffs that I think should matter, sorry. You can run with STTRACE=protocol on the Syncthing side as well to get a bit more info on what it thinks it sends and receives.

1 Like

According to https://docs.syncthing.net/users/releases, Go version changed from v1.16.5 to v1.16.6. Not sure if that is the actual culprit though.

1 Like

Looks like it

1 Like

Oh you absolutely should, on both accounts :grin:

3 Likes

It works quite well :+1: File transfers get stuck sometimes but smaller files sync instantly in most cases.

2 Likes

Wow, Bravo! Thank you for putting this much time into a fix, I really appreciate it. My whole storage backbone relies on syncthing lite.

Really not Syncthing-spoon? :smirking_face:

Congratulations and thank you for your work on this.

1 Like

There’s no ed25519 (0x0807) in the “Signature Hash Algorithms” on the st-lite side :wink:

2 Likes

Most likely feat: use Ed25519 keys for sync connections by calmh · Pull Request #10162 · syncthing/syncthing · GitHub

2 Likes

Yeah there aren’t many TLS implementations that can do Ed25519 certs currently (not allowed by BRs, reason for adoption now is rather low). OpenSSL can do it, golang as well, obviously. Not sure about the BoringSSL used by Android. NSS recently added support as well, but rather bare-bones (e.g. Firefox still can’t do it).

1 Like

conscrypt is basically a java bridge library to BoringSSL, so the first question would be if BoringSSL supports it. I had a look and yes, they implemented this 8 years ago actually: Support Ed25519 in TLS. · google/boringssl@6952211 · GitHub. But I know from experience that the Android devs love to customize the BoringSSL build and runtime (which the folks at BoringSSL seem to hate), so maybe they’re doing something to turn it off.

2 Likes

Maybe you can use bouncycastle?

2 Likes

I think BC should be able to handle mTLS

Mixing Ed25519 and the older ECDSA/SHA256 combo works. Haven’t tried mixing RSA and Ed25519, but that sounds like it would work too.

1 Like

I’ve tried it now (with RSA-3072), and it does work.

1 Like

With a standard Syncthing release. Just deleted the cert.pem and key.pem and ran openssl req -x509 -newkey rsa:3072 -keyout key.pem -out cert.pem -sha256 -days 7300 -nodes -subj "/O=Syncthing/CN=syncthing" (forked from an answer on Stack Overflow) in the Syncthing home directory, and tested that it connected with instances with an Ed25519 key alright.