[MS-RDPBCGR] Section 5.3 describes the encryption level and method values for
standard RDP security.
Looking at the current usage of these values in the FreeRDP code gives me
reason to believe that there is a certain lack of understanding of how these
values should be handled.
The encryption level is only configured on the server side in the "Encryption
Level" setting found in the Remote Desktop Session Host Configuration RDP-Tcp
properties dialog and this value is never transferred from the client to the
server over the wire.
The possible options are "None", "Low", "Client Compatible", "High" and
"FIPS Compliant". The client receices this value in the Server Security Data
block (TS_UD_SC_SEC1), probably only for informational purposes and maybe to
give the client the possibility to verify if the server's decision for the
encryption method confirms to the server's encryption level.
The possible encryption methods are "NONE", "40BIT", "56BIT", "128BIT" and
"FIPS" and the RDP client advertises the ones it supports to the server in the
Client Security Data block (TS_UD_CS_SEC).
The server's configured encryption level value restricts the possible final
encryption method.
Something that I was not able to find in the documentation is the priority
level of the individual encryption methods based on which the server makes its
final method decision if there are several options.
My analysis with Windows Servers reveiled that the order is 128, 56, 40, FIPS.
The server only chooses FIPS if the level is "FIPS Comliant" or if it is the
only method advertised by the client.
Bottom line:
* FreeRDP's client side does not need to set settings->EncryptionLevel
(which was done quite frequently).
* FreeRDP's server side does not have to set the supported encryption methods
list in settings->EncryptionMethods
Changes in this commit:
Removed unnecessary/confusing changes of EncryptionLevel/Methods settings
Refactor settings->DisableEncryption
* This value actually means "Advanced RDP Encryption (NLA/TLS) is NOT used"
* The old name caused lots of confusion among developers
* Renamed it to "UseRdpSecurityLayer" (the compare logic stays untouched)
Any client's setting of settings->EncryptionMethods were annihilated
* All clients "want" to set all supported methods
* Some clients forgot 56bit because 56bit was not supported at the time the
code was written
* settings->EncryptionMethods was overwritten anyways in nego_connect()
* Removed all client side settings of settings->EncryptionMethods
The default is "None" (0)
* Changed nego_connect() to advertise all supported methods if
settings->EncryptionMethods is 0 (None)
* Added a commandline option /encryption-methods:comma separated list of the
values "40", "56", "128", "FIPS". E.g. /encryption-methods:56,128
* Print warning if server chooses non-advertised method
Verify received level and method in client's gcc_read_server_security_data
* Only accept valid/known encryption methods
* Verify encryption level/method combinations according to MS-RDPBCGR 5.3.2
Server implementations can now set settings->EncryptionLevel
* The default for settings->EncryptionLevel is 0 (None)
* nego_send_negotiation_response() changes it to ClientCompatible in that case
* default to ClientCompatible if the server implementation set an invalid level
Fix server's gcc_write_server_security_data
* Verify server encryption level value set by server implementations
* Choose rdp encryption method based on level and supported client methods
* Moved FIPS to the lowest priority (only used if other methods are possible)
Updated sample server
* Support RDP Security (RdpKeyFile was not set)
* Added commented sample code for setting the security level
The fOpRedundant field of the GlyphIndex primary drawing order
(MS-RDPEGDI, chapter 2.2.2.2.1.1.2.13) was neglected which resulted in some
severe text rendering errors.
With BOOL as return type it is not possible to differentiate between
success and "no data can be read" (when a channel read would block).
rdpsnd_server_handle_messages returns now int with the following
possible values:
-1 if no data could be read
0 error (like connection close) (formerly FALSE)
1 succsess (also if further bytes need to be read) (formerly TRUE)
Not using -1 for error cases was chosen to be compatible with the BOOL
return values used before.
MS-RDPEA 2.2.2.3 states (Appendix A <6>) that quality mode PDU
should be ignored if the client version is < 6. For these clients the sound
channel got never activated since activated was only called after
reception of the quality mode PDU.
For clients < version 6 activated is now called after
CLIENT_AUDIO_VERSION_AND_FORMATS was received.
Conflicts:
channels/drdynvc/client/dvcman.c
include/freerdp/codec/h264.h
libfreerdp/codec/h264.c after this merge h264 doesn't work anymore!!
libfreerdp/utils/svc_plugin.c
Fixes clang compiler warning:
"warning: the value of the size argument in 'strncat' is too large,
might lead to a buffer overflow [-Wstrncat-size]"
strncat requires an extra byte for '\0' so dest needs to have a size of
n+1
CLRCONV_INVERT and/or CLRCONV_ALPHA is set.
* include/freerdp/codec/color.h (RGB32_to_BGR32): New inline function.
* libfreerdp/codec/color.c:
(freerdp_image_convert_24bpp): Fix CLRCONV_ALPHA and CLRCONV_INVERT
processing for 32bpp destination.
Unroll the conversion loop to process four pixels in one go using
32-bit load and store operations.
(freerdp_color_convert_drawing_order_color_to_gdi_color): Declare new
function.
* libfreerdp/codec/color.c:
(freerdp_color_convert_drawing_order_color_to_gdi_color): Implement.
(freerdp_image_convert_8bpp): Properly use the ARGB32/ABGR32/RGB32/BGR32
macros when converting 8bpp data to 32bpp.
(freerdp_image_convert_32bpp): Fix CLRCONV_ALPHA and CLRCONV_INVERT
processing for 32bpp destination.
(freerdp_mono_image_convert): Use ARGB32/ABGR32 when converting to 32bpp
and CLRCONV_ALPHA is set.
* libfreerdp/core/orders.c: Color data from drawing orders is
interpreted in big endian mode.
* libfreerdp/core/update.c (update_read_palette): Likewise.
* libfreerdp/gdi/16bpp.c (gdi_get_color_16bpp): GDI colors are stored as
RGB now.
* libfreerdp/gdi/32bpp.c (gdi_get_color_32bpp): Likewise.
* libfreerdp/gdi/gdi.c:
Use freerdp_color_convert_drawing_order_color_to_gdi_color() to convert
from drawing order color representation to GDI color representation
troughout.
* libfreerdp/gdi/graphics.c (gdi_Glyph_BeginDraw): Likewise.
(gdi_Glyph_EndDraw): Likewise.
This adds 2 arguments:
/tls-ciphers List of permitted openssl ciphers - see ciphers(1)
/tls-ciphers-netmon Use tls ciphers that netmon can parse
With KB2919355, client/server negotiate the use of
TLS cipher TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
which works fine except that netmon can't parse it.
By adding commandline /tls-ciphers-netmon, we restrict
the available ciphers to a list that netmon can
deal with. Also adds /tls-ciphers, which
accepts a string arg, for further customization.
# By Marc-André Moreau (20) and others
# Via Mike McDonald (6) and others
* 'master' of git://github.com/awakecoding/FreeRDP: (26 commits)
libfreerdp-codec: fix C++ headers
libfreerdp-codec: fix ClearCodec short vbar cache hit
libfreerdp-codec: improve ClearCodec error checking
libfreerdp-codec: fix ClearCodec RLEX decoding
libfreerdp-codec: ClearCodec fix error codes and wrapping around of cursors
libfreerdp-codec: fix some ClearCodec flag checking
Fixed issue with last merge.
Added #ifdef WITH_OPENH264 ... #endif to appropriate places in the code.
libfreerdp-codec: handle long vbar length mismatch
channels/rdpgfx: add egfx command line options and settings
libfreerdp-codec: reduce number of variables
libfreerdp-codec: improve ClearCodec robustness
libfreerdp-codec: simplify ClearCodec code
Initial implementation of H.264 decoder for MS-RDPEGFX
libfreerdp-codec: improve ClearCodec subcodec xStart, yStart handling
libfreerdp-codec: improve ClearCodec subcodec support
libfreerdp-codec: improve ClearCodec error checking
libfreerdp-codec: more ClearCodec vBar caching
channels/rdpgfx: harden parsing code
libfreerdp-codec: add ClearCodec glyph cache
...
