remmina "Cannot connect to the RDP server ... via TLS. Check that the client and server support a common TLS version"

Thank you for your bug report, could you try the update on https://bugs.launchpad.net/ubuntu/+source/freerdp2/2.4.1+dfsg1-1ubuntu1 and tell us if it fixes your issue?

I tried, and it not fixed.

Is there anything specific to the setup you are using? There is a report upstream about gateway issue with openssl3, https://github.com/FreeRDP/FreeRDP/issues/7449

I don't have a win8 to test but connecting to a standard win10 pro desktop works without issue using the current freerdp package (even before the recent patches)

It might be worth reporting the issue on github directly, they probably would have a better understanding of the issue than we do here without an active maintainer for that stack in Ubuntu

Status changed to 'Confirmed' because the bug affects multiple users.

I have a similar issue. With libfreerdp2 being built against libssl.so.3 it doesn't work at all

Btw snap version:

$ ldd /snap/remmina/5237/usr/lib/libfreerdp2.so.2.6.1
        ...
        libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007fe684581000)

I believe that distro version of OpenSSLv3 is missing some neccessary extension

This is happening to me as well, see the bug report here:
https://github.com/FreeRDP/FreeRDP/issues/7449

It appears to be an issue with any RD Gateway and related to OpenSSL 3....
I tried the Flatpak method suggested and that works for me using the command line but would really like to be able to get back to using Remmina.

Update: Installed Remmina using Flatpak Edge version and it now works properly. Also tried the Snaps but couldn't get them to work.

it is now fixed upstream and in stable-2.0
https://github.com/FreeRDP/FreeRDP/pull/7823
https://github.com/FreeRDP/FreeRDP/pull/7822

>https://github.com/FreeRDP/FreeRDP/pull/7822

I've been testing this patch and it didn't help in my case

https://github.com/FreeRDP/FreeRDP/pull/7822 addresses a gateway issue only, so if you don't use a gateway this will not fix anything for you.

I just compiled the latest ubuntu 2.6.1 version with this patch applied and for me now gateway connections work

> I've been testing this patch and it didn't help in my case

what would probably be useful in this thread if someone would post the output of ex.

xfreerdp /v: .... /log-level:debug

I know we are talk about remmina here, but it would be very strange if xfreerdp works and remmina doesn't.

For me before applying this patch the relevant last lines where

[DEBUG][com.freerdp.core.nego] - nego_security_connect with PROTOCOL_HYBRID
[ERROR][com.freerdp.core] - rdg_process_close_packet:freerdp_set_last_error_ex E_PROXY_INTERNALERROR [0x800759D8]
[com.freerdp.core.nego] - Failed to connect with NLA security

I do use a gateway actually

again: a debug log output would be very useful.
With a gateway there are actually two TLS handshakes. It would be useful what handshake fails.

What version of RD Gateway are you using? If it is a 2008/2008R2 based one, is that even openssl3 compatible? (I checked that TLS1.0 is enabled on the https tls handshake, but I don't know if a required cipher match is there since I don't have a such old server available)

I just discovered that a direct tls connection to a windows 7 (=2008r2) rdp server indeed fails with
ERRCONNECT_TLS_CONNECT_FAILED

the error is that there is no cipher match (this probably happens also with a 2008r2 based rdp gateway server, but that someone would need to check)

this however can be workarounded by /tls-seclevel:0

If this resolves your issue I would suggest making this the default for freerdp. If someone from the Ubuntu team is willing to integrate such a thing I would make a downstream patch for that too..

The relevant change is SHA1 in openssl3
https://github.com/openssl/openssl/commit/aba03ae571ea677fc484daef00a21ca8f7e82708
SHA1 is, contrary to what someone would expect given that the documentation says:

Level 4

Security level set to 192 bits of security. As a result RSA, DSA and
DH keys shorter than 7680 bits and ECC keys shorter than 384 bits are
prohibited. Cipher suites using SHA1 for the MAC are prohibited. TLS
versions below 1.2 are not permitted.

Thanks for the details shared here. We should start by SRUing the gateway fix mentioned, then it sounds like there are other issues being discussed that would be better to be split in a new report?

reading the first message actually it would be better splitting out the gateway fix since this bug really talks about windows 2008r2. If you agree I will make a new report about the backport of the gateway fix

yes, it would be better, thanks

ok, I created a bug report dedicated for the rdp gateway issue
https://bugs.launchpad.net/ubuntu/+source/freerdp2/+bug/1970655

regarding the windows 6.1 tls issue (Windows 7 and Windows Server 2008 R2, probably also Vista and Server 2008) there is now an upstream report here

https://github.com/FreeRDP/FreeRDP/issues/7839

but I think this one needs to be decided downstream if we want to support Windows 7/2008R2 out of the box or, like in other places where old tls versions where disabled, we want to drop support for that.

A possible workaround for the average user in that case (or also right now) might be disabling nla on the windows 7 machine and using rdp security instead of tls or nla.

Well. What do I have

1) I have no control over the gateway software.
2) xfreerdp is blocked here. No matter what I do I'm always getting 403 status code.
3) There's no way to try the security level workaround in Remmina.

So I guess that is it for now. The only way around is to rebuild freerdp2 against openssl 1.1

@blaze status 403 is quite strange, but afaik openssl1.1 is not in jammy. If you still have it this is because it probably does not get removed when updating.

I will try to make a package that fixes both rdp gateway and windows < 8.
It would be very useful if you (and probably others) would be able to test this

note however that the gateway part is now this bug report: https://bugs.launchpad.net/ubuntu/+source/freerdp2/+bug/1970655

I have built a version that includes my mentioned security level workaround.

It's in ppa:saxl/freerdp2

With that this bug report should be addressed

The issue with connecting with gateway has been fixed for me with the release of freerdp2-wayland and freerdp2-x11 version 2.6.1+dfsg1-3ubuntu1

@omriasta are you sure you did not use /sec:rdp? 2.6.1+dfsg1-3ubuntu1 does not contain the upstream patch and will 100% not work over gateway if linked to openssl3 and using a tls based transport over rdp gateway (nla/ext/tls), but as said /sec:rdp always worked if the remote end allowed it
The version in my ppa is 2.6.1+dfsg1-3ubuntu1.2~gwfix, if you meant that one

remmina will probably have a tls security level switch in the future.

https://gitlab.com/Remmina/Remmina/-/commit/cf4d8f99ac258248b8e3f3a5314ae047a210a3e9

imo it would be cleaner to backport this instead of lowering the default security for everyone.
In the next ubuntu version I think the will be an updated remmina, so if we decide to lower the default level in 22.04 with a sru, we must not forget to drop that in kosmic.
The only other applications that uses libfreerdp directly I know of are libguac-client-rdp0 and krdc, but I think they will also adopt as soon as it will be obvious that such a setting is needed for a successful connection to older OSes

Backporting that UI seems indeed a better solution than lowering the default value

There is a fix for the gateway issue in jammy-proposed now, https://launchpad.net/ubuntu/+source/freerdp2/2.6.1+dfsg1-3ubuntu2/+build/23606934, if someone wants to try it

I can confirm that 2.6.1+dfsg1-3ubuntu2 fixes the gateway issue

Thanks msaxl!

The 2.6.1+dfsg1-3ubuntu2 libfreerdp2-2 found on jammy-updates fixes the RD gateway access issue for me too. Thanks, I can use Remmina again. A bit disconcerting that Remmina seems to be the only GUI option for this task. Much depends on it working. Shocking that the bug made it all the way to 22.04 LTS release. Happy for the fix!
Your bleeding user

> A bit disconcerting that Remmina seems to be the only GUI option for this task.

KRDC works for this as you can add xfreerdp flags in the "Extra Options" box for each host or add it to the default Extra Options.

We had several fixes landing in freerdp since that issue was report. Dmitry could you try if you still see the problem in the current version?

Using Remmina 1.4.27 (git n/a)

LSB Version: core-11.1.0ubuntu4-noarch:printing-11.1.0ubuntu4-noarch:security-11.1.0ubuntu4-noarch
Distributor ID: Ubuntu
Description: Ubuntu 22.04.1 LTS
Release: 22.04
Codename: jammy

Not Working cannot connect to RDP

@t2t-exe some questions:
is the error message exactly the one mentioned here?
what version is the target rdp server (Windows7, Windows 10, Windows Server 2019, ..)?
since you use a new remmina version, what is the tls security level set to?

I can confirm that the remmina-next PPA (currently offering version 1.4.27) provides a TLS Security Level drop down in the Advanced tab and that by choosing the option "0 - Windows 7 compatible" works to connect to a Windows Server 2008 R2 (which does not have ssl3 enabled) from an Ubuntu 22.04.1 client as per:

https://gitlab.com/Remmina/Remmina/-/wikis/home

Packages updated for me by this PPA were:
freerdp2-x11 libfreerdp-client2-2 libfreerdp-server2-2 libfreerdp2-2 libwinpr2-2

runnuni as suggested didnt help:

$ remmina --set-option tls-seclevel=0

Any time frame when 1.27 will be available in Ubuntu's repo?

I don't think remmina will be updated to 1.27 (1.26 would be enough). Usually the version of the package remain the same, only some patches get applied when needed. Browsers are exempt from that rule.

Ubuntu maintainers might cherry pick this:
https://gitlab.com/Remmina/Remmina/-/merge_requests/2402/diffs?commit_id=ecfa4fe4a93f99fd8991eb18fc1442c01b642a07

but they must be convinced this is a issue for enough people to do that.

Unsubscribing since I'm not working on that issue