Note that with Low Encryption set; only packets from client to server are
encrypted. Packets from server to the client are not.

This is also documented here:

Low encryption encrypts only packets being sent from the client to the
Terminal Server. This "input only" encryption is to protect the input of
sensitive data like a user's password.
http://technet2.microsoft.com/windowsserver/en/library/2cb5c8c9-cadc-44a
9-bf
39-856127f4c8271033.mspx?mfr=true

This is the reason why I don't use "Low" or "Client compatible" settings.

Mike

-----Original Message-----
From: listbounce (at) securityfocus (dot) com [email concealed] [mailto:listbounce (at) securityfocus (dot) com [email concealed]] On
Behalf Of Wayne S. Anderson
Sent: Friday, January 25, 2008 4:05 PM
To: 'Wozny, Scott'; focus-ms (at) securityfocus (dot) com [email concealed]
Subject: RE: Under the hood question about Remote Desktop Connection

By default, there are three settings in a non-FIPS, non-TLS environment:
Low, High, and Client Compatible. Low is encrypted with 56-bit RC4, High is
encrypted with 128-bit RC4 (or TLS if configured). Client compatible
selects the highest supported level of encryption between the two. Just so
you know, by default you are usually using 128 bit RC4 in a homogenous
Windows XP / Server 2003 environment. With RDP 5.2 and later (XP, Server
2003, Vista, Server 2008), you can set the encryption to use TLS 1.0 with
certificates. This should solve any concern about key exchange by ensuring
your local infrastructure adopts an accepted standard.

There are other solutions, of course, including implementing IPSec so that
administrators are running RDP and other sensitive sessions over IPSec
channels, thereby circumventing the issue of RDP encryption integrity
completely but for obvious reasons, the performance and maintainability is
going to be significantly in favor of simply using TLS if this is really a
concern.

Windows Server 2003
Client-Based Encryption Config:
http://technet2.microsoft.com/windowsserver/en/library/cdfe9f76-fb54-46f
e-84
c0-7cf637dc65be1033.mspx?mfr=true
Server-Based Encryption Config:
http://technet2.microsoft.com/windowsserver/en/library/a92d8eb9-f53d-4e8
6-ac
9b-29fd6146977b1033.mspx?mfr=true
http://technet2.microsoft.com/windowsserver/en/library/8be5bfb5-b652-49a
a-8a
c4-f6c2b01f35101033.mspx?mfr=true

Windows Server 2008
Server-Based Encryption Config:
http://technet2.microsoft.com/windowsserver2008/en/library/9a86af81-c87e
-41f
2-bdec-b154d896a8821033.mspx?mfr=true

There is one other thing that I think you may want to pay attention to,
there are some things in any RDP session which are, by default, not
encrypted. For XP or 2003 based sessions, there is a KB article which
reviews these elements: http://support.microsoft.com/kb/275727

This documentation is not yet fully available for RDP 6.0 which is used in
Vista and Windows Server 2008.

-W

Wayne S. Anderson
http://www.linkedin.com/in/wayneanderson

-----Original Message-----
From: listbounce (at) securityfocus (dot) com [email concealed] [mailto:listbounce (at) securityfocus (dot) com [email concealed]] On
Behalf Of Wozny, Scott
Sent: Thursday, January 24, 2008 12:20 PM
To: focus-ms (at) securityfocus (dot) com [email concealed]
Subject: Under the hood question about Remote Desktop Connection

Doing some poking around in the list archives and some sites on the net, I
see how one can require remote connections to use 128-bit RC4 encryption. 
Setting aside the debate on whether or not this algorithm qualifies as
secure or insecure, this is a symmetric algorithm.  As sending the key in
the clear would be a major faux pas, does anyone know what mechanism this
app uses to do secure key exchange?  Does it just "borrow" a browser cert to
do a DH exchange?
 
Any insights would be appreciated.
 
Thanks,
 
Scott
 

0? *?H?÷

 ?0?

10 +0? *?H?÷


 ?Ù0?=0?
¦ͺVðßä¼Tþ"¬³rªU0
 *?H?÷


0_10 UUS10U
VeriSign, Inc.1705U.Class 1 Public Primary Certification Authority0
960129000000Z
280801235959Z0_10 UUS10U
VeriSign, Inc.1705U.Class 1 Public Primary Certification Authority0?0
 *?H?÷



0?å¿m£Va-?HqögÞ¹ë·???
?ú8%¯F??ås¨ ?$]
Ìen°ÐV????¡sß´X9knÁöÕ¨¨?ª1¬°4׏4g? ÍâNEVix?ÚÜG?)»6Éc\Åà×-?{¡·2°{0º*/1ªî£gÚÛ

0
 *?H?÷


L?¸?ÆhßîC3]é¦Ë?Mz3ÿ?ô6­Ø?"6hl|BÌó?.Ä?°Oÿ?vùâ¼JéÍ ?
÷Å)ñ?"]¸±Ý#£{%F0yøêK?ÂÈã·ô@<Ã_SèHä?´{¡5°{%º¸Ó?«?84?óÑq?0?Ä0?
¬ 
}Ì<¹Zµ*)\üæku7ë0
 *?H?÷


0Ý10 UUS10U
VeriSign, Inc.10UVeriSign Trust Network1;09U2Terms of use at https://www.verisign.com/rpa (c)0510UPersona Not Validated1705U.VeriSign Class 1 Individual Subscriber CA - G20
080113000000Z
090112235959Z0?
10U
VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. by Ref.,LIAB.LTD(c)9810UPersona Not Validated1402U+Digital ID Class 1 - Microsoft Full Service10UMiha Pihler1!0 *?H?÷


miha.pihler (at) snt (dot) si0 [email concealed]?0
 *?H?÷



0??ë±|GÇ9+?J ;DPá{)$M9?Ïn¼Ø#¤%÷«?þõãà?Á­?_« öÉLbç=Ô²?Q/¦Ð",
%C?¼îþ¶¾^ôCG©º¾?ÞôÙÛ
©·3SäAWÌ÷ñU{µüCgî?ZL?Þ:°È6Ôm£

£Ì0É0 U00DU =0;09`?H
?øE
0*0(+

https://www.verisign.com/rpa0U
 0U%0+
+
0JUC0A0? = ;?9http://IndC1Digita
lID-crl.verisign.com/IndC1DigitalID.crl0
 *?H?÷


?

?(5Q´$6ށé:[QªpØuðcóÜÝå>??tÚ?J·W?4æÈ?µbH}?$!
¨+³rJâ<P? ¨©
ÅÞTÌ^HðûÁ?²×ß)$äI%Ó©O?#²O°UX??õvÆN^¬­,©+¼oµ?T:ÉCh7ùçîºï,hìS%9ú\O?c?Ü}È?l{û1ÌølÂ$?UI5·$]7Oâ&Ï?Ì'?úüº?ù>äÑ_6JâûÏ
|
I4$?3?ÏUÙ½'Õ·?ç¬Áí wûZÈ2Ð`Ð+ñ¾GåÒªÆ0¼<wK0?Ì0?5 
®k
?ôæ/"?£Útal0
 *?H?÷


0_10 UUS10U
VeriSign, Inc.1705U.Class 1 Public Primary Certification Authority0
051028000000Z
151027235959Z0Ý10 UUS10U
VeriSign, Inc.10UVeriSign Trust Network1;09U2Terms of use at https://www.verisign.com/rpa (c)0510UPersona Not Validated1705U.VeriSign Class 1 Individual Subscriber CA - G20?
"0
 *?H?÷



?
0?

?

É߬çêøøÄ?ÕÁ~6Â<ï|rËÀ«?=?Îo,?í?&æ¶Çæ­C?¤?GGL>TøløÇü±?½0p¼?±ê
?ñ­@ÅDzK¢ò`ü×:ebïÿ{¢V»ÅNp-Ö¢<í°Bè^W!¬¦?ÙéÒÀtGBüÅ4êýæº$Ñ7¢×sÏ

A/c²:?¾¥nôÉJ[=?¦»5ùÔ／qvY»K¶>ÖüZôÖ?òIþlíéÙ?u?yÎ`'ݹ­uÎ/s?z@:?uI°¸ßh¼«Í??P£à<®À
SÍ×0o?2FäIÂlâ¯yÿÛ´µ

£?
?0?
?0U

ÿ0

ÿ
0DU =0;09`?H
?øE

0*0(+

https://www.verisign.com/rpa0U

0 `?H
?øB


0.U'0%¤#0!10UPrivateLabel3-2048-1550U
}^}<ßjlÖ¢??1Ø;?R01U*0(0& $ "? http://crl.verisign.com/pca1.crl0U#z0x¡c¤a0_10 UUS10U
VeriSign, Inc.1705U.Class 1 Public Primary Certification Authority?ͺVðßä¼Tþ"¬³rªU0
 *?H?÷


±/Ù?á?¢î`åÈ* ûág,Ö?S£éKøD?F÷ú þÓ£Ò¿ìÖ?JMCøÊ»¾?IÝ!s3WÂBZ¾ú?²æ1?N]<ðs7cë¿?
Y?ýfÞé?2??)<:®TÚ¦Q±ÈÊÓGxæÛ¥?ãÑÀÂ!öº1?Ä0?À

0ò0Ý10 UUS10U
VeriSign, Inc.10UVeriSign Trust Network1;09U2Terms of use at https://www.verisign.com/rpa (c)0510UPersona Not Validated1705U.VeriSign Class 1 Individual Subscriber CA - G2}Ì<¹Zµ*)\üæku7ë0 + ?'0 *?H?÷

1 *?H?÷


0 *?H?÷

1
080127193607Z0# *?H?÷

1IÆã?.8ÕÿÛF/hãìxGÔ0· *?H?÷

1©0¦0 `?H
e
*0 `?H
e
0
*?H?÷
0 `?H
e
0*?H?÷
?0
*?H?÷

@0+0
*?H?÷

(0+0 `?H
e0 `?H
e0 `?H
e
0
*?H?÷
0?
 +

?71õ0ò0Ý10 UUS10U
VeriSign, Inc.10UVeriSign Trust Network1;09U2Terms of use at https://www.verisign.com/rpa (c)0510UPersona Not Validated1705U.VeriSign Class 1 Individual Subscriber CA - G2}Ì<¹Zµ*)\üæku7ë0?
*?H?÷

1õ ò0Ý10 UUS10U
VeriSign, Inc.10UVeriSign Trust Network1;09U2Terms of use at https://www.verisign.com/rpa (c)0510UPersona Not Validated1705U.VeriSign Class 1 Individual Subscriber CA - G2}Ì<¹Zµ*)\üæku7ë0
 *?H?÷



?B?¡FÏZ>?:P¿?¨ªC
p%W 1A;ÔÑ?2"B?Ò´P) ?f´8̬Ý÷æÍ?Ï -§«.8Ë?e0
L"ÍV½RÕfÞI¥ôèhéVO¶=ì
L{ 9ü?a×cáª4íXó 8Sz\Ü;U0¼÷?rs¯?

[ reply ]