New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

forward secrecy support with openssl 1.0.2 #1023

Closed
enricotagliavini opened this Issue Feb 2, 2018 · 4 comments

Comments

Projects
None yet
2 participants
@enricotagliavini
Contributor

enricotagliavini commented Feb 2, 2018

I'm trying to configure tls_ciphers to use something with forward secrecy. I've tried to use the same ciphers list I use for apache httpd (so it's tested and it works) but was not able to get a connection working with XRDP when using these.

Starting point (it works like this):

security_layer=tls
crypt_level=high
certificate=/etc/xrdp/cert.pem
key_file=/etc/xrdp/key.pem
ssl_protocols=TLSv1.2
tls_ciphers=HIGH

xrdp logs will show

[20180202-10:44:21] [INFO ] Socket 12: AF_INET connection received from <client IP> port 37802
[20180202-10:44:21] [DEBUG] Closed socket 12 (AF_INET <server IP>:3389)
[20180202-10:44:21] [DEBUG] Closed socket 11 (AF_INET 0.0.0.0:3389)
[20180202-10:44:21] [DEBUG] TLSv1.2 enabled
[20180202-10:44:21] [DEBUG] Security layer: requested 3, selected 1
[20180202-10:44:31] [INFO ] connected client computer name: <client hostname>
[20180202-10:44:31] [INFO ] TLS connection established from <client ip> port 37802: TLSv1.2 with cipher AES256-GCM-SHA384

As far as I know AES256-GCM-SHA384 doesn't provide any forward secrecy. If the server private key is leaked all previously recorded traffic could be decrypted.

So I tried the following:

security_layer=tls
crypt_level=high
certificate=/etc/xrdp/cert.pem
key_file=/etc/xrdp/key.pem
ssl_protocols=TLSv1.2
tls_ciphers=ECDHE-RSA-AES128-GCM-SHA256

Trying to connect with xfreerdp or the Windows remote desktop client doesn't work in this case, TLS handshake fails. For example xfreerdp shows

$ xfreerdp /v:vcl1034.fmi.ch /log-level:TRACE
[10:55:11:769] [10219:10220] [DEBUG][com.freerdp.channels.cliprdr.client] - VirtualChannelEntryEx
[10:55:11:769] [10219:10220] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
[10:55:11:769] [10219:10220] [INFO][com.freerdp.client.x11] - No user name set. - Using login name: taglenri
[10:55:12:777] [10219:10220] [DEBUG][com.freerdp.client.x11] - Searching for XInput pointer device
[10:55:12:777] [10219:10220] [DEBUG][com.freerdp.client.x11] - Pointer device: 11
[10:55:12:779] [10219:10220] [DEBUG][com.freerdp.core.nego] - Enabling security layer negotiation: TRUE
[10:55:12:779] [10219:10220] [DEBUG][com.freerdp.core.nego] - Enabling restricted admin mode: FALSE
[10:55:12:779] [10219:10220] [DEBUG][com.freerdp.core.nego] - Enabling RDP security: TRUE
[10:55:12:779] [10219:10220] [DEBUG][com.freerdp.core.nego] - Enabling TLS security: TRUE
[10:55:12:779] [10219:10220] [DEBUG][com.freerdp.core.nego] - Enabling NLA security: TRUE
[10:55:12:779] [10219:10220] [DEBUG][com.freerdp.core.nego] - Enabling NLA extended security: FALSE
[10:55:12:779] [10219:10220] [DEBUG][com.freerdp.core.nego] - state: NEGO_STATE_NLA
[10:55:12:779] [10219:10220] [DEBUG][com.freerdp.core.nego] - Attempting NLA security
[10:55:12:782] [10219:10220] [DEBUG][com.freerdp.core.nego] - RequestedProtocols: 3
[10:55:12:789] [10219:10220] [DEBUG][com.freerdp.core.nego] - RDP_NEG_RSP
[10:55:12:789] [10219:10220] [DEBUG][com.freerdp.core.nego] - selected_protocol: 1
[10:55:12:789] [10219:10220] [DEBUG][com.freerdp.core.nego] - state: NEGO_STATE_FINAL
[10:55:12:789] [10219:10220] [DEBUG][com.freerdp.core.nego] - Negotiated TLS security
[10:55:12:789] [10219:10220] [DEBUG][com.freerdp.core.nego] - nego_security_connect with PROTOCOL_TLS
[10:55:12:790] [10219:10220] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_TLS_CONNECT_FAILED [0x00020008]
[10:55:12:790] [10219:10220] [DEBUG][com.freerdp.core.nego] - Failed to connect with TLS security
[10:55:12:790] [10219:10220] [ERROR][com.freerdp.core.connection] - Error: protocol security negotiation or connection failure

and the xrdp logs are showing

[20180202-10:54:53] [INFO ] Socket 12: AF_INET connection received from <client IP> port 37970
[20180202-10:54:53] [DEBUG] Closed socket 12 (AF_INET <server IP>:3389)
[20180202-10:54:53] [DEBUG] Closed socket 11 (AF_INET 0.0.0.0:3389)
[20180202-10:54:53] [DEBUG] TLSv1.2 enabled
[20180202-10:54:53] [DEBUG] Security layer: requested 3, selected 1
[20180202-10:54:53] [DEBUG] Closed socket 12 (AF_INET <server IP>:3389)

Is it me doing something wrong or is this a bug / unsupported cipher(s)?

Server info:

  • CentOS 7
  • xrdp 0.9.5 from EPEL repository

Tested clients are Fedora 27 using freerdp 2.0 and Windows 10 remote desktop client

@enricotagliavini enricotagliavini changed the title from how to use forward secrecy? to how to use forward secrecy with TLS? Feb 2, 2018

@enricotagliavini

This comment has been minimized.

Contributor

enricotagliavini commented Feb 2, 2018

Mhm this might actually be a bug in the EPEL package for xrdp. Just tried a Fedora 27 test server machine and that worked as expected. I'll try to double check and post my findings here. Sorry for the noise if this was actually a packaging issue.

@enricotagliavini

This comment has been minimized.

Contributor

enricotagliavini commented Feb 2, 2018

Actually turns out this might be a limitation of the current xrdp code when using openssl 1.0.2 (which is what CentOS / Red Hat are shipping) vs. the newer openssl 1.1 shipped in Fedora. According to the official openssl wiki [1] the Perfect Forward Secrecy cipher suite must be explicitly enabled in the application or it will be silently ignored. I looked for the mentioned code in xrdp but I didn't found anything like that.

I can also confirm Red Hat / CentOS is patching their default httpd daemon package to activate the Perfect Forward Secrecy cipher suite as can be found in [2]

[1] https://wiki.openssl.org/index.php/Diffie-Hellman_parameters
[2] https://git.centos.org/blob/rpms!httpd.git/c7/SOURCES!httpd-2.4.6-ssl-ecdh-auto.patch

@enricotagliavini

This comment has been minimized.

Contributor

enricotagliavini commented Feb 2, 2018

I opened pull request #1024 . With that code change applied automatic ECDH was working when using openssl 1.0.2k as found in CentOS as of today. This made possible a connection using the ECDHE-RSA-AES256-GCM-SHA384 cipher and fixed the issue.

@enricotagliavini enricotagliavini changed the title from how to use forward secrecy with TLS? to forward secrecy support with openssl 1.0.2 Feb 2, 2018

@metalefty metalefty added the TLS label Feb 3, 2018

@metalefty

This comment has been minimized.

Member

metalefty commented Mar 1, 2018

Merged #1024.

@metalefty metalefty closed this Mar 1, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment