Allow password to be stored in .RDP file and parsed and settings
updated, this will allow for dynamic .RDP files to be created with
complete login credentials, using this method the username, server and
password will no longer be visible within process lists.
Also fixed issue of username and domain being read from .RDP files and
set to null by command line processor.
- fixed invalid, missing or additional arguments
- removed all type casts from arguments
- added missing (void*) typecasts for %p arguments
- use inttypes defines where appropriate
Extend winpr and client/common to support a new option "/buildconfig".
When used build the following build specific information is print:
* cmake options
* cflags
* compiler
* target architecture
* cmake build type
In case the old behaviour of not reverse-mapping the mouse buttons is
desirable, a command-line option is added to disable the mapping. This
option is made experimental for the time being.
The default is to do the reverse mapping, as this is the intuitive
behaviour (the mouse then works as it would on the console).
This patch contains:
* checks for malloc return value + treat callers;
* modified malloc() + ZeroMemory() to calloc();
* misc fixes of micro errors seen during the code audit:
** some invalid checks in gcc.c, also there were some possible
integer overflow. This is interesting because at the end the data are parsed
and freed directly, so it's a vulnerability in some kind of dead code (at least
useless);
** fixed usage of GetComputerNameExA with just one call, when 2 were used
in misc places. According to MSDN GetComputerNameA() is supposed to return
an error when called with NULL;
** there were a bug in the command line parsing of shadow;
** in freerdp_dynamic_channel_collection_add() the size of array was multiplied
by 4 instead of 2 on resize
+ add: COMMAND_LINE_IGN_UNKNOWN_KEYWORD flag for CommandLineParseArgumentsA to ignory unknown keys without fail
+ add: lot of WLog_DBG() in drdynvc, add function names in existing
* change: error text in rdpsnd OSS
* fix: dev in rdpsnd does not work
* fix/change: audio-dev renamed to dev and now work in audin
* fix dynamic channels now work again
[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
1.0 had the ability to specifiy window geometry by a percentage.
The support is still there, just needed command line support.
Example in 1.1 syntax: /size:85%
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.
This patch changes the prototype for decode_base64 so that the encode / decode
method are consistant (encode(BYTE *) => char* and decode(char*) => BYTE*).
It also does some improvements with unrolling loops so that end conditions are
tested only at the end.
The patch also adds some unitary tests.
Before the patch base64_decode() made valgrind complain about uninitialized
bits, after valgrind is happy and very quiet.
- fixed invalid stream position if extEncryptionMethods is not used
- enabled 56bit rdp security method
- fixed entropy reduction of the keys for 40 bit and 56 bit
- added rdp security incl. FIPS for fastpath output
- added FIPS encryption to fast path input
- fixed FIPS key generation in server mode
- fixed stream length correction in FIPS mode
- added rdp encryption for licensing packets (apparently some clients,
specifically cetsc, require the license packets received from the
server to be encrypted under certain RDP encryption levels)
- replace errnous virtual extended mouse event in focus in event
