Up to this commit the client and server state machine handling used
different return values for state machine changes.
This is fixed with this commit:
* Use common enum return values
* Use common helper functions
When transitioning from CONNECTION_STATE_FINALIZATION_FONT_LIST to
CONNECTION_STATE_ACTIVE we must return a value > 0 so that the
state machine can properly initialize the new state.
The demand active state might be called when receiving data from the
client during initial connection phase or might be triggered server
side after sending a deactivate all pdu
* Fixed remdesk settings pointer
* Fixed sign warnings in display_write_monitor_layout_pdu
* Use freerdp_abort_connect_context and freerdp_shall_disconnect_context
* Added and updates settings
* info assert/dynamic timezone
* mcs assert/log/flags
* Fixed and added assertions for wStream
* Unified stream length checks
* Added new function to check for lenght and log
* Replace all usages with this new function
* Cleaned up PER, added parser logging
* Cleaned up BER, added parser logging
* log messages
* Modified Stream_CheckAndLogRequiredLengthEx
* Allow custom format and options
* Add Stream_CheckAndLogRequiredLengthExVa for prepared va_list
* Improved Stream_CheckAndLogRequiredLength
* Now have log level adjustable
* Added function equivalents for existing logger
* Added a backtrace in case of a failure is detected
* Fixed public API input checks
* Implemented missing server side version of PDU (just skip data)
* Refactored read/write functions to properly check stream
length/capacity and handle return values.
* Fix some missing argument checks for function pointer implementations
* Fix broken return value check for client->SendChannelData
* Updated const correctness for function pointer implementations
TPKT header length and consumption of data was not consistently
checked. This adds checks after each packet processed and fixes
any inconsistencies found.
Add server-side management of the licensing workflow. The default
behaviour is to accept the client, but if a server wants to implement
full licensing support as in MS-RDPELE it is possible by defining a callback.
- fixed invalid, missing or additional arguments
- removed all type casts from arguments
- added missing (void*) typecasts for %p arguments
- use inttypes defines where appropriate
This patch make it possible to limit the time that is passed when we call
XXX_check_fds functions. This should smooth the treatment between handling inputs
and handling incoming bitmap updates.
The default maximum time is set to 100 ms.
Shadow server crash with rdp8.0 with gfx enabled.
Root Cause: rdp8.0 is not support in shadow gfx and rdpgfx_caps_advertise returns an error. However setChannelError crashs because context->errorDescription is NULL
1. Fix shadow gfx to handle rdp8.0
2. Initialize context->errorDescription for server side new-context
Sometime it's possible that your server application doesn't have access to files
(when running in a very restricted environment for example). This patch allows
to ship the private key and certificate as a string.
Sponsored by: Wheel Systems (http://www.wheelsystems.com)
rdp_recv_message_channel_pdu always read the rdp security header
even if it was already previously read (which is the case if rdp
security is active)
This caused malfunctions and disconnects when heartbeat or bandwidth
autodetect packets were sent/received in rdp security mode.
Credit goes to @MartinHaimberger for identifying the broken code
part.
1)
Added missing checks for CreateEvent which also required the
following related changes:
- changed freerdp_context_new API to BOOL
- changed freerdp_peer_context_new API to BOOL
- changed pRdpClientNew callback to BOOL
- changed pContextNew callback to BOOL
- changed psPeerAccepted callback to BOOL
- changed psPeerContextNew callback to BOOL
2)
Fixed lots of missing alloc and error checks in the
changed code's neighbourhood.
3)
Check freerdp_client_codecs_prepare result to avoid segfaults
caused by using non-initialized codecs.
4)
Fixed deadlocks in x11 caused by missing xf_unlock_x11() calls
in some error handlers
5)
Some fixes in thread pool:
- DEFAULT_POOL assignment did not match TP_POOL definition
- don't free the pool pointer if it points to the static DEFAULT_POOL
- added error handling and cleanup in InitializeThreadpool
Change the return type of Stream_Ensure*Capacity from void to BOOL to be
able to detect realloc problems easily. Otherwise the only way to detect
this was to check if the capacity after the call was >= the required
size.
In case Stream_Ensure*Capacity fails the old memory is still available
and need to freed outside.
This commit also adds checks to most calls of Stream_Ensure*Capacity to
check if the call was successful.
This patch fixes a bug with mstsc connecting to a RDP security only FreeRDP server.
It seems like the mstsc shipped with Windows Seven considers packets after the nego_failure
packet as an error. So after trying to do TLS, depending on the timing, mstsc can print an
error message instead of retrying to connect with RDP security. With this patch, we
don't send the MCS disconnect message when the negociation has failed.
[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
