neutrinolabs / xrdp

xrdp: an open source RDP server
http://www.xrdp.org/
Apache License 2.0
5.75k stars 1.73k forks source link

Enableing security_layer=tls breaks all rdp clients #1172

Closed Hyper200 closed 6 years ago

Hyper200 commented 6 years ago

Hi all,

Trying to configure TLS on xrdp but having issues.

[Globals]
; xrdp.ini file version number
ini_version=1

; fork a new process for each incoming connection
fork=true
; tcp port to listen
port=3389
#address=127.0.0.1
; 'port' above should be connected to with vsock instead of tcp
use_vsock=false
; regulate if the listening socket use socket option tcp_nodelay
; no buffering will be performed in the TCP stack
tcp_nodelay=true
; regulate if the listening socket use socket option keepalive
; if the network connection disappear without close messages the connection will be closed
tcp_keepalive=true
#tcp_send_buffer_bytes=32768
#tcp_recv_buffer_bytes=32768

; security layer can be 'tls', 'rdp' or 'negotiate'
; for client compatible layer
security_layer=tls
; minimum security level allowed for client
; can be 'none', 'low', 'medium', 'high', 'fips'
#crypt_level=medium
; X.509 certificate and private key
; openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem -days 365
certificate=/etc/xrdp/cert-mottmac.pem
key_file=/etc/xrdp/key-mottmac.pem
; set SSL protocols
; can be comma separated list of 'SSLv3', 'TLSv1', 'TLSv1.1', 'TLSv1.2'
ssl_protocols=TLSv1,TLSv1.1,TLSv1.2
; set TLS cipher suites
tls_ciphers=HIGH

; Section name to use for automatic login if the client sends username
; and password. If empty, the domain name sent by the client is used.
; If empty and no domain name is given, the first suitable section in
; this file will be used.
autorun=

allow_channels=true
allow_multimon=true
bitmap_cache=true
bitmap_compression=true
bulk_compression=true
#hidelogwindow=true
max_bpp=32
new_cursors=true
; fastpath - can be 'input', 'output', 'both', 'none'
use_fastpath=both
; when true, userid/password *must* be passed on cmd line
#require_credentials=true
; You can set the PAM error text in a gateway setup (MAX 256 chars)
#pamerrortxt=change your password according to policy at http://url

;
; colors used by windows in RGB format
;
blue=009cb5
grey=dedede
#black=000000
#dark_grey=808080
#blue=08246b
#dark_blue=08246b
#white=ffffff
#red=ff0000
#green=00ff00
#background=626c72

;
; configure login screen
;

; Login Screen Window Title
#ls_title=My Login Title

; top level window background color in RGB format
ls_top_window_bg_color=009cb5

; width and height of login screen
ls_width=350
ls_height=430

; login screen background color in RGB format
ls_bg_color=dedede

; optional background image filename (bmp format).
#ls_background_image=

; logo
; full path to bmp-file or file in shared folder
ls_logo_filename=
ls_logo_x_pos=55
ls_logo_y_pos=50

; for positioning labels such as username, password etc
ls_label_x_pos=30
ls_label_width=60

; for positioning text and combo boxes next to above labels
ls_input_x_pos=110
ls_input_width=210

; y pos for first label and combo box
ls_input_y_pos=220

; OK button
ls_btn_ok_x_pos=142
ls_btn_ok_y_pos=370
ls_btn_ok_width=85
ls_btn_ok_height=30

; Cancel button
ls_btn_cancel_x_pos=237
ls_btn_cancel_y_pos=370
ls_btn_cancel_width=85
ls_btn_cancel_height=30

[Logging]
LogFile=xrdp.log
LogLevel=DEBUG
EnableSyslog=true
SyslogLevel=DEBUG
; LogLevel and SysLogLevel could by any of: core, error, warning, info or debug

[Channels]
; Channel names not listed here will be blocked by XRDP.
; You can block any channel by setting its value to false.
; IMPORTANT! All channels are not supported in all use
; cases even if you set all values to true.
; You can override these settings on each session type
; These settings are only used if allow_channels=true
rdpdr=true
rdpsnd=true
drdynvc=true
cliprdr=true
rail=true
xrdpvr=true
tcutils=true

; for debugging xrdp, in section xrdp1, change port=-1 to this:
#port=/tmp/.xrdp/xrdp_display_10

; for debugging xrdp, add following line to section xrdp1
#chansrvport=/tmp/.xrdp/xrdp_chansrv_socket_7210

;
; Session types
;

; Some session types such as Xorg, X11rdp and Xvnc start a display server.
; Startup command-line parameters for the display server are configured
; in sesman.ini. See and configure also sesman.ini.
[Xorg]
name=Xorg
lib=libxup.so
username=ask
password=ask
ip=127.0.0.1
port=-1
code=20

[X11rdp]
name=X11rdp
lib=libxup.so
username=ask
password=ask
ip=127.0.0.1
port=-1
xserverbpp=24
code=10

[Xvnc]
name=Xvnc
lib=libvnc.so
username=ask
password=ask
ip=127.0.0.1
port=-1
#xserverbpp=24
#delay_ms=2000

[console]
name=console
lib=libvnc.so
ip=127.0.0.1
port=5900
username=na
password=ask
#delay_ms=2000

[vnc-any]
name=vnc-any
lib=libvnc.so
ip=ask
port=ask5900
username=na
password=ask
#pamusername=asksame
#pampassword=asksame
#pamsessionmng=127.0.0.1
#delay_ms=2000

[sesman-any]
name=sesman-any
lib=libvnc.so
ip=ask
port=-1
username=ask
password=ask
#delay_ms=2000

[neutrinordp-any]
name=neutrinordp-any
lib=libxrdpneutrinordp.so
ip=ask
port=ask3389
username=ask
password=ask

; You can override the common channel settings for each session type
#channel.rdpdr=true
#channel.rdpsnd=true
#channel.drdynvc=true
#channel.cliprdr=true
#channel.rail=true
#channel.xrdpvr=true

If i have security_layer=rdp the connection works and i can login.

If set to TLS my windows client gets the following error: capture

Trying to debug the issue but the log is not that helpful:

==> xrdp-sesman.log <==
[20180720-14:09:16] [DEBUG] Closed socket 5 (AF_INET6 ::1 port 3350)
[20180720-14:09:16] [INFO ] starting xrdp-sesman with pid 1579
[20180720-14:09:16] [INFO ] listening to port 3350 on 127.0.0.1
[20180720-14:15:21] [INFO ] shutting down sesman 1
[20180720-14:15:21] [DEBUG] Closed socket 7 (AF_INET6 ::1 port 3350)
[20180720-14:15:23] [DEBUG] libscp initialized
[20180720-14:15:23] [DEBUG] Testing if xrdp-sesman can listen on 127.0.0.1 port 3350.
[20180720-14:15:23] [DEBUG] Closed socket 5 (AF_INET6 ::1 port 3350)
[20180720-14:15:23] [INFO ] starting xrdp-sesman with pid 1693
[20180720-14:15:23] [INFO ] listening to port 3350 on 127.0.0.1

==> xrdp.log <==
[20180720-14:16:34] [INFO ] Socket 12: AF_INET6 connection received from ::ffff:127.0.0.1 port 49928
[20180720-14:16:34] [DEBUG] Closed socket 12 (AF_INET6 ::ffff:127.0.0.1 port 3389)
[20180720-14:16:34] [DEBUG] Closed socket 11 (AF_INET6 :: port 3389)
[20180720-14:16:34] [DEBUG] TLSv1.2 enabled
[20180720-14:16:34] [DEBUG] TLSv1.1 enabled
[20180720-14:16:34] [DEBUG] TLSv1 enabled
[20180720-14:16:34] [DEBUG] Security layer: requested 11, selected 1
[20180720-14:16:34] [DEBUG] Closed socket 12 (AF_INET6 ::ffff:127.0.0.1 port 3389)

I can't seem to figure it out - Does anyone have any suggestions or does this look like a bug?

The RDP connection is being sent via a SSH tunnel hence the 127.0.0.1 addresses.

Its running on Kali linux, xrdp version is

'ii  xorgxrdp                             1:0.2.6-1                      amd64        Remote Desktop Protocol (RDP) modules for X.org
ii  xrdp                                 0.9.6-1                        amd64        Remote Desktop Protocol (RDP) server'

Thanks for any help.

Joe.

speidy commented 6 years ago

The relevant log is xrdp.log or just try running xrdp at the foreground ‘xrdp -ns’ and examine the output.

Also try to set the ‘tls_ciphers’ config to something else or just comment it out. בתאריך יום ו׳, 20 ביולי 2018 ב-16:18 מאת Hyper200 <notifications@github.com

:

Hi all,

Trying to configure TLS on xrdp but having issues.

`[Globals] ; xrdp.ini file version number ini_version=1

; fork a new process for each incoming connection fork=true ; tcp port to listen port=3389

address=127.0.0.1

; 'port' above should be connected to with vsock instead of tcp use_vsock=false ; regulate if the listening socket use socket option tcp_nodelay ; no buffering will be performed in the TCP stack tcp_nodelay=true ; regulate if the listening socket use socket option keepalive ; if the network connection disappear without close messages the connection will be closed tcp_keepalive=true

tcp_send_buffer_bytes=32768

tcp_recv_buffer_bytes=32768

; security layer can be 'tls', 'rdp' or 'negotiate' ; for client compatible layer security_layer=tls ; minimum security level allowed for client ; can be 'none', 'low', 'medium', 'high', 'fips'

crypt_level=medium

; X.509 certificate and private key ; openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem -days 365 certificate=/etc/xrdp/cert-mottmac.pem key_file=/etc/xrdp/key-mottmac.pem ; set SSL protocols ; can be comma separated list of 'SSLv3', 'TLSv1', 'TLSv1.1', 'TLSv1.2' ssl_protocols=TLSv1,TLSv1.1,TLSv1.2 ; set TLS cipher suites tls_ciphers=HIGH

; Section name to use for automatic login if the client sends username ; and password. If empty, the domain name sent by the client is used. ; If empty and no domain name is given, the first suitable section in ; this file will be used. autorun=

allow_channels=true allow_multimon=true bitmap_cache=true bitmap_compression=true bulk_compression=true

hidelogwindow=true

max_bpp=32 new_cursors=true ; fastpath - can be 'input', 'output', 'both', 'none' use_fastpath=both ; when true, userid/password must be passed on cmd line

require_credentials=true

; You can set the PAM error text in a gateway setup (MAX 256 chars)

pamerrortxt=change your password according to policy at http://url

; ; colors used by windows in RGB format ; blue=009cb5 grey=dedede

black=000000

dark_grey=808080

blue=08246b

dark_blue=08246b

white=ffffff

red=ff0000

green=00ff00

background=626c72

; ; configure login screen ;

; Login Screen Window Title

ls_title=My Login Title

; top level window background color in RGB format ls_top_window_bg_color=009cb5

; width and height of login screen ls_width=350 ls_height=430

; login screen background color in RGB format ls_bg_color=dedede

; optional background image filename (bmp format).

ls_background_image=

; logo ; full path to bmp-file or file in shared folder ls_logo_filename= ls_logo_x_pos=55 ls_logo_y_pos=50

; for positioning labels such as username, password etc ls_label_x_pos=30 ls_label_width=60

; for positioning text and combo boxes next to above labels ls_input_x_pos=110 ls_input_width=210

; y pos for first label and combo box ls_input_y_pos=220

; OK button ls_btn_ok_x_pos=142 ls_btn_ok_y_pos=370 ls_btn_ok_width=85 ls_btn_ok_height=30

; Cancel button ls_btn_cancel_x_pos=237 ls_btn_cancel_y_pos=370 ls_btn_cancel_width=85 ls_btn_cancel_height=30

[Logging] LogFile=xrdp.log LogLevel=DEBUG EnableSyslog=true SyslogLevel=DEBUG ; LogLevel and SysLogLevel could by any of: core, error, warning, info or debug

[Channels] ; Channel names not listed here will be blocked by XRDP. ; You can block any channel by setting its value to false. ; IMPORTANT! All channels are not supported in all use ; cases even if you set all values to true. ; You can override these settings on each session type ; These settings are only used if allow_channels=true rdpdr=true rdpsnd=true drdynvc=true cliprdr=true rail=true xrdpvr=true tcutils=true

; for debugging xrdp, in section xrdp1, change port=-1 to this:

port=/tmp/.xrdp/xrdp_display_10

; for debugging xrdp, add following line to section xrdp1

chansrvport=/tmp/.xrdp/xrdp_chansrv_socket_7210

; ; Session types ;

; Some session types such as Xorg, X11rdp and Xvnc start a display server. ; Startup command-line parameters for the display server are configured ; in sesman.ini. See and configure also sesman.ini. [Xorg] name=Xorg lib=libxup.so username=ask password=ask ip=127.0.0.1 port=-1 code=20

[X11rdp] name=X11rdp lib=libxup.so username=ask password=ask ip=127.0.0.1 port=-1 xserverbpp=24 code=10

[Xvnc] name=Xvnc lib=libvnc.so username=ask password=ask ip=127.0.0.1 port=-1

xserverbpp=24

delay_ms=2000

[console] name=console lib=libvnc.so ip=127.0.0.1 port=5900 username=na password=ask

delay_ms=2000

[vnc-any] name=vnc-any lib=libvnc.so ip=ask port=ask5900 username=na password=ask

pamusername=asksame

pampassword=asksame

pamsessionmng=127.0.0.1

delay_ms=2000

[sesman-any] name=sesman-any lib=libvnc.so ip=ask port=-1 username=ask password=ask

delay_ms=2000

[neutrinordp-any] name=neutrinordp-any lib=libxrdpneutrinordp.so ip=ask port=ask3389 username=ask password=ask

; You can override the common channel settings for each session type

channel.rdpdr=true

channel.rdpsnd=true

channel.drdynvc=true

channel.cliprdr=true

channel.rail=true

channel.xrdpvr=true`

If i have security_layer=rdp the connection works and i can login.

If set to TLS my windows client gets the following error: [image: capture] https://user-images.githubusercontent.com/37409036/43004183-e6dae94e-8c26-11e8-91a9-8033983bc13b.PNG

Trying to debug the issue but the log is not that helpful:

`==> xrdp-sesman.log <== [20180720-14:09:16] [DEBUG] Closed socket 5 (AF_INET6 ::1 port 3350) [20180720-14:09:16] [INFO ] starting xrdp-sesman with pid 1579 [20180720-14:09:16] [INFO ] listening to port 3350 on 127.0.0.1 [20180720-14:15:21] [INFO ] shutting down sesman 1 [20180720-14:15:21] [DEBUG] Closed socket 7 (AF_INET6 ::1 port 3350) [20180720-14:15:23] [DEBUG] libscp initialized [20180720-14:15:23] [DEBUG] Testing if xrdp-sesman can listen on 127.0.0.1 port 3350. [20180720-14:15:23] [DEBUG] Closed socket 5 (AF_INET6 ::1 port 3350) [20180720-14:15:23] [INFO ] starting xrdp-sesman with pid 1693 [20180720-14:15:23] [INFO ] listening to port 3350 on 127.0.0.1

==> xrdp.log <== [20180720-14:16:34] [INFO ] Socket 12: AF_INET6 connection received from ::ffff:127.0.0.1 port 49928 [20180720-14:16:34] [DEBUG] Closed socket 12 (AF_INET6 ::ffff:127.0.0.1 port 3389) [20180720-14:16:34] [DEBUG] Closed socket 11 (AF_INET6 :: port 3389) [20180720-14:16:34] [DEBUG] TLSv1.2 enabled [20180720-14:16:34] [DEBUG] TLSv1.1 enabled [20180720-14:16:34] [DEBUG] TLSv1 enabled [20180720-14:16:34] [DEBUG] Security layer: requested 11, selected 1 [20180720-14:16:34] [DEBUG] Closed socket 12 (AF_INET6 ::ffff:127.0.0.1 port 3389)`

I can't seem to figure it out - Does anyone have any suggestions or does this look like a bug?

Its running on Kali linux, xrdp version is

'ii xorgxrdp 1:0.2.6-1 amd64 Remote Desktop Protocol (RDP) modules for X.org ii xrdp 0.9.6-1 amd64 Remote Desktop Protocol (RDP) server'

Thanks for any help.

Joe.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/neutrinolabs/xrdp/issues/1172, or mute the thread https://github.com/notifications/unsubscribe-auth/ADTH1H3MN-MxK9xcpi5JzYtRa4Wx7-nDks5uIdiVgaJpZM4VYBTR .

-- Idan Freiberg

GPG FP: 8108 7EC9 806E 4980 75F2 72B3 8AD3 2D04 337B 1F18

Hyper200 commented 6 years ago

Hi there,

Thanks for that

The errors are ovbious now, please see below:

[20180720-15:08:36] [INFO ] starting xrdp with pid 2247
[20180720-15:08:36] [INFO ] listening to port 3389 on 0.0.0.0
[20180720-15:08:47] [INFO ] Socket 12: AF_INET6 connection received from ::ffff:127.0.0.1 port 49954
[20180720-15:08:47] [DEBUG] Closed socket 12 (AF_INET6 ::ffff:127.0.0.1 port 3389)
[20180720-15:08:47] [DEBUG] Closed socket 11 (AF_INET6 :: port 3389)
[20180720-15:08:47] [DEBUG] TLSv1.2 enabled
[20180720-15:08:47] [DEBUG] TLSv1.1 enabled
[20180720-15:08:47] [DEBUG] TLSv1 enabled
[20180720-15:08:47] [DEBUG] Security layer: requested 11, selected 1
ssl_tls_print_error: SSL_accept: Failure in SSL library (protocol error?)
trans_set_tls_mode: ssl_tls_accept failed
xrdp_sec_incoming: trans_set_tls_mode failed
xrdp_process_main_loop: libxrdp_process_incoming failed
ssl_tls_print_error: SSL_shutdown: Failure in SSL library (protocol error?)
[20180720-15:08:48] [DEBUG] Closed socket 12 (AF_INET6 ::ffff:127.0.0.1 port 3389)
xrdp_mcs_disconnect - socket closed

Can't see what causes this issue though? i've tried tls_ciphers=HIGH and #tls_ciphers=HIGH with no result.

speidy commented 6 years ago

You might want to look at network capture using wireshark. I think the issue is probably lack of supported ciphersuites that windows allows. I think @kiwao meta@vmeta.jp was saying you the the ephemeral ciphersuites (ECDHE, DHE) to be enabled on the server machine (so xrdp will support them)

what is the server openssl version ?

[image: Mailtrack] https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality5& Sender notified by Mailtrack https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality5& 07/20/18, 5:14:41 PM

On Fri, Jul 20, 2018 at 5:11 PM Hyper200 notifications@github.com wrote:

Hi there,

Thanks for that

The errors are ovbious now, please see below:

[20180720-15:08:36] [INFO ] starting xrdp with pid 2247 [20180720-15:08:36] [INFO ] listening to port 3389 on 0.0.0.0 [20180720-15:08:47] [INFO ] Socket 12: AF_INET6 connection received from ::ffff:127.0.0.1 port 49954 [20180720-15:08:47] [DEBUG] Closed socket 12 (AF_INET6 ::ffff:127.0.0.1 port 3389) [20180720-15:08:47] [DEBUG] Closed socket 11 (AF_INET6 :: port 3389) [20180720-15:08:47] [DEBUG] TLSv1.2 enabled [20180720-15:08:47] [DEBUG] TLSv1.1 enabled [20180720-15:08:47] [DEBUG] TLSv1 enabled [20180720-15:08:47] [DEBUG] Security layer: requested 11, selected 1 ssl_tls_print_error: SSL_accept: Failure in SSL library (protocol error?) trans_set_tls_mode: ssl_tls_accept failed xrdp_sec_incoming: trans_set_tls_mode failed xrdp_process_main_loop: libxrdp_process_incoming failed ssl_tls_print_error: SSL_shutdown: Failure in SSL library (protocol error?) [20180720-15:08:48] [DEBUG] Closed socket 12 (AF_INET6 ::ffff:127.0.0.1 port 3389) xrdp_mcs_disconnect - socket closed

Can't see what causes this issue though? i've tried tls_ciphers=HIGH and

tls_ciphers=HIGH with no result.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/neutrinolabs/xrdp/issues/1172#issuecomment-406612488, or mute the thread https://github.com/notifications/unsubscribe-auth/ADTH1MlCFn2TPyrSjeFLPi8aONzfsaCOks5uIeUSgaJpZM4VYBTR .

-- Idan Freiberg Mobile: +972-52-2925213

Hyper200 commented 6 years ago

Openssl version is: OpenSSL 1.1.0h 27 Mar 2018

I would have thought there must be one supported cipher suite that windows/openssl supported within HIGH?

Does anyone know of one which works with windows and i can try that specific cipher?

metalefty commented 6 years ago

ECDHE-RSA-AES256-GCM-SHA384 is one of supported cipher suites. Can you show me the result of openssl ciphers HIGH ?

Hyper200 commented 6 years ago

:/etc/xrdp# openssl ciphers HIGH ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-CCM8:ECDHE-ECDSA-AES256-CCM:DHE-RSA-AES256-CCM8:DHE-RSA-AES256-CCM:ADH-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-CCM8:ECDHE-ECDSA-AES128-CCM:DHE-RSA-AES128-CCM8:DHE-RSA-AES128-CCM:ADH-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:ECDHE-ECDSA-CAMELLIA256-SHA384:ECDHE-RSA-CAMELLIA256-SHA384:DHE-RSA-CAMELLIA256-SHA256:DHE-DSS-CAMELLIA256-SHA256:ADH-AES256-SHA256:ADH-CAMELLIA256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:ECDHE-ECDSA-CAMELLIA128-SHA256:ECDHE-RSA-CAMELLIA128-SHA256:DHE-RSA-CAMELLIA128-SHA256:DHE-DSS-CAMELLIA128-SHA256:ADH-AES128-SHA256:ADH-CAMELLIA128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:AECDH-AES256-SHA:ADH-AES256-SHA:ADH-CAMELLIA256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:AECDH-AES128-SHA:ADH-AES128-SHA:ADH-CAMELLIA128-SHA:RSA-PSK-AES256-GCM-SHA384:DHE-PSK-AES256-GCM-SHA384:RSA-PSK-CHACHA20-POLY1305:DHE-PSK-CHACHA20-POLY1305:ECDHE-PSK-CHACHA20-POLY1305:DHE-PSK-AES256-CCM8:DHE-PSK-AES256-CCM:AES256-GCM-SHA384:AES256-CCM8:AES256-CCM:PSK-AES256-GCM-SHA384:PSK-CHACHA20-POLY1305:PSK-AES256-CCM8:PSK-AES256-CCM:RSA-PSK-AES128-GCM-SHA256:DHE-PSK-AES128-GCM-SHA256:DHE-PSK-AES128-CCM8:DHE-PSK-AES128-CCM:AES128-GCM-SHA256:AES128-CCM8:AES128-CCM:PSK-AES128-GCM-SHA256:PSK-AES128-CCM8:PSK-AES128-CCM:AES256-SHA256:CAMELLIA256-SHA256:AES128-SHA256:CAMELLIA128-SHA256:ECDHE-PSK-AES256-CBC-SHA384:ECDHE-PSK-AES256-CBC-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:RSA-PSK-AES256-CBC-SHA384:DHE-PSK-AES256-CBC-SHA384:RSA-PSK-AES256-CBC-SHA:DHE-PSK-AES256-CBC-SHA:ECDHE-PSK-CAMELLIA256-SHA384:RSA-PSK-CAMELLIA256-SHA384:DHE-PSK-CAMELLIA256-SHA384:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA384:PSK-AES256-CBC-SHA:PSK-CAMELLIA256-SHA384:ECDHE-PSK-AES128-CBC-SHA256:ECDHE-PSK-AES128-CBC-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:SRP-AES-128-CBC-SHA:RSA-PSK-AES128-CBC-SHA256:DHE-PSK-AES128-CBC-SHA256:RSA-PSK-AES128-CBC-SHA:DHE-PSK-AES128-CBC-SHA:ECDHE-PSK-CAMELLIA128-SHA256:RSA-PSK-CAMELLIA128-SHA256:DHE-PSK-CAMELLIA128-SHA256:AES128-SHA:CAMELLIA128-SHA:PSK-AES128-CBC-SHA256:PSK-AES128-CBC-SHA:PSK-CAMELLIA128-SHA256

Looks like it!

Hyper200 commented 6 years ago

I get the same issue with:

tls_ciphers=ECDHE-RSA-AES256-GCM-SHA384

Hyper200 commented 6 years ago

@speidy

Wireshark isn't really tell me much bar there is a two way connection. Does this suggest it's not negotiation the TLS options yet?

I've also tried with an windows 10 client on the same LAN in case the SSH tunnel was somehow interfering with it.

wireshark11.zip

Hyper200 commented 6 years ago

Does anyone have any other suggestions? I've tried a few things but i'm not really getting anywhere at the moment.

Cheers

Joe.

speidy commented 6 years ago

Can you tell what is your client machine OS version / mstsc version?

Did you try to connect w/o ssh tunnel ?

Hyper200 commented 6 years ago

Hi @speidy

Windows Version: Version 10.0.16299 Build 16299

MSTSC Version attached capture

I have also tried without the SSH tunnel and going directly, no luck.

Cheers

metalefty commented 6 years ago

You should try other clients ex FreeRDP to break down the issue.

Hyper200 commented 6 years ago

@metalefty

FreeRDP is the same, Working when security_level=rdp but not when security_level=tls

metalefty commented 6 years ago

Show the FreeRDP log.

Hyper200 commented 6 years ago

Does freerdp log by default or is there a required switch? - Can't seem to find a log at the moment.

(Using the windows freerdp client)

metalefty commented 6 years ago

UNIX version writes log to the stdout/stderr but Windows version probably doesn't. Anyway, the issue still seems cipher suite issue.

Hyper200 commented 6 years ago

I've tried from fedora 28 using freerdp

[12:19:06:162] [32166:32167] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
[12:19:06:163] [32166:32167] [INFO][com.freerdp.client.x11] - No user name set. - Using login name: mad56570
[12:19:06:215] [32166:32167] [INFO][com.freerdp.crypto] - creating directory /home/mad56570/.config/freerdp
[12:19:06:215] [32166:32167] [INFO][com.freerdp.crypto] - creating directory [/home/mad56570/.config/freerdp/certs]
[12:19:06:215] [32166:32167] [INFO][com.freerdp.crypto] - created directory [/home/mad56570/.config/freerdp/server]
[12:19:06:260] [32166:32167] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_TLS_CONNECT_FAILED [0x00020008]
[12:19:06:260] [32166:32167] [ERROR][com.freerdp.core.connection] - Error: protocol security negotiation or connection failure

Does this tie in with your cipher suite suspecting? If so how do i fix it?

metalefty commented 6 years ago

@Hyper200 can you provide the smallest repro VM ?

Hyper200 commented 6 years ago

I can, leave it with me i'll create a VM - Can you send me an email i'll use OneDrive/Dropbox to send it across.

Cheers

Joe.

metalefty commented 6 years ago

@Hyper200 I'm sorry. I missed that you're waiting for my email and I was waiting for you.
Can you send me the VM to meta@vmeta.jp ?

ivanbaldo commented 6 years ago

Hello. Maybe this info could help or not, but just in case... I tried with Debian Stretch both with XRDP version 0.9.8 (from backports) and 0.9.1. Both using XFreeRDP 2.0.0 and RDesktop 1.8.3. It connects only using plain RDP encryption. Thanks!!!

metalefty commented 6 years ago

@ivanbaldo Your issue is your issue. Maybe you should add xrdp user to ssl-cert group. That is FAQ for Debian users.

metalefty commented 6 years ago

Anyway, no feed back from the reporter more than a month, closing.

ivanbaldo commented 6 years ago

The issue is real, at least on Debian Stretch (current stable). I did add the xrdp user to ssl-cert group and restarted xrdp and sesman. I can give feedback and try almost anything you ask me. Thanks!!!

merrx commented 2 years ago

I know this issue is old and closed, but not resolved. I had the same issue today on only a single computer and found out the culprit was the used ssl certificate (in my case the default snakeoil ssl certificate). The solution was a simple renewal: sudo make-ssl-cert generate-default-snakeoil --force-overwrite

Kofa1 commented 1 year ago

I have the same issue on Arch host and Windows Vista. Working fine on 10 though, but the laptop is too outdated for it. What I get is An authentication error has occurred (Code: 0x80090302) on Vista and Apr 07 16:53:01 archlinux xrdp[2780]: [ERROR] SSL_accept: Failure in SSL library (protocol error?) Apr 07 16:53:01 archlinux xrdp[2780]: [ERROR] SSL: error:0A000102:SSL routines::unsupported protocol Apr 07 16:53:01 archlinux xrdp[2780]: [ERROR] trans_set_tls_mode: ssl_tls_accept failed Apr 07 16:53:01 archlinux xrdp[2780]: [ERROR] xrdp_sec_incoming: trans_set_tls_mode failed by entering systemctl status xrdp.service

guruevi commented 1 year ago

For those still struggling: older packages of XRDP (eg in older distros like Ubuntu Focal Fossa, Debian Bullseye etc) do not support ephemeral certificates due to XRDP hardcoded to look for RSA certificates.

See also: https://github.com/neutrinolabs/xrdp/issues/1776 https://github.com/matt335672/xrdp/commit/ea582429e1d0413c7d53b718419f6a73142dd3c7