Bug 462418 - Android app cannot connect, TLS 1.0 suspected
Summary: Android app cannot connect, TLS 1.0 suspected
Status: RESOLVED FIXED
Alias: None
Product: kdeconnect
Classification: Applications
Component: android-application (other bugs)
Version First Reported In: 22.11.80
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Albert Vaca Cintora
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-11-30 01:45 UTC by Aaron Williams
Modified: 2023-04-10 22:26 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:

Attachments
Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description Aaron Williams 2022-11-30 01:45:19 UTC 
SUMMARY
The Android app for my phone, a Google Pixel 6 Pro, cannot connect to my desktop running OpenSUSE 15.4. Doing a packet trace with wireshark I am seeing some funny behavior with TCP, but the problem appears to be due to TLS. The Android client is attempting to use TLS 1.0 which I believe is no longer supported by my desktop due to being insecure and outdated. The android client sends a TLS hello message and the desktop daemon never responds. I believe that this is due to the outdated TLS being used by the Android client. It should be upgraded to use at least TLS Version 1.2.


STEPS TO REPRODUCE
1.  Start up KDE Connect on Linux desktop
2.  Install KDE Connect on Android phone
3.  Attempt to pair
4. Add desktop IP address to phone app
5. Attempt to pair again

OBSERVED RESULT
When attempting to pair using either the phone or desktop app, no devices appear. A TCP packet trace indicates that there is no response after the phone sends a TLS 1.0 hello message.

EXPECTED RESULT
I expect it to work.

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 5.100.0
Qt Version: 5.15.7

ADDITIONAL INFORMATION
Comment 1 Aaron Williams 2022-11-30 01:58:23 UTC 
I might also add that TLS 1.0 and 1.1 have been deprecated and are no longer supported in Android. I do not know how or why TLS 1.0 is being used.

I believe I found the location of the bug. In the Android version in src/org/kdeconnect/Helpers/SecurityHelpers/SsslHelper.java around line 209 it should say "TLSv1.2" instead of "TLSv1".

According to https://developer.android.com/training/articles/security-ssl it looks like recent versions of Android default to TLS 1.3.
Comment 2 Aaron Williams 2022-11-30 14:25:30 UTC 
I modified the Android app to use TLS 1.2. I am seeing the following:

2022-11-30 06:07:57.589 12619-13216/org.kde.kdeconnect_tp E/KDE/LanLinkProvider: Handshake failed with Flash
    java.net.SocketTimeoutException: Read timed out
        at java.net.SocketInputStream.socketRead0(Native Method)
        at java.net.SocketInputStream.socketRead(SocketInputStream.java:118)
        at java.net.SocketInputStream.read(SocketInputStream.java:173)
        at java.net.SocketInputStream.read(SocketInputStream.java:143)
        at com.android.org.conscrypt.ConscryptEngineSocket$SSLInputStream.readFromSocket(ConscryptEngineSocket.java:945)
        at com.android.org.conscrypt.ConscryptEngineSocket$SSLInputStream.processDataFromSocket(ConscryptEngineSocket.java:909)
        at com.android.org.conscrypt.ConscryptEngineSocket$SSLInputStream.-$$Nest$mprocessDataFromSocket(Unknown Source:0)
        at com.android.org.conscrypt.ConscryptEngineSocket.doHandshake(ConscryptEngineSocket.java:241)
        at com.android.org.conscrypt.ConscryptEngineSocket.startHandshake(ConscryptEngineSocket.java:220)
        at org.kde.kdeconnect.Backends.LanBackend.LanLinkProvider.lambda$identityPacketReceived$3(LanLinkProvider.java:231)
        at org.kde.kdeconnect.Backends.LanBackend.LanLinkProvider.$r8$lambda$Jao-pvoLRBDL_CAjSz-x8HAC9X8(Unknown Source:0)
        at org.kde.kdeconnect.Backends.LanBackend.LanLinkProvider$$ExternalSyntheticLambda5.run(Unknown Source:6)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1137)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637)
        at java.lang.Thread.run(Thread.java:1012)
2022-11-30 06:08:07.606 12619-13204/org.kde.kdeconnect_tp E/KDE/LanLinkProvider: Handshake failed with Flash
    java.net.SocketTimeoutException: Read timed out
        at java.net.SocketInputStream.socketRead0(Native Method)
        at java.net.SocketInputStream.socketRead(SocketInputStream.java:118)
        at java.net.SocketInputStream.read(SocketInputStream.java:173)
        at java.net.SocketInputStream.read(SocketInputStream.java:143)
        at com.android.org.conscrypt.ConscryptEngineSocket$SSLInputStream.readFromSocket(ConscryptEngineSocket.java:945)
        at com.android.org.conscrypt.ConscryptEngineSocket$SSLInputStream.processDataFromSocket(ConscryptEngineSocket.java:909)
        at com.android.org.conscrypt.ConscryptEngineSocket$SSLInputStream.-$$Nest$mprocessDataFromSocket(Unknown Source:0)
        at com.android.org.conscrypt.ConscryptEngineSocket.doHandshake(ConscryptEngineSocket.java:241)
        at com.android.org.conscrypt.ConscryptEngineSocket.startHandshake(ConscryptEngineSocket.java:220)
        at org.kde.kdeconnect.Backends.LanBackend.LanLinkProvider.lambda$identityPacketReceived$3(LanLinkProvider.java:231)
        at org.kde.kdeconnect.Backends.LanBackend.LanLinkProvider.$r8$lambda$Jao-pvoLRBDL_CAjSz-x8HAC9X8(Unknown Source:0)
        at org.kde.kdeconnect.Backends.LanBackend.LanLinkProvider$$ExternalSyntheticLambda5.run(Unknown Source:6)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1137)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637)
        at java.lang.Thread.run(Thread.java:1012)
2022-11-30 06:08:17.624 12619-13205/org.kde.kdeconnect_tp E/KDE/LanLinkProvider: Handshake failed with Flash
    java.net.SocketTimeoutException: Read timed out
        at java.net.SocketInputStream.socketRead0(Native Method)
        at java.net.SocketInputStream.socketRead(SocketInputStream.java:118)
        at java.net.SocketInputStream.read(SocketInputStream.java:173)
        at java.net.SocketInputStream.read(SocketInputStream.java:143)
        at com.android.org.conscrypt.ConscryptEngineSocket$SSLInputStream.readFromSocket(ConscryptEngineSocket.java:945)
        at com.android.org.conscrypt.ConscryptEngineSocket$SSLInputStream.processDataFromSocket(ConscryptEngineSocket.java:909)
        at com.android.org.conscrypt.ConscryptEngineSocket$SSLInputStream.-$$Nest$mprocessDataFromSocket(Unknown Source:0)
        at com.android.org.conscrypt.ConscryptEngineSocket.doHandshake(ConscryptEngineSocket.java:241)
        at com.android.org.conscrypt.ConscryptEngineSocket.startHandshake(ConscryptEngineSocket.java:220)
        at org.kde.kdeconnect.Backends.LanBackend.LanLinkProvider.lambda$identityPacketReceived$3(LanLinkProvider.java:231)
        at org.kde.kdeconnect.Backends.LanBackend.LanLinkProvider.$r8$lambda$Jao-pvoLRBDL_CAjSz-x8HAC9X8(Unknown Source:0)
        at org.kde.kdeconnect.Backends.LanBackend.LanLinkProvider$$ExternalSyntheticLambda5.run(Unknown Source:6)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1137)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637)
        at java.lang.Thread.run(Thread.java:1012)


Note that on my desktop computer I have multiple IP addresses. When I click Refresh in the settings it is only sending output on one subnet, which is not the subnet my phone is on. If I select Refresh on my phone it gets as far as sending a TLS hello but the desktop app  does not respond and times out.

Also, broadcasts are only going out on the first interface for the desktop client. I am wondering if the same workaround is needed in lanlinkprovider.cpp as for FreeBSD and Windows.

kdeconnect.core: TCP connection done (i'm the existing device)
kdeconnect.core: Starting server ssl (I'm the client TCP socket)
kdeconnect.core: TCP connection done (i'm the existing device)
kdeconnect.core: Starting server ssl (I'm the client TCP socket)

I am wondering if it is a socket option where it is stuck waiting for more data.
Comment 3 Albert Vaca Cintora 2023-04-10 22:26:01 UTC 
KDE Connect can now negotiate the TLS version and cipher suite that's best from the ones supported by the system. This should solve this kind of issues.