How does one upgrade the rdp service on windows 7 to use tls 1.3? I'm trying to force freerdp on the guacamole server to downgrade to tls 1.1 to talk to legacy equipment
________________________________ From: Sean Hulbert <[email protected]> Sent: Tuesday, July 22, 2025 5:02:06 PM To: [email protected] <[email protected]> Subject: Re: [EXTERNAL]Re: Force TLS version in FreeRDP? CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Your best installing openssl 3.x run TLS 1.3 fall back to 1.2, as 1.1 is not secure. Use Nginx and certbot letsencrypt to get a free SSL and it will update automatically every 6 months. Nignx secure config running AES 256 over tcpip example: listen 443 default ssl; ssl_certificate /etc/nginx/ssl/bundle/YourDomainHere-bundle.crt; ssl_certificate_key /etc/nginx/ssl/private/YourDomainHere.key; ssl_session_timeout 5m; ssl_protocols TLSv1.3 TLSv1.2; ssl_ciphers ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA; ssl_session_cache shared:SSL:50m; ssl_dhparam /etc/nginx/ssl/dhparam.pem; You should also run a Layer 7 firewall if you are worried about attempted exploits, MFA and fail2ban are good deterrents as well. Thank You Sean On 7/22/2025 1:52 PM, Bob Healey wrote: I'm running native, built from sources, on FreeBSD via their ports tree. FreeRDP 2.11.7 and Guacamole 1.6.0. OpenSSL s_client fails, except when I explicitly specify tls 1.1, which is why I was leaning in that direction with FreeRDP. My logged errors are about invalid/no certificate. I've obfuscated the host names just to avoid giving people a valid DNS name to hammer our external firewall with. healer@GUAC_HOST:~ $ openssl s_client -connect ZZZZ-lab-YYYY.XXXXXXXXXXXX.rpi.edu:3389 CONNECTED(00000003) write:errno=54 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 332 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- healer@GUAC_HOST:~ $ openssl s_client -connect ZZZZ-lab-YYYY.XXXXXXXXXXXX.rpi.edu:3389 -tls1_1 CONNECTED(00000003) depth=0 CN = ZZZZ-lab-YYYY.XXXXXXXXXXXX.rpi.edu verify error:num=18:self-signed certificate verify return:1 depth=0 CN = ZZZZ-lab-YYYY.XXXXXXXXXXXX.rpi.edu verify return:1 081085EEF4360000:error:0A00014D:SSL routines:tls_process_key_exchange:legacy sigalg disallowed or unsupported:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:2255: --- Certificate chain 0 s:CN = ZZZZ-lab-YYYY.XXXXXXXXXXXX.rpi.edu i:CN = ZZZZ-lab-YYYY.XXXXXXXXXXXX.rpi.edu a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA1 v:NotBefore: Jul 6 15:37:50 2025 GMT; NotAfter: Jan 5 15:37:50 2026 GMT --- Server certificate -----BEGIN CERTIFICATE----- <snipped> -----END CERTIFICATE----- subject=CN = ZZZZ-lab-YYYY.XXXXXXXXXXXX.rpi.edu issuer=CN = ZZZZ-lab-YYYY.XXXXXXXXXXXX.rpi.edu --- No client certificate CA names sent Server Temp Key: ECDH, prime256v1, 256 bits --- SSL handshake has read 1199 bytes and written 146 bytes Verification error: self-signed certificate --- New, (NONE), Cipher is (NONE) Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.1 Cipher : 0000 Session-ID: E109000004CB9BE9BBF225B331DC8EA7371A72037EFE8237C6361B691DA39980 Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1753216892 Timeout : 7200 (sec) Verify return code: 18 (self-signed certificate) Extended master secret: yes --- healer@GUAC_HOST:~ $ openssl s_client -connect ZZZZ-lab-YYYY.XXXXXXXXXXXX.rpi.edu:3389 -tls1_2 CONNECTED(00000003) write:errno=54 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 223 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1753216897 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no --- healer@GUAC_HOST:~ $ On 7/22/25 15:06, Nick Couchman wrote: CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Tue, Jul 22, 2025 at 10:18 AM Healey, Robert Andrew <[email protected]<mailto:[email protected]>> wrote: Since upgrading to Guacamole 1.6, I've lost the ability to connect to hosts running Windows 7 over Remote Desktop. Are you running Guacamole in Docker or installed natively? My Windows XP, Windows 10, Windows 11, and XRDP hosts are all still working fine. It looks like from the logs I'm having TLS failiures since the Windows 7 hosts seem to only be happy with TLS 1.1 connections. Is there a way to force the TLS version FreeRDP uses for specific connections? I'm using the MySQL extension. No, but FreeRDP should negotiate this, and, if I recall correctly, the range of options that FreeRDP can negotiate is limited by the OpenSSL configuration of the Linux install on which FreeRDP (=guacd) is running. I see this most often when upgrading to something like RHEL9/Rocky9 where the default TLS configuration is very strict regarding old TLS versions, and it takes some amount of deliberate manual intervention to enable older TLS versions, SHA algorithms, etc. Depending on where you're running Guacamole - either in Docker or what Linux distribution - you may have to adjust things in some different ways. And before anyone decides to lecture me on running legacy OS's in production, I am using Guacamole to filter/proxy remote access to laboratory equipment that is locked to a specific OS build and is otherwise isolated from the general network. I'm quite sympathetic to your plight in that regard - my day job includes maintaining a handful of legacy platforms of various ilks that sometimes take creative means to access properly while still maintaining a secure network. I would venture a guess that anyone working for a company that's been around longer than 10 years has at least one or two similar challenges. -Nick -- Bob Healey '05 Senior Systems Administrator Office of Research and Scientific Computation Research Center [email protected]<mailto:[email protected]> (518) 276-6022
