Freerdp: TLSv1 alert internal error

[AdmiralNemo]

I recently upgraded to FreeRDP 1.0.1 after using FreeRDP-old for quite some time, but I am no longer able to connect to any of my servers. They are all Windows Server 2008 R2 with NLA required. Whenever I try, I get the following error:

SSL_read: Failure in SSL library (protocol error?)
SSL_read: error:14094438:SSL routines:SSL3_READ_BYTES:tlsv1 alert internal error

I am using Gentoo Linux, OpenSSL 1.0.0j and FreeRDP git commit 9b6231c08830976abcbcb7cbf536f9c04411ce7f.

On my machine at home, I do not get this error. I tried building with the same environment (OpenSSL 1.0.0h, FreeRDP git commit 7fe240df119dcf585f97e3b696c863b49be44b9a), but still no luck.

What additional information can I provide to find the cause of this problem and hopefully get back to a working FreeRDP installation?

[bmiklautz]

@AdmiralNemo this is an openss library error. I had a similar problem with a self compiled libopenssl 1.0.1c.

Maybe there was a problem with your openssl build on gentoo. Did you try recompiling openssl or to use an older version? Also recheck your use flags (e.g. optimization).

[AdmiralNemo]

Okay, I have done some checking, and I now have two systems with a working FreeRDP install, but the one that counts still doesn't work. On all three systems, OpenSSL was built with the same CFLAGS, etc. variables:

CFLAGS="-O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"

OpenSSL USE flags: kerberos zlib
FreeRDP USE flags: X alsa sse2

On the system that doesn't work, I have tried OpenSSL versions 1.0.0h and 1.0.0j; neither works.
On the two other systems that do work, I have OpenSSL 1.0.0h and 1.0.1c, both of which work.

How can I get more information about what is causing the problem? I tried running inside strace, but nothing helpful is printed.

[bmiklautz]

@AdmiralNemo did you try to build the recent freerdp version from git?

To find out more information it might also help to compile openssl with debug options.

[AdmiralNemo]

Yes, I built FreeRDP again this morning from b6a9937fa13fb5a07671789b23ab3beeb5ba79e6, but it exhibits the same behavior. I just finished an emerge -e openssl to rebuild OpenSSL and all of its dependencies, but that didn't seem to help either.

The OpenSSL ebuild doesn't seem to have a _debug_ USE flag anymore, so I will have to look into building it manually. I'll also try building everything in a chroot and see what that yields.

[AdmiralNemo]

Some progress: while investigating a possible issue related to CA certificates (my company uses an internal CA that signs most RDP certificate), it occurred to me that the problem could also be related to my credentials (in the working environment, I have a relatively short password, but in the nonworking environment, I have a very long password). I did find that although the password length was not the problem, I think the domain name might be.

Here are the results of my tests:

• Using no domain: does not work
• Using domain name softek.local: does not work
• Using domain name SSI: works
• Using domain name pyrocufflink.jazz: works
• Using domain name PYROCUFFLINK: works
• Using (fake) domain name foo: works

(by "works" I mean connects, launches a remote desktop window, and logs in to the remote machine, while by "doesn't work" I mean aborts with the error in the original report)

Note that SSI is the NetBIOS name for softek.local, where PYROCUFFLINK is the NetBIOS name for pyrocufflink.jazz. This behavior is consistent with every machine on the softek.local domain that I have tried, including Windows 7, Windows Server 2008, and Windows Server 2008 R2. These are independent domains (i.e. no trust relationship between them), so there are no machines that would accept both domains.

I guess I can reprogram my hands to type -d SSI instead of -d softek.local, and since I have already removed all of my Remmina configurations during troubleshooting, I can recreate them with that as the domain as well. Still, it does seem like a bug in FreeRDP that I cannot use softek.local, even though I used to be able to and it works from the Windows RDP client.

[freakynl]

Not sure if this is related.

I'm running gentoo too. Been using the latest version marked stable (net-misc/freerdp-1.1.0_pre20121004-r1) as that was the most stable for me so far (tried using -9999 (git build)) several times, but was too unstable.

Anways, today I updated my system. Both openssl slots got updated to 0.9.8y and 1.0.1d respectively.

Freerdp stopped working after this (several other packages were updated to, but I don't think they're related). It just says:

freaky@flaptoppy ~/.freerdp $ rdp srv-ts-01
loading plugin cliprdr
loading plugin rdpdr
connected to srv-ts-01:3389
freaky@flaptoppy ~/.freerdp $

No error, no connection. rdp is a bash file btw, contains this:
freaky@flaptoppy ~/.freerdp $ cat /usr/bin/rdp

!/bin/sh

/usr/bin/xfreerdp /size:1280x960 /cert-ignore -sec-nla +clipboard /v:$@

/usr/bin/xfreerdp -a 24 -g 1280x960 --no-nla --ignore-certificate --gdi hw --plugin cliprdr --plugin rdpdr --data disk:freaky:/home/freaky -- "$@"

Said in #freerdp that -z was still unstable

/usr/bin/xfreerdp -z -a 24 -g 1280x960 --no-nla --ignore-certificate --gdi hw --plugin cliprdr --plugin rdpdr --data disk:freaky:/home/freaky -- "$@"

Tried with git (-9999) build too, that threw errors on SSL but stated it could also be NTLMSSP (NTLMSPP? not sure on what it was called)

[freakynl]

freaky@flaptoppy ~/.freerdp $ ldd /usr/bin/xfreerdp
linux-vdso.so.1 (0x00007fffa996e000)
libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007fe181d92000)
libXinerama.so.1 => /usr/lib64/libXinerama.so.1 (0x00007fe181b8f000)
libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007fe18197b000)
libXcursor.so.1 => /usr/lib64/libXcursor.so.1 (0x00007fe181770000)
libXv.so.1 => /usr/lib64/libXv.so.1 (0x00007fe18156a000)
libfreerdp-core.so.1.1 => /usr/lib64/libfreerdp-core.so.1.1 (0x00007fe181322000)
libfreerdp-gdi.so.1.1 => /usr/lib64/libfreerdp-gdi.so.1.1 (0x00007fe18110a000)
libfreerdp-locale.so.1.1 => /usr/lib64/libfreerdp-locale.so.1.1 (0x00007fe180ee2000)
libfreerdp-rail.so.1.1 => /usr/lib64/libfreerdp-rail.so.1.1 (0x00007fe180cdd000)
libfreerdp-channels.so.1.1 => /usr/lib64/libfreerdp-channels.so.1.1 (0x00007fe180ad7000)
libfreerdp-utils.so.1.1 => /usr/lib64/libfreerdp-utils.so.1.1 (0x00007fe1808c7000)
libfreerdp-cache.so.1.1 => /usr/lib64/libfreerdp-cache.so.1.1 (0x00007fe1806bf000)
libfreerdp-codec.so.1.1 => /usr/lib64/libfreerdp-codec.so.1.1 (0x00007fe1804a8000)
libwinpr-synch.so.0.1 => /usr/lib64/libwinpr-synch.so.0.1 (0x00007fe1802a3000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fe180086000)
libc.so.6 => /lib64/libc.so.6 (0x00007fe17fcde000)
libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007fe17fabd000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fe17f8b9000)
libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x00007fe17f6ae000)
libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00007fe17f4a7000)
libwinpr-sspi.so.0.1 => /usr/lib64/libwinpr-sspi.so.0.1 (0x00007fe17f295000)
libwinpr-registry.so.0.1 => /usr/lib64/libwinpr-registry.so.0.1 (0x00007fe17f090000)
libfreerdp-crypto.so.1.1 => /usr/lib64/libfreerdp-crypto.so.1.1 (0x00007fe17ee7f000)
libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 (0x00007fe17eaac000)
libxkbfile.so.1 => /usr/lib64/libxkbfile.so.1 (0x00007fe17e887000)
libwinpr-crt.so.0.1 => /usr/lib64/libwinpr-crt.so.0.1 (0x00007fe17e682000)
libwinpr-interlocked.so.0.1 => /usr/lib64/libwinpr-interlocked.so.0.1 (0x00007fe17e47f000)
libwinpr-handle.so.0.1 => /usr/lib64/libwinpr-handle.so.0.1 (0x00007fe17e27c000)
libjpeg.so.8 => /usr/lib64/libjpeg.so.8 (0x00007fe17e02a000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe1820d1000)
libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007fe17de26000)
libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00007fe17dc20000)
libssl.so.1.0.0 => /usr/lib64/libssl.so.1.0.0 (0x00007fe17d9b6000)
libwinpr-sysinfo.so.0.1 => /usr/lib64/libwinpr-sysinfo.so.0.1 (0x00007fe17d7b4000)
libwinpr-utils.so.0.1 => /usr/lib64/libwinpr-utils.so.0.1 (0x00007fe17d5b0000)
libwinpr-library.so.0.1 => /usr/lib64/libwinpr-library.so.0.1 (0x00007fe17d3ae000)
libz.so.1 => /lib64/libz.so.1 (0x00007fe17d198000)

[flickerfly]

I found this can occur simply because of an expired password as well.

[bmiklautz]

@flickerfly haven't seen that one ;). Thanks or the hint!

[kiav]

I used /sec:tls to solve the problem.

`$ cat /etc/system-release
ALT Linux 7.0.5 KDesktop (Centaurea Montana)

$ rpm -qa | grep -F openssl
openssl-1.0.1u-alt0.M70P.1

$ rpm -qa | grep -F xfreerdp
xfreerdp-1.1.0-alt1.M70P.1.beta1`

[Karlomanio]

Thanks, this resolved my problem, too.