I have a suggestion regarding certificate validation:
Looking at mstsc.exe, it appears to me that the certificate validation is
delegated to a module dedicated just to that. If we let the UI handle it
with a callback, maybe we could provide the UI with a library that can
handle it? This way, for instance, a system with both xfreerdp and
dfbfreerdp wouldn't need to have separate certificate validation.
Information could be stored in ~/.freerdp
On Tue, Mar 8, 2011 at 10:07 AM, Mads Kiilerich <m...@kiilerich.com> wrote:
> On 02/08/2011 07:01 AM, Robert Ancell wrote:
> > I've had a first attempt at getting something working.
>
> Thanks for the patches. Unfortunately it seems like everybody has been
> too busy to be scalable and efficient and review contributions ...
>
> > 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.
>
> That tool wasn't really supported and has been removed.
>
> > The second patch is to add a callback in the freerdp API so that RDP
> > clients can prompt the user.
>
> Some general comments:
>
> If we extend the API with a ui_check_certificate method it should be
> mandatory - there shouldn't be any particular need for checking if it is
> NULL. But it should also be implemented in win/wfreerdp/.
>
> I get segmentation fault when l_ui_check_certificate returns False. It
> seems like the connection isn't "sufficiently terminated".
>
> The changes in secure.c seems to violate some layering, but I'm not sure
> how that should be solved. Others might have an opinion on that.
>
> > 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.
>
> The way I see it there are two different ways a host can be verified.
>
> One way is that the user somehow (implicitly or explicitly) tells the
> crypto library which CAs should be trusted, and FreeRDP then makes sure
> the server host certificates are signed by one of these (possibly by
> chain of trust).
>
> The other way is that the server presents a certificate that can't be
> validated by any CA. FreeRDP can then ask the UI if the certificate is
> OK anyway. The UI can ask the user, and the UI may store the decision in
> a database so it can answer on the users behalf next time.
>
> ( My reference for how that can be done in a slightly different
> architecture is http://hg.intevation.org/mercurial/crew/rev/8dc488dfcdb4.)
>
> The UI shouldn't need to have any crypto awareness, so I think the
> check_certificate callback to the UI should have the following parameters:
> * flag, one of
> ** got certificate - what to do
> ** certificate passed validation by CA
> ** certificate validation by CA failed
> ** certificate validation failed - expired or doesn't match server
> * servername (as requested by the user or redirected to)
> * certificate fingerprint (uint8[20] with sha1 of public certificate DER)
> * textual decoding of public certificate (20+ lines as returned by
> crypto_cert_print_fp ... or something similar)
> * perhaps the raw DER certificate so the user can analyze it further
> with crypto tools
> The return value could be
> * go ahead and accept the connection
> * try again with this CA (which also is returned somehow) and call back
> * rejected - terminate the connection ASAP
>
> I think such an API would give reasonable flexibility and functionality.
> What do GUI writers such as Vic say?
>
> Obviously the connection must either be verified as the user specified
> or rejected. I don't think it matters after the fact how it was verified
> and I don't see the point in storing sec->verified.
>
> > - - 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?
>
> Correct. TLS works with some servers and the old way must be used when
> connecting to other servers, so both must be implemented.
>
> We don't have a good name for "the old way" that uses "Server
> Proprietary" or X.509 certificates.
>
> > - - 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).
>
> Correct. So far the TLS/NLA only works with OpenSSL and doesn't use the
> plugable crypto modules secure.c uses. I think it would be OK if we
> focus on OpenSSL here too, but keep in mind that it also should be
> possible to make it work with other crypto backends in the future.
>
> /Mads
>
>
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> Freerdp-devel mailing list
> Freerdp-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freerdp-devel
>
------------------------------------------------------------------------------
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
_______________________________________________
Freerdp-devel mailing list
Freerdp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel
