TLS/FIPS for Terminal Services and RWW in SBS 2003

Hi David,
 
I had a question about connect to Server desktop through the RWW
 
Two methods to connect in SBS using Terminal Services for Remote Administration
1 - Terminal Services RDP 3389
2 - connect to Server desktop (which uses tsweb through the Remote Web Workplace)
 
In experimenting with SBS Remote Administration I discovered an unusual circumstance in which you CANNOT set the Terminal Services Connection to TLS/FIPS compliant encryption and still access the SBS computer through RWW.
 
So to explain:
*I used Terminal Services Configuration
*loaded a certificate
*in the Terminal Services Connection Properties, General TAB:
**Set Security Layer to SSL
**Set Encryption Level to FIPS compliant
 
NOW... connecting to the SBS server using RWW connect to Server Desktop does not work
 
SOLUTION... in the above walkthrough, change Security Layer to NEGOTIATE. This allowed the RWW session to negotiate it's own encryption level without affecting connections using Terminal Services Client RDP/RDC on 3389 directly. Remote Desktop Connections can still be made over 3389 and they are secure (you see the little lock symbol). With RDP/RDC, the certificate can be viewed and believe RDC 6.0 negotiates highest possible encryption.
 
My question is this:
 
When connecting to Server desktop using RWW, the wrapper indicates there is no encryption what-so-ever. (i.e. No LOCK symbol, no certificate can be viewed, etc...) DOES TSWEB THROUGH THE RWW WEBSITE USE A CERTIFICATE AND NOT INDICATE THAT -OR- DOES IT LAUNCH A CONNECTION ON PORT 3389 FROM THE RWW INTERFACE USING TSWEB, AND!!! IS THIS CONNECTION UN-ENCRYPTED?
 
Thanks,
wigital
 
PS.. made a blog entry on the subject here
http://wintivity.wigital.net/?p=14

PPS.. thanks for the blog post about the live space

Hi,

Things are never as simple as they seem.  You are assuming that there are not some custom written components at work here, which there are.  When I asked internally I was told (para-phrased):

Although  from a client perspective they get the RDP control (same as tsweb), behind the scenes its connecting to our RWW proxy code running within the worker process, thus, the client running on the customer’s browser is not actually ever talking to the RDP server on the destination, there is a layer in the middle. It is probable that this was never part of the design goals.  This should not an issue in the future.

The short answer is that SBS & FIPS for the web RDP client do not mix.

I hope this helps, even if it is not the answer you wanted.

ttfn

David

Thanks David

Yes.. I did assume the use of TSWEB. I figured Microsoft would re-use code and I knew of no other way to access Terminal Services through the browser.

 Thanks for taking the time to call Microsoft. The phone call is way more than I expected. I also appreciate the clarity on the response.

If I understand the implications of your post, even though the logon to RWW is secured using SSL... both the authentication to TS and the TS session that result from using the Connect to Server Desktop link are potentially *quite literally* unsecured (as the wrapper indicates). The question is: does this Proxy session launch some sort of RPC over HTTP type connection outside the context of RWW SSL session? I note (in your reply) that it is invoked using the same worker process but I'm not at all clear if the resulting traffic is still being routed via Port 443 HTTPS and then hitting the Terminal. The client is (after all things) given another logon screen for the Terminal???

Personally, I will be utilizing a direct RDP connection TLS/FIPS instead of RWW to Connect to Server Desktop.

Thanks so much for your excellent response. Nice to meet you BTW

warm regards,
Mark

Mark,

working for Microsoft means that asking the questions is quite easy for me .  Note that the client to the web site is secure and the RDP protcol is not in clear.  TLS cannot be used due to the fact that there is a proxy between the client and the server (RWW).  Information about security can be found at http://technet2.microsoft.com/WindowsServer/en/library/a92d8eb9-f53d-4e86-ac9b-29fd6146977b1033.mspx?mfr=true.

If you are really, really concerned about security and to avoid spoofing, then VPN into the network 1st.  Of, you might find future versions of SBS don't have this problem [;-]

ttfn

David