Nadim here again. Today we’re wrapping up our Top 10 list of RDP Misconceptions. So without further ado…
1) Myth: RDP is insecure; there is no encryption
To be clear, this is totally false! RDP has always supported strong encryption and is by default encrypted!
What has changed over the releases is the type of encryption we offer. The very first versions of RDP back in the Windows 2000 era had encryption that was based on SSL.
As early as Windows 2003 SP1 RDP we decided to introduce full-blown standards-based encryption (i.e. the same SSL as your browser uses to connect to your bank). SP1 did this by introducing standard SSL-encryption as an option.
Current versions of RDP have even stronger encryption and server authentication options out of the box. This is because they are built on top of a security mechanism in Windows called CredSSP which uses Kerberos or TLS (aka SSL) for authentication – when you use those settings RDP is using the same or stronger encryption that your browser uses when communicating with your bank.
2) Myth: RDP performance hasn’t changed much over the releases
False! We’re constantly working to improve RDP performance as well as adding a lot of great functionality to RDP in terms of features.
Every release since Windows 2000 has seen improved perf, i.e. there is a real benefit to upgrading to the latest client and server (e.g. RDP 6.1).
Here’s just one example of the bandwidth difference for a common scenario across several releases of RDP. We essentially have in these scenarios gains of between 8% to 45% bandwidth improvement from switching to the latest protocol. See the RDP Performance Whitepaper for more details on this data.
Going forward - We’re hard at work to continue that trend and bring even better innovations and improved remote experiences – see Asael’s post on some of the future upcoming improvements.
3) Myth: RDP is only used in Remote Desktop Services (formerly TS)
RDP is actually used under the hood in pretty much every Microsoft product that benefits from desktop or application remoting.
Just some examples of products or features you may not have known were built on top of RDP for their remoting needs:
· Remote Assistance
· Windows Media Center Extenders use RDP internally (including Xbox360)
· Windows Live Mesh
· Hyper-V Virtual Machine console
· Office Communications Server 2007 R2
· System Center Configuration Manager (SCCM)
If you’re interesting in seeing how RDP might be able to fit within your application, see the next point...
4) Myth: I can’t customize or program extensions to RDP
There are actually several useful ways to extend/or customize RDP:
· Programming the RDP Client: Host the RDP ActiveX control in your web page or application.
The Remote Desktop client in Windows is a great example of an application that hosts the RDP ActiveX control. This control is fully documented in MSDN. It’s possible for 3rd party software developers to host this control in an app or a web page to provide desktop remoting as part of your larger app.
· Programming the RDP Server side: Use the Windows Desktop Sharing API
This blog post by Seenu has a lot of good detail and examples on how you can use our Windows Desktop Sharing API to write custom collaboration or desktop sharing applications, these APIs are all built on the same core RDP protocol that powers Windows Remote Desktop.
· Write a dynamic virtual channel extension to RDP
Probably the most powerful way to extend RDP is to actually write a virtual channel plug-in extension to RDP. This allows you to extend the protocol with your own bi-directional channel that can communicate from client to server. The possibilities are limitless but some examples include supporting new devices over RDP. We have a nice blog post with an overview of the dynamic virtual channel API or the docs are in MSDN.
5) Myth: The RDP protocol is not publicly documented
If you’re curious to learn more about very low-level technical details of RDP, we have thousands of pages of detailed specifications up on MSDN. For example, you can see the documents for the core protocol sequence and basic graphics here.
I hope this list was useful, if you’ve got any questions or want to provide us with feedback or suggestions for what you’d like to see in RDP we’d love to hear it!
PingBack from http://www.clickandsolve.com/?p=22319
<p>Here is part 2 of the 10 common misconceptions about RDP: </p> <p><a href="http://blogs.msdn.com/ts/archive/2009/03/12/top-10-rdp-protocol-misconceptions-part-2.aspx&quot ...
Cain & Able has done RDP man in the middle for years (not sure what the state is now, but in the 2000 era, it was not secure)
Regrading Myth #4 -
there is no version of the 6.1 Activex available for redistribution.
this means effectively that it is not customizable !
Even I code something that is based on it I can't guarantee my customer actually have it.
Why did Microsoft stop providing the ActiveX itself ?
Or is it hidden in a place I could not find ?
Myth1: Sure, RDP is encrypted, but when you use a static, known key to encrypt, it's might as well be plaintext. As far as I can tell, that's still the default unless you install a certificate.
Why doesn't the RDP management interface make adding a certificate easy, like IIS does? Why doesn't it generate a self-signed certificate on first use, like Exchange 2007 does?
RDP without TLS (added in W2K3 SP1) or CredSSP (added in Vista, and doc'ed in MS-CSSP) does not use a known static key to protect data exchanged between the client and server. Instead, the symmetric key used between the client and server is generated based on random data created by the server and client. MITM attacks exploit the fact that the signing key is known (this exploit was resolved by adding true server authentication with TLS in W2K3 SP1 in 2005). The details of the security exchange are public and available for your review in MS-RDPBCGR section 5.
On the subject of self-signed certificates, beginning with Vista all Terminal Servers generate a self-signed certificate to use by default with TLS or CredSSP protected connections. Take a look at the following registry key to confirm this: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\SelfSignedCertificate. To further confirm, open up the Certificates snap-in and take a look at the machine certificates. You will see a "Remote Desktop" category that contains a self-signed certificate.
A newly installed Vista or later Remote Desktop Host has the default setting of only allowing connections from machines that support NLA (essentially CredSSP) - take a look at the Remote settings UI. This tightens up security, only allowing authenticated users to connect (CredSSP facilitates mutual authentication).
Hope this helps.
thanks for the information, this is great
but is it possible to modify the compression parameter you mentioned in myth#4 for a VDI environment ?
Administrative Templates\Windows Components\Terminal Services\Terminal Server\Remote Session Environment\“Set compression algorithm for RDP data”
this GP does not show up in XP or Vista
I'm trying to use a 3rd party cert from GoDaddy (also tried one from RapidSSL) on my Vista box, but when connecting in from the outside I'm always presented with the self-signed cert. How do I get my Vista host to present its CA cert instead of the cruddy selfsigned one?
Thank you for this great post. You mentioned that by default RDP connections are encrypted (including the username/password exchange).
Can I interperet that as saying all RDP connections/clients require encryption?
Essentially I just want to know if it is possible to establish a successful remote desktop connection while passing credentials over the network in clear text.
Hello! Can one of you RDP Developers please answer an important question of mine: Does RDP need some sort of graphics chipset on the remote machine? In other words, does RDP make any use of the GPU on the remote server in any way, shape, or form?
I am basically asking because I was wondering...if I have a server that has no integrated graphics capability and no video card, would I be able to RDP into this? Would performance be terrible because of the lack of some sort of a GPU? Thanks!