[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
xf_cliprdr_process_selection_notify calls xf_cliprdr_send_client_format_list
if the SelectionNotify event property was None.
xf_cliprdr_send_client_format_list called XConvertSelection even if there
was no clipboard owner. In that case the XServer generates a SelectionNotify
event to the requestor (us) with property None and so on ...
The most obvious fix is to ensure that XConvertSelection is not called if
the owner is None which is done in this commit.
In case of server side initiated desktop resize it could happen that the
client was "scaling" even if smart-sizing was disabled. The reason for
this was that the "scaled" width and height was set when the X Configure
event arrived but not in xf_desktop_resize.
* fixed crash on server-initiated desktop resize and fullscreen toggle with /gdi:sw
* implemented desktop resize for /gdi:sw
* check for availibility of XRender extension and show error messages if a setting would require it
* fixed compile error if xrender devel packages are missing
* fixed bug with server-initiated desktop resize in fullscreen mode
Most of xfreerdp's hw gdi callbacks did the the same X11 drawing operation
twice: Initially on the primary pixmap to keep the back buffer up to date
and then directly on the window in order to see the result.
This sequence is followed by a call to gdi_InvalidateRegion() to mark the
rectangular area of the drawing operation.
Since in xfreerdp's current design (or better current evolved state) the
backbuffer pixmap is obligatory, all drawing operations directly targeting
the window are redundant because of the subsequent EndPaint (mapped to
xf_hw_end_paint) where the damaged region is copied from the backbuffer
to the drawable.
- removed X11 drawing operations which directly target the window drawable
- fixed some errors in the calculation of the required update regions
This commit does the following:
* fix the keyboard logic (which now fully works), add support for vertical mouse wheel events ;
* make the rendering a lot more efficient, by using RDP damage information to refresh only the relevant part of the buffer ;
* fix two race conditions. wlfreerdp should not crash anymore now ;
* fix shm_open() and shm_unlink() calls ;
* improve the code style.
Signed-off-by: Manuel Bachmann <tarnyko@tarnyko.net>
Added a condition to redraw a rect only when region is invalidated. For
example. this avoids a redraw when only the cursor changes on the
remote machine.
We split the one massive source file into multiple separate
source files and headers, just like it is done for other
clients.
We add a new "wlfInput" interface which will try to
initialize mouse and keyboard at startup. Mouse inputs
already work, keyboard inputs need further investigation.
Signed-off-by: Manuel Bachmann <tarnyko@tarnyko.net>
X11 gdi polyline has been broken by commit 3de5c62.
We don't need to convert the point coordinates if XDrawLines is called with
coordinate mode CoordModePrevious.
Also Use ANDROID_APP_TARGET_SDK for application compatibility project.
It is now automatically set/updated during build.
Note: The ANDROID_APP_TARGET_SDK version need to be larger or equal to the
version required by the used Android support library (appcompat).
Marc-André Moreau