Unable to connect with FreeRDP3 using /sec:rdp about freerdp

[akallabeth]

@ndonkersloot it does work, it is just insecure.

[ndonkersloot]

@akallabeth
In my case it does not, that's the main reason why I created this issue.
I've created a video file showcasing my issue.
freerdp.webm

I've also added a trace log.
I have this with multiple server, but for this example I only focus on one.
trace.log

[akallabeth]

@ndonkersloot you might want to try with a build from master though, I´ve added additional logging with #9943 that might be helpful

[akallabeth]

@ndonkersloot you can build a flatpak from source, just check out and run:

cd <sourcedir>/packaging/flatpak
./build-bundle.sh

(requires flatpak-builder and flatpak installed)

install the bundle created and run that one. (you have the improved logging from master now, maybe something will tell you what is wrong)

[akallabeth]

I get errors when running that the /dev/dri/card1 can't be found. I think the permission --device=dri needs to be set in the flatpak manifest. Once I do that the error goes away.

will have a look.

[TijZwa]

I have the exact same issue. Can this be fixed?

[akallabeth]

@ndonkersloot

first a word about /sec:rdp: that is always a VERY BAD idea.
I get why you disable NLA (you want the windows logon screen), but there is /sec:TLS that is from that perspective the same as /sec:rdp but with proper TLS)

as for the unable to connect :

• are you only talking about the credential dialog? behavior changed with FreeRDP3 and you always need to provide /u: /p: to not get that dialog. (just use empty values if you don´t want the dialog but not provide any credentials either)

[akallabeth]

ok, checked with current flatpak:

• flatpak run com.freerdp.FreeRDP /v:host /sec:tls /p: /u: works as expected (get the logon screen)
• flatpak run com.freerdp.FreeRDP /v:host /sec:tls works as expected (get the credential dialog, hit accept and you get the logon screen)

[ndonkersloot]

@akallabeth
Adding the parameters /p: /u: does help to prevent the logon screen, thanks!

I don't have control over the remote server that I need to connect to.
So there is no way for me to force the use of /sec:tls even if it is better.
It would be great if /sec:rdp also works like on freerdp2 so I can start using freerdp3.

[akallabeth]

@ndonkersloot which openssl version and are legacy ciphers allowed?
as already mentioned, RDP security works.

what might not be happy is your distribution or SSL policy.
(yea I know flatpak, but the SSL is from your distro)

[ndonkersloot]

@akallabeth
Thank you for that insight, i'll experiment with that.

[ndonkersloot]

@akallabeth
I'm using openssl 3.1.1 on my system (fedora silverblue 39).

rpm -qa | grep openssl-libs openssl-libs-3.1.1-4.fc39.x86_64
I've tried the LEGACY crypto-policies using update-crypto-policies but that didn't solve the issue.
I'm gonna build from master later to have additional logging.

[ndonkersloot]

@akallabeth
I've rebased my Fedora Silverblue system to use fedora40 because fedora 40 ships with frreerdp 3.3.0.
I've installed the freerdp 3.3.0 from the fedora repo's and indeed, /sec:rdp does work there!

However, the flatpak still doesn't work.
I'm not sure how to debug the flatpak but on my system freerdp 3.3.0 installed via repo's does work with /sec:rdp and flatpak freerdp 3.3.0 does not.

Any advice?

[ndonkersloot]

I haven't put a lot of time in it yet but noticed two things:

I get errors when running that the /dev/dri/card1 can't be found. I think the permission --device=dri needs to be set in the flatpak manifest. Once I do that the error goes away.

amdgpu_device_initialize: amdgpu_get_auth (1) failed (-1)
amdgpu: amdgpu_device_initialize failed.
glx: failed to create dri3 screen
failed to load driver: radeonsi
failed to open /dev/dri/card1: No such file or directory
failed to load driver: radeonsi

I get errors regarding the x509 certificate, I only get this with the flatpak version, not with the local repository install. So I'm starting to think this is the reason it doesn't work.

[ERROR][com.freerdp.core] - [update_x509_from_info]: failed to update x509 from rdpCertInfo
[ERROR][com.freerdp.core] - [certificate_read_server_x509_certificate_chain]: Failed to read x509 certificate
[ERROR][com.freerdp.core.gcc] - [gcc_read_conference_create_response]: gcc_read_conference_create_response: gcc_read_server_data_blocks failed
[ERROR][com.freerdp.core] - [mcs_recv_connect_response]: gcc_read_conference_create_response failed
[ERROR][com.freerdp.core.rdp] - [rdp_recv_callback_int][0x561a71e0f050]: mcs_recv_connect_response failure
[ERROR][com.freerdp.core.rdp] - [rdp_recv_callback_int][0x561a71e0f050]: CONNECTION_STATE_MCS_CREATE_RESPONSE status STATE_RUN_FAILED [-1]
[ERROR][com.freerdp.core.transport] - [transport_check_fds]: transport_check_fds: transport->ReceiveCallback() - STATE_RUN_FAILED [-1]
[ERROR][com.freerdp.core] - [rdp_client_wait_for_activation]: ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D]

I'll definitely going to spend some more time at this, but maybe this error speaks more to you than it does to me right now.

[akallabeth]

@ndonkersloot ok, that confirms my suspicion: [update_x509_from_info]: failed to update x509 from rdpCertInfo means that the SSL is not allowing raw RSA operations.

[ndonkersloot]

@ndonkersloot ok, that confirms my suspicion: [update_x509_from_info]: failed to update x509 from rdpCertInfo means that the SSL is not allowing raw RSA operations.

I'm not a programmer, let alone a C programmer, but I did some digging and think it goes into this fail.
I'm not sure how to x509 cert is created, but my gut is pointing to winpr-makecert.

I've entered the flatpak sandbox with bash to poke around there to verify some things:

The flatpak itself has openSSL 3.1.5:

bash-5.2$ openssl version
OpenSSL 3.1.5 30 Jan 2024 (Library: OpenSSL 3.1.5 30 Jan 2024)

A connection from the flatpak to the RDP server is possible from within the flatpak itself:

bash-5.2$ openssl s_client -connect 172.19.123.184:3389
CONNECTED(00000003)

Creating a certificate with openssl from within the flatpak sandbox works:

bash-5.2$ openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out private_key.pem
.....+.+..+.+..............+++++++++++++++++++++++++++++++++++++++*....+..+.........+++++++++++++++++++++++++++++\++++++++++*....+...+...............+..+.......+......+..+..........+........+.........+.+........+......+.+...+..............+.+......+........+.....................+............+...+.+........+.............+.................+.....................+.......+...+......+.....+...+.+............+...+......+...+.....+...+.........+.+.....+.............+..............+.+..+....+......+..+.+..+.......+..+...+......+..........+......+...+.....+...+...++++++
..+++++++++++++++++++++++++++++++++++++++*......+...........+.+.....+++++++++++++++++++++++++++++++++++++++*...+...+..+..................+.+..............+.+.....+.........+...+............+..................+.......+............+.....+....+...........+..........+........+.+............+.....+..........+...+......+...........+...+....+........+....+...........+...++++++
bash-5.2$ ls
private_key.pem

Creating a certificate with winpr-makecert from within the flatpak sandbox does work:

bash-5.2$ /app/bin/winpr-makecert -rdp
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 3750714 (0x393b3a)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=lenovo-t14
        Validity
            Not Before: Mar 13 09:33:38 2024 GMT
            Not After : Mar 13 09:33:38 2025 GMT
        Subject: CN=lenovo-t14
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:c1:c4:54:48:8a:c5:26:d3:67:a1:a9:71:13:a6:
                    d5:d9:e3:ca:b1:7d:2f:d8:d2:63:0c:6a:dc:95:6b:
                    07:0f:6c:a9:92:20:b0:c5:bb:ae:fd:92:b0:fc:82:
                    72:1a:3a:1e:2f:86:88:02:b8:06:55:97:79:96:a0:
                    28:a7:50:07:c6:49:43:8f:93:82:ca:57:21:94:16:
                    fc:13:7d:92:3f:87:7c:a4:ec:9a:46:2c:48:9c:00:
                    dd:c8:92:99:1a:44:8e:4d:e5:ec:5d:c2:85:71:69:
                    90:3d:45:0d:bb:05:4a:84:b9:f2:bf:c0:b9:22:fd:
                    72:ff:e6:45:bd:8b:e7:2b:e6:1d:22:ef:67:b6:87:
                    20:ff:b5:b1:ea:0e:c5:28:ce:8a:28:7e:0d:37:a8:
                    ad:34:73:32:a1:c7:59:b9:f2:5e:35:9c:f8:2f:1a:
                    2a:43:31:34:d5:b3:ec:a0:f1:40:93:f5:ae:4c:31:
                    9f:a2:e1:b4:c1:97:31:54:09:62:c2:85:2a:84:a7:
                    9d:71:77:50:a6:5f:78:7f:8f:66:44:a6:ec:ab:41:
                    1e:76:f8:77:51:5f:57:f2:0d:c5:9c:46:5e:21:cf:
                    a4:64:ed:05:15:c0:bb:67:c2:98:1d:f4:18:30:23:
                    5b:e8:87:9b:71:17:d8:84:b2:68:e0:99:71:1c:b5:
                    f4:8f
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        6a:c1:07:08:a9:60:29:e6:d1:22:ab:0f:6b:77:e2:53:d3:f1:
        b8:25:3f:3a:df:76:b3:6a:1a:1f:ba:71:22:7c:0e:e8:7f:b5:
        51:c5:55:9b:e0:b6:a2:e2:d7:61:a2:16:e7:a2:65:ca:b0:ba:
        03:ad:95:6c:12:a3:48:81:66:c5:61:eb:87:1e:d3:23:0c:b4:
        c4:a6:de:58:1f:3d:4f:f9:d0:9a:85:6e:0a:6b:b8:88:2b:31:
        4c:d3:b0:96:97:66:d7:f3:ad:54:f4:97:c7:70:8b:00:3c:65:
        09:32:c0:c0:96:24:04:df:43:0b:30:6f:ba:14:85:b5:3d:25:
        50:7d:bb:f0:19:39:85:be:fb:7b:d4:bf:53:eb:3d:8c:1e:a1:
        60:91:b5:5e:60:f3:89:21:ac:2f:f8:21:c3:63:f1:f3:3b:6c:
        a0:db:1a:91:7b:3e:7a:d7:94:b3:2d:6d:ec:07:e0:0d:6a:97:
        0c:d2:15:ae:3e:c9:d8:a3:91:d6:7e:e7:8a:e1:0b:09:ef:06:
        77:15:79:bb:5c:ae:67:e3:73:88:47:65:02:f9:17:e8:44:fa:
        f3:f8:15:06:43:6b:cd:44:e1:3a:a2:6a:fa:92:e9:da:ec:15:
        41:5a:06:8d:15:d9:b7:9d:8b:00:76:53:19:09:1f:b2:48:7b:
        e7:6e:36:a7

Maybe this info is helpful for you.
At a later time I'll poke around some more to hopefully locate and fix the issue.

[akallabeth]

there is quite a difference.

• the winpr-makecert just creates a new certificate (standard API calls)
• update_x509_from_info creates a RSA certificate from raw numbers (low level deprecated API calls)

[ndonkersloot]

I haven't found the time yet to look further into this, but I'm committed to do so.

Can you reproduce the issue yourself?
Could you re-open the issue as it still persists, although only for the flatpak release.

[akallabeth]

yes. you can check with:

1. flatpak run --command=bash com.freerdp.FreeRDP
2. openssl list -providers
3. output should be:

Providers:
  default
    name: OpenSSL Default Provider
    version: 3.1.5
    status: active

[ndonkersloot]

That is correct:

[📦 com.freerdp.FreeRDP ~]$ openssl list -providers
Providers:
  default
    name: OpenSSL Default Provider
    version: 3.1.5
    status: active

This is the output from a build of the latest master where the issue is reproducible.