Can you please run it with SETH_DEBUG=1 ./seth.sh ... and post the output?

Please have a look, thanks!

[] Spoofing arp replies...
[] Turning on IP forwarding...
[] Set iptables rules for SYN packets...
[] Waiting for a SYN packet to the original destination...
[+] Got it! Original destination is 10.0.0.87
[] Clone the x509 certificate of the original destination...
[] Adjust the iptables rule for all packets...
[*] Run RDP proxy...
Warning: The python3 module 'hexdump' is missing. Using hexlify instead.
Listening for new connection
Connection received from 10.0.0.164:58030
From client:
030000130ee00000000000010008000b000000
Downgrading authentication options from 11 to 3
From client: (modified)
030000130ee000000000000100080003000000
Listening for new connection
From server:
030000130ed000001234000209080002000000
Enable SSL
From client:
3037a003020105a130302e302ca02a04284e544c4d5353500001000000b78208e2000000000000000000000000000000000601b11d0000000f
From server:
30820119a003020105a18201103082010c30820108a0820104048201004e544c4d53535000020000001000100038000000358289e2b331b7424249a4ba0000000000000000b800b800480000000601b11d0000000f560045004e0045005400490041004e0002001000560045004e0045005400490041004e00010014005600490054004400540052004d0037003900320004001e00760065006e0065007400690061006e002e0063006f006d002e006d006f00030034005600490054004400540052004d003700390032002e00760065006e0065007400690061006e002e0063006f006d002e006d006f0005001e00760065006e0065007400690061006e002e0063006f006d002e006d006f0007000800b47e54e5f4f7d30100000000
Connection lost

Hmmm everything looks fine. I increased verbosity with the latest commit. You could pull it and try again to see what it says.

Also you may want to redact that last hex string. It contains the host name of your server.

Thanks Adrian.
The new version output "Connection lost ([Errno 104] Connection reset by peer)".

Any possibility that the client validate the certificate (although the original is untrusted as well), and find out that the cloned certificate is not valid?

No, because the SSL connection is successfully established and data is exchanged after the SSL handshake. For whatever reason the server closes the connection right before authentication. Unfortunately I'm clueless at this point.

You could try running it with SETH_DOWNGRADE=1 ./seth.sh ... or use the fake server mode. To always enable the fake server mode you have to modify seth.sh and replace seth.py with seth.py -f in line 136. However, I haven't tested this. I should implement an easy switch for that.

Anyway, thanks for reporting.

Actually, you may have been right. See http://fixmyitsystem.com/2011/08/rdp-rds-unexpected-server.html

I'll have to come up with something

If I force the SETH_DOWNGRADE=1 or the using of the fake server with "seth.py -f, then a new failure occurs:

Listening for new connection
'NoneType' object has no attribute 'getsockopt'
Hiding forged protocol request from client
Connection lost on run_fake_server