full-disclosure - Re: RDP, can it be done safely?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 10 Jun 2010 15:38:23 +0000
From: "Thor (Hammer of God)" <Thor@...merofgod.com>
To: Marsh Ray <marsh@...endedsubset.com>
Cc: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: RDP, can it be done safely?

So, with TSG things are a bit different.  You don't have to have a client cert, but in order to connect to TSG you have to have the MSFT 6.1+ RDP client.  As such, the client can test the server's cert and see if you (the client) trusts it.  If not, you can't connect.

This differs from a "direct" RDP connection where you have a self-signed or private cert configured on the server in that the server has no means of enforcing a trust chain - It just requires the use of the cert on the server side -- the client gets to make the choice of whether to trust the server or not.  

The TSG configuration lets you use self-signed certs (or "private" CA certs), and thus prevent people from connecting if they are not in the trust chain.  But it's not based on a "client cert."

The only exception to this I know of is the current beta of the iTap iPhone RDP client.  It will let you connect to the TSG server without regard to cert trust.  And that's the real distinction here - unless you are using a CLIENT that will enforce a trust, the server-side certificate issuer won't matter.   It's always up to the client to trust the server.  The server can't say "you must trust me" because the client can always just say "OK, I do" even if it really doesn't.

The only way to require an actual client cert (where it "presents" as in your example) is to use something like ISA to publish the SSL connection to the server  - but that will only work with TSWeb services, not the actual TSG services (which I didn't properly explain in my first email - not enough coffee ;).

Make sense?
t

-----Original Message-----
From: Marsh Ray [mailto:marsh@...endedsubset.com] 
Sent: Thursday, June 10, 2010 7:30 AM
To: Thor (Hammer of God)
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: [Full-disclosure] RDP, can it be done safely?

On 6/10/2010 9:10 AM, Thor (Hammer of God) wrote:
> To be specific, it actually doesn't require a "client" cert in the 
> strictest sense.

But I thought it could be configured to require a client cert?

> You can configure certificate parameters on the server in such a way 
> that certificate trust chains must be honored (close enough)

I don't get your meaning here. What cert chains would the server be validating if not client certs? The server's own?

Or are you saying it's still the client's option to not present a client cert?

> but if you want true client authentication based on a certificate, you 
> would have to publish the RDP over RPC/HTTP(s) via something like ISA 
> where you can specifically configure a listener to require client 
> authentication certificates to be "presented" to the publisher, but 
> that's not really the same thing.

I kind of thought we had it configured something like that (but I haven't gotten in too deep yet).

http://technet.microsoft.com/en-us/library/cc731264%28WS.10%29.aspx

Thanks for the heads-up, I'll definitely look at this more closely as I have some projects at work which involve MSTS and TSG.

- Marsh

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/