Have had an attempt at a patch, but I'm not sure exactly what needs to be changed to make it safe.  Here is the conversation I had with upstream:

On 27/01/11 23:42, Mads Kiilerich wrote:
> > On 01/27/2011 04:51 AM, Robert Ancell wrote:
>> >> Hi FreeRDPers!
>> >>
>> >> I'm currently trying to get Remmina/FreeRDP as the default on
>> >> the Ubuntu 11.04 CD, but our pesky security team wants the
>> >> certificate checking to work:
>> >>
>> >> RD_BOOL crypto_cert_verify(CryptoCert server_cert, CryptoCert
>> >> cacert) { /* FIXME: do the actual verification */ return True; }
> >
> > I assume this is from crypto_openssl.c and that you don't care
> > about other crypto backends. Ok.
> >
> > This function is only used to verify the individual links in the
> > x509 certificate chain is correct. That alone is far from enough.
> > Note however that this part works with the gnutls backend.
> >
> > Finally (so far) there is the tls option. libfreerdp/tls.c (which
> > so far only works with openssl) is far more complete but still not
> > completely finished.
> >
>> >> So the question is: - - Any chance of this working by the end of
>> >> February? - - Any plans for this? - - If you guys haven't got
>> >> plans, I'll work on a patch. I'm not an expert at certificate,
>> >> do I just need to pass the information to the GUI and let the
>> >> user ACK/NACK it?
> >
> > AFAIK there are no specific plans and no chance unless somebody do
> > something.
> >
> > I think FreeRDP is quite stable and reliable on local trusted
> > networks, but I wouldn't recommend using it on untrusted networks
> > or when connecting to untrusted servers. FreeRDP security in these
> > (and other) areas is definitely not worse than rdesktop (which I
> > assume is the only alternative).
> >
> > It would be great if you could work on improvements in this area.
> >
> > A brief description of some aspects of a good solution could be: *
> > options for warning/accepting/failing on "Proprietary Certificate"
> > * more common handling of certificates for tls and non-tls *
> > support more crypto backends for tls (and nla) (but focusing on
> > openssl first is fine) * checking that the server certificate
> > matches the request hostname * functionality for checking that the
> > x509 chain can be validated with the systems CA certificates
> > (probably only useful in very few setups) * functionality for using
> > other CA certificates (so you can add your local AD CA and
> > automatically trust all servers on the domain regarding rdp without
> > adding it to the global configuration) * ssh-like "known host"
> > functionality, asking "unknown host X shows certificate Y - trust
> > it and store it to next time?", adding it to some "known_hosts"
> > file and using it next time and failing/prompting if it doesn't
> > match next time
> >
> > It will require changes to both libfreerdp and xfreerdp and will
> > thus also require a so version bump.
> >
> > Not a trivial task ... It might make sense to focus on "known
> > host" and ignore the PKI mess. That might bring you most of the way
> > to what you want.
> >
> > /Mads
Hi Mads,

Thanks for the information.  Yes, we would be switching from rdesktop
(which is a support problem).

I've had a first attempt at getting something working.

Firstly, I'm using the rdp_mitm server to connect to.  I couldn't work
out how to get a secure RDP server to work in Linux.  Attached patch
fixes the build system for this.

The second patch is to add a callback in the freerdp API so that RDP
clients can prompt the user.

Some questions:

- - I figure the API needs to provide the security state of the
connection (unsecured, secured with unknown/invalid certificate,
secured with valid certificate).  Please let me know if this is
heading in the direction you expect.

- - There are two encryption schemes here right?  One for the whole
channel (TLS) and one inside the RDP protocol (MCS?).  Is TLS the
newer method and MCS? the legacy method?

- - Any thoughts on how to provide certificate contents to the user for
them to decide if a certificate is valid / should be added to the list
of accepted certificates?  This seems difficult to provide due to the
number of different crypto backends (i.e. no shared certificate class).

Thanks,
- --Robert