2011-07-05 01:05:58 +04:00
|
|
|
/**
|
2012-10-09 07:02:04 +04:00
|
|
|
* FreeRDP: A Remote Desktop Protocol Implementation
|
2011-07-05 01:05:58 +04:00
|
|
|
* T.124 Generic Conference Control (GCC)
|
|
|
|
*
|
|
|
|
* Copyright 2011 Marc-Andre Moreau <marcandre.moreau@gmail.com>
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
* Copyright 2014 Norbert Federa <norbert.federa@thincast.com>
|
2015-01-13 19:09:36 +03:00
|
|
|
* Copyright 2014 DI (FH) Martin Haimberger <martin.haimberger@thincast.com>
|
2023-02-09 10:48:11 +03:00
|
|
|
* Copyright 2023 Armin Novak <anovak@thincast.com>
|
|
|
|
* Copyright 2023 Thincast Technologies GmbH
|
2011-07-05 01:05:58 +04:00
|
|
|
*
|
|
|
|
* Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
* you may not use this file except in compliance with the License.
|
|
|
|
* You may obtain a copy of the License at
|
|
|
|
*
|
|
|
|
* http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
*
|
|
|
|
* Unless required by applicable law or agreed to in writing, software
|
|
|
|
* distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
* See the License for the specific language governing permissions and
|
|
|
|
* limitations under the License.
|
|
|
|
*/
|
|
|
|
|
2022-02-16 13:20:38 +03:00
|
|
|
#include <freerdp/config.h>
|
2012-08-15 01:09:01 +04:00
|
|
|
|
2023-10-16 13:59:19 +03:00
|
|
|
#include "settings.h"
|
|
|
|
|
2012-12-14 22:11:07 +04:00
|
|
|
#include <winpr/crt.h>
|
2016-02-24 18:46:25 +03:00
|
|
|
#include <winpr/crypto.h>
|
2021-06-18 10:58:46 +03:00
|
|
|
#include <winpr/assert.h>
|
2011-08-31 12:35:50 +04:00
|
|
|
|
2014-09-12 16:36:29 +04:00
|
|
|
#include <freerdp/log.h>
|
2023-01-21 11:45:11 +03:00
|
|
|
#include <freerdp/utils/string.h>
|
2023-02-03 13:53:49 +03:00
|
|
|
#include <freerdp/crypto/certificate.h>
|
2014-09-12 16:36:29 +04:00
|
|
|
|
2022-10-10 12:41:34 +03:00
|
|
|
#include "utils.h"
|
2011-07-05 01:05:58 +04:00
|
|
|
#include "gcc.h"
|
2023-02-03 13:53:49 +03:00
|
|
|
#include "nego.h"
|
|
|
|
|
|
|
|
#include "../crypto/certificate.h"
|
2011-07-05 01:05:58 +04:00
|
|
|
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
#define TAG FREERDP_TAG("core.gcc")
|
2014-09-12 16:36:29 +04:00
|
|
|
|
2023-04-13 13:39:59 +03:00
|
|
|
typedef enum
|
|
|
|
{
|
|
|
|
HIGH_COLOR_4BPP = 0x04,
|
|
|
|
HIGH_COLOR_8BPP = 0x08,
|
|
|
|
HIGH_COLOR_15BPP = 0x0F,
|
|
|
|
HIGH_COLOR_16BPP = 0x10,
|
|
|
|
HIGH_COLOR_24BPP = 0x18,
|
|
|
|
} HIGH_COLOR_DEPTH;
|
|
|
|
|
|
|
|
static const char* HighColorToString(HIGH_COLOR_DEPTH color)
|
|
|
|
{
|
|
|
|
switch (color)
|
|
|
|
{
|
|
|
|
case HIGH_COLOR_4BPP:
|
|
|
|
return "HIGH_COLOR_4BPP";
|
|
|
|
case HIGH_COLOR_8BPP:
|
|
|
|
return "HIGH_COLOR_8BPP";
|
|
|
|
case HIGH_COLOR_15BPP:
|
|
|
|
return "HIGH_COLOR_15BPP";
|
|
|
|
case HIGH_COLOR_16BPP:
|
|
|
|
return "HIGH_COLOR_16BPP";
|
|
|
|
case HIGH_COLOR_24BPP:
|
|
|
|
return "HIGH_COLOR_24BPP";
|
|
|
|
default:
|
|
|
|
return "HIGH_COLOR_UNKNOWN";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static HIGH_COLOR_DEPTH ColorDepthToHighColor(UINT32 bpp)
|
|
|
|
{
|
|
|
|
switch (bpp)
|
|
|
|
{
|
|
|
|
case 4:
|
|
|
|
return HIGH_COLOR_4BPP;
|
|
|
|
case 8:
|
|
|
|
return HIGH_COLOR_8BPP;
|
|
|
|
case 15:
|
|
|
|
return HIGH_COLOR_15BPP;
|
|
|
|
case 16:
|
|
|
|
return HIGH_COLOR_16BPP;
|
|
|
|
default:
|
|
|
|
return HIGH_COLOR_24BPP;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-06-28 15:38:51 +03:00
|
|
|
static char* gcc_block_type_string(UINT16 type, char* buffer, size_t size);
|
2023-06-26 12:38:11 +03:00
|
|
|
static BOOL gcc_read_client_cluster_data(wStream* s, rdpMcs* mcs);
|
|
|
|
static BOOL gcc_read_client_core_data(wStream* s, rdpMcs* mcs);
|
2021-01-25 12:06:01 +03:00
|
|
|
static BOOL gcc_read_client_data_blocks(wStream* s, rdpMcs* mcs, UINT16 length);
|
|
|
|
static BOOL gcc_read_server_data_blocks(wStream* s, rdpMcs* mcs, UINT16 length);
|
2019-11-20 13:30:14 +03:00
|
|
|
static BOOL gcc_read_user_data_header(wStream* s, UINT16* type, UINT16* length);
|
2020-11-18 09:51:45 +03:00
|
|
|
static BOOL gcc_write_user_data_header(wStream* s, UINT16 type, UINT16 length);
|
2019-11-20 13:30:14 +03:00
|
|
|
|
2022-10-10 12:41:34 +03:00
|
|
|
static BOOL gcc_write_client_core_data(wStream* s, const rdpMcs* mcs);
|
2019-11-20 13:30:14 +03:00
|
|
|
static BOOL gcc_read_server_core_data(wStream* s, rdpMcs* mcs);
|
2022-12-12 14:17:18 +03:00
|
|
|
static BOOL gcc_write_server_core_data(wStream* s, rdpMcs* mcs);
|
2023-06-26 12:38:11 +03:00
|
|
|
static BOOL gcc_read_client_security_data(wStream* s, rdpMcs* mcs);
|
2020-11-18 09:51:45 +03:00
|
|
|
static BOOL gcc_write_client_security_data(wStream* s, const rdpMcs* mcs);
|
2019-11-20 13:30:14 +03:00
|
|
|
static BOOL gcc_read_server_security_data(wStream* s, rdpMcs* mcs);
|
2022-12-12 14:17:18 +03:00
|
|
|
static BOOL gcc_write_server_security_data(wStream* s, rdpMcs* mcs);
|
2023-06-26 12:38:11 +03:00
|
|
|
static BOOL gcc_read_client_network_data(wStream* s, rdpMcs* mcs);
|
2020-11-18 09:51:45 +03:00
|
|
|
static BOOL gcc_write_client_network_data(wStream* s, const rdpMcs* mcs);
|
2019-11-20 13:30:14 +03:00
|
|
|
static BOOL gcc_read_server_network_data(wStream* s, rdpMcs* mcs);
|
2020-11-18 09:51:45 +03:00
|
|
|
static BOOL gcc_write_server_network_data(wStream* s, const rdpMcs* mcs);
|
|
|
|
static BOOL gcc_write_client_cluster_data(wStream* s, const rdpMcs* mcs);
|
2023-06-26 12:38:11 +03:00
|
|
|
static BOOL gcc_read_client_monitor_data(wStream* s, rdpMcs* mcs);
|
2020-11-18 09:51:45 +03:00
|
|
|
static BOOL gcc_write_client_monitor_data(wStream* s, const rdpMcs* mcs);
|
2023-06-26 12:38:11 +03:00
|
|
|
static BOOL gcc_read_client_monitor_extended_data(wStream* s, rdpMcs* mcs);
|
2020-11-18 09:51:45 +03:00
|
|
|
static BOOL gcc_write_client_monitor_extended_data(wStream* s, const rdpMcs* mcs);
|
2023-06-26 12:38:11 +03:00
|
|
|
static BOOL gcc_read_client_message_channel_data(wStream* s, rdpMcs* mcs);
|
2020-11-18 09:51:45 +03:00
|
|
|
static BOOL gcc_write_client_message_channel_data(wStream* s, const rdpMcs* mcs);
|
2019-11-20 13:30:14 +03:00
|
|
|
static BOOL gcc_read_server_message_channel_data(wStream* s, rdpMcs* mcs);
|
2020-11-18 09:51:45 +03:00
|
|
|
static BOOL gcc_write_server_message_channel_data(wStream* s, const rdpMcs* mcs);
|
2023-06-26 12:38:11 +03:00
|
|
|
static BOOL gcc_read_client_multitransport_channel_data(wStream* s, rdpMcs* mcs);
|
2020-11-18 09:51:45 +03:00
|
|
|
static BOOL gcc_write_client_multitransport_channel_data(wStream* s, const rdpMcs* mcs);
|
2019-11-20 13:30:14 +03:00
|
|
|
static BOOL gcc_read_server_multitransport_channel_data(wStream* s, rdpMcs* mcs);
|
2020-11-18 09:51:45 +03:00
|
|
|
static BOOL gcc_write_server_multitransport_channel_data(wStream* s, const rdpMcs* mcs);
|
2019-11-20 13:30:14 +03:00
|
|
|
|
2022-12-12 14:17:18 +03:00
|
|
|
static rdpSettings* mcs_get_settings(rdpMcs* mcs)
|
|
|
|
{
|
|
|
|
WINPR_ASSERT(mcs);
|
|
|
|
|
|
|
|
rdpContext* context = transport_get_context(mcs->transport);
|
|
|
|
WINPR_ASSERT(context);
|
|
|
|
|
|
|
|
return context->settings;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const rdpSettings* mcs_get_const_settings(const rdpMcs* mcs)
|
|
|
|
{
|
|
|
|
WINPR_ASSERT(mcs);
|
|
|
|
|
|
|
|
const rdpContext* context = transport_get_context(mcs->transport);
|
|
|
|
WINPR_ASSERT(context);
|
|
|
|
|
|
|
|
return context->settings;
|
|
|
|
}
|
|
|
|
|
2023-01-19 17:49:05 +03:00
|
|
|
static char* rdp_early_server_caps_string(UINT32 flags, char* buffer, size_t size)
|
2022-10-10 12:41:34 +03:00
|
|
|
{
|
2023-01-19 17:49:05 +03:00
|
|
|
char msg[32] = { 0 };
|
|
|
|
const UINT32 mask = RNS_UD_SC_EDGE_ACTIONS_SUPPORTED_V1 | RNS_UD_SC_DYNAMIC_DST_SUPPORTED |
|
|
|
|
RNS_UD_SC_EDGE_ACTIONS_SUPPORTED_V2 | RNS_UD_SC_SKIP_CHANNELJOIN_SUPPORTED;
|
|
|
|
const UINT32 unknown = flags & (~mask);
|
|
|
|
|
|
|
|
if (flags & RNS_UD_SC_EDGE_ACTIONS_SUPPORTED_V1)
|
|
|
|
winpr_str_append("RNS_UD_SC_EDGE_ACTIONS_SUPPORTED_V1", buffer, size, "|");
|
|
|
|
if (flags & RNS_UD_SC_DYNAMIC_DST_SUPPORTED)
|
|
|
|
winpr_str_append("RNS_UD_SC_DYNAMIC_DST_SUPPORTED", buffer, size, "|");
|
|
|
|
if (flags & RNS_UD_SC_EDGE_ACTIONS_SUPPORTED_V2)
|
|
|
|
winpr_str_append("RNS_UD_SC_EDGE_ACTIONS_SUPPORTED_V2", buffer, size, "|");
|
|
|
|
if (flags & RNS_UD_SC_SKIP_CHANNELJOIN_SUPPORTED)
|
|
|
|
winpr_str_append("RNS_UD_SC_SKIP_CHANNELJOIN_SUPPORTED", buffer, size, "|");
|
|
|
|
|
|
|
|
if (unknown != 0)
|
|
|
|
{
|
|
|
|
_snprintf(msg, sizeof(msg), "RNS_UD_SC_UNKNOWN[0x%08" PRIx32 "]", unknown);
|
|
|
|
winpr_str_append(msg, buffer, size, "|");
|
|
|
|
}
|
|
|
|
_snprintf(msg, sizeof(msg), "[0x%08" PRIx32 "]", flags);
|
|
|
|
winpr_str_append(msg, buffer, size, "|");
|
|
|
|
return buffer;
|
2022-10-10 12:41:34 +03:00
|
|
|
}
|
|
|
|
|
2023-01-19 17:49:05 +03:00
|
|
|
static const char* rdp_early_client_caps_string(UINT32 flags, char* buffer, size_t size)
|
2022-10-10 12:41:34 +03:00
|
|
|
{
|
2023-01-19 17:49:05 +03:00
|
|
|
char msg[32] = { 0 };
|
|
|
|
const UINT32 mask = RNS_UD_CS_SUPPORT_ERRINFO_PDU | RNS_UD_CS_WANT_32BPP_SESSION |
|
|
|
|
RNS_UD_CS_SUPPORT_STATUSINFO_PDU | RNS_UD_CS_STRONG_ASYMMETRIC_KEYS |
|
|
|
|
RNS_UD_CS_VALID_CONNECTION_TYPE | RNS_UD_CS_SUPPORT_MONITOR_LAYOUT_PDU |
|
|
|
|
RNS_UD_CS_SUPPORT_NETCHAR_AUTODETECT |
|
|
|
|
RNS_UD_CS_SUPPORT_DYNVC_GFX_PROTOCOL | RNS_UD_CS_SUPPORT_DYNAMIC_TIME_ZONE |
|
|
|
|
RNS_UD_CS_SUPPORT_HEARTBEAT_PDU | RNS_UD_CS_SUPPORT_SKIP_CHANNELJOIN;
|
|
|
|
const UINT32 unknown = flags & (~mask);
|
2022-10-10 12:41:34 +03:00
|
|
|
|
|
|
|
if (flags & RNS_UD_CS_SUPPORT_ERRINFO_PDU)
|
2023-01-19 17:49:05 +03:00
|
|
|
winpr_str_append("RNS_UD_CS_SUPPORT_ERRINFO_PDU", buffer, size, "|");
|
2022-10-10 12:41:34 +03:00
|
|
|
if (flags & RNS_UD_CS_WANT_32BPP_SESSION)
|
2023-01-19 17:49:05 +03:00
|
|
|
winpr_str_append("RNS_UD_CS_WANT_32BPP_SESSION", buffer, size, "|");
|
2022-10-10 12:41:34 +03:00
|
|
|
if (flags & RNS_UD_CS_SUPPORT_STATUSINFO_PDU)
|
2023-01-19 17:49:05 +03:00
|
|
|
winpr_str_append("RNS_UD_CS_SUPPORT_STATUSINFO_PDU", buffer, size, "|");
|
2022-10-10 12:41:34 +03:00
|
|
|
if (flags & RNS_UD_CS_STRONG_ASYMMETRIC_KEYS)
|
2023-01-19 17:49:05 +03:00
|
|
|
winpr_str_append("RNS_UD_CS_STRONG_ASYMMETRIC_KEYS", buffer, size, "|");
|
2022-10-10 12:41:34 +03:00
|
|
|
if (flags & RNS_UD_CS_VALID_CONNECTION_TYPE)
|
2023-01-19 17:49:05 +03:00
|
|
|
winpr_str_append("RNS_UD_CS_VALID_CONNECTION_TYPE", buffer, size, "|");
|
2022-10-10 12:41:34 +03:00
|
|
|
if (flags & RNS_UD_CS_SUPPORT_MONITOR_LAYOUT_PDU)
|
2023-01-19 17:49:05 +03:00
|
|
|
winpr_str_append("RNS_UD_CS_SUPPORT_MONITOR_LAYOUT_PDU", buffer, size, "|");
|
2022-10-10 12:41:34 +03:00
|
|
|
if (flags & RNS_UD_CS_SUPPORT_NETCHAR_AUTODETECT)
|
2023-01-19 17:49:05 +03:00
|
|
|
winpr_str_append("RNS_UD_CS_SUPPORT_NETCHAR_AUTODETECT", buffer, size, "|");
|
2022-10-10 12:41:34 +03:00
|
|
|
if (flags & RNS_UD_CS_SUPPORT_DYNVC_GFX_PROTOCOL)
|
2023-01-19 17:49:05 +03:00
|
|
|
winpr_str_append("RNS_UD_CS_SUPPORT_DYNVC_GFX_PROTOCOL", buffer, size, "|");
|
2022-10-10 12:41:34 +03:00
|
|
|
if (flags & RNS_UD_CS_SUPPORT_DYNAMIC_TIME_ZONE)
|
2023-01-19 17:49:05 +03:00
|
|
|
winpr_str_append("RNS_UD_CS_SUPPORT_DYNAMIC_TIME_ZONE", buffer, size, "|");
|
2022-10-10 12:41:34 +03:00
|
|
|
if (flags & RNS_UD_CS_SUPPORT_HEARTBEAT_PDU)
|
2023-01-19 17:49:05 +03:00
|
|
|
winpr_str_append("RNS_UD_CS_SUPPORT_HEARTBEAT_PDU", buffer, size, "|");
|
|
|
|
if (flags & RNS_UD_CS_SUPPORT_SKIP_CHANNELJOIN)
|
|
|
|
winpr_str_append("RNS_UD_CS_SUPPORT_SKIP_CHANNELJOIN", buffer, size, "|");
|
2022-10-10 12:41:34 +03:00
|
|
|
|
2023-01-19 17:49:05 +03:00
|
|
|
if (unknown != 0)
|
|
|
|
{
|
|
|
|
_snprintf(msg, sizeof(msg), "RNS_UD_CS_UNKNOWN[0x%08" PRIx32 "]", unknown);
|
|
|
|
winpr_str_append(msg, buffer, size, "|");
|
|
|
|
}
|
|
|
|
_snprintf(msg, sizeof(msg), "[0x%08" PRIx32 "]", flags);
|
|
|
|
winpr_str_append(msg, buffer, size, "|");
|
2022-10-10 12:41:34 +03:00
|
|
|
return buffer;
|
|
|
|
}
|
|
|
|
|
2018-11-14 12:14:48 +03:00
|
|
|
static DWORD rdp_version_common(DWORD serverVersion, DWORD clientVersion)
|
|
|
|
{
|
|
|
|
DWORD version = MIN(serverVersion, clientVersion);
|
|
|
|
|
|
|
|
switch (version)
|
|
|
|
{
|
|
|
|
case RDP_VERSION_4:
|
|
|
|
case RDP_VERSION_5_PLUS:
|
|
|
|
case RDP_VERSION_10_0:
|
|
|
|
case RDP_VERSION_10_1:
|
|
|
|
case RDP_VERSION_10_2:
|
|
|
|
case RDP_VERSION_10_3:
|
|
|
|
case RDP_VERSION_10_4:
|
|
|
|
case RDP_VERSION_10_5:
|
|
|
|
case RDP_VERSION_10_6:
|
2019-12-19 11:50:29 +03:00
|
|
|
case RDP_VERSION_10_7:
|
2022-10-12 13:37:54 +03:00
|
|
|
case RDP_VERSION_10_8:
|
|
|
|
case RDP_VERSION_10_9:
|
|
|
|
case RDP_VERSION_10_10:
|
|
|
|
case RDP_VERSION_10_11:
|
2023-10-12 14:07:11 +03:00
|
|
|
case RDP_VERSION_10_12:
|
2018-11-14 12:14:48 +03:00
|
|
|
return version;
|
|
|
|
|
|
|
|
default:
|
2019-11-06 17:24:51 +03:00
|
|
|
WLog_ERR(TAG, "Invalid client [%" PRId32 "] and server [%" PRId32 "] versions",
|
2018-11-14 12:14:48 +03:00
|
|
|
serverVersion, clientVersion);
|
|
|
|
return version;
|
|
|
|
}
|
|
|
|
}
|
2017-05-29 11:50:22 +03:00
|
|
|
|
2011-07-05 01:05:58 +04:00
|
|
|
/**
|
|
|
|
* T.124 GCC is defined in:
|
|
|
|
*
|
|
|
|
* http://www.itu.int/rec/T-REC-T.124-199802-S/en
|
|
|
|
* ITU-T T.124 (02/98): Generic Conference Control
|
|
|
|
*/
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ConnectData ::= SEQUENCE
|
|
|
|
* {
|
|
|
|
* t124Identifier Key,
|
|
|
|
* connectPDU OCTET_STRING
|
|
|
|
* }
|
|
|
|
*
|
2011-07-05 03:13:01 +04:00
|
|
|
* Key ::= CHOICE
|
|
|
|
* {
|
|
|
|
* object OBJECT_IDENTIFIER,
|
|
|
|
* h221NonStandard H221NonStandardIdentifier
|
|
|
|
* }
|
|
|
|
*
|
2011-07-05 01:05:58 +04:00
|
|
|
* ConnectGCCPDU ::= CHOICE
|
|
|
|
* {
|
|
|
|
* conferenceCreateRequest ConferenceCreateRequest,
|
|
|
|
* conferenceCreateResponse ConferenceCreateResponse,
|
|
|
|
* conferenceQueryRequest ConferenceQueryRequest,
|
|
|
|
* conferenceQueryResponse ConferenceQueryResponse,
|
|
|
|
* conferenceJoinRequest ConferenceJoinRequest,
|
|
|
|
* conferenceJoinResponse ConferenceJoinResponse,
|
|
|
|
* conferenceInviteRequest ConferenceInviteRequest,
|
|
|
|
* conferenceInviteResponse ConferenceInviteResponse,
|
|
|
|
* ...
|
|
|
|
* }
|
2011-07-05 03:13:01 +04:00
|
|
|
*
|
|
|
|
* ConferenceCreateRequest ::= SEQUENCE
|
|
|
|
* {
|
|
|
|
* conferenceName ConferenceName,
|
|
|
|
* convenerPassword Password OPTIONAL,
|
|
|
|
* password Password OPTIONAL,
|
|
|
|
* lockedConference BOOLEAN,
|
|
|
|
* listedConference BOOLEAN,
|
|
|
|
* conductibleConference BOOLEAN,
|
|
|
|
* terminationMethod TerminationMethod,
|
|
|
|
* conductorPrivileges SET OF Privilege OPTIONAL,
|
|
|
|
* conductedPrivileges SET OF Privilege OPTIONAL,
|
|
|
|
* nonConductedPrivileges SET OF Privilege OPTIONAL,
|
|
|
|
* conferenceDescription TextString OPTIONAL,
|
|
|
|
* callerIdentifier TextString OPTIONAL,
|
|
|
|
* userData UserData OPTIONAL,
|
|
|
|
* ...,
|
|
|
|
* conferencePriority ConferencePriority OPTIONAL,
|
|
|
|
* conferenceMode ConferenceMode OPTIONAL
|
|
|
|
* }
|
|
|
|
*
|
2011-07-10 01:28:30 +04:00
|
|
|
* ConferenceCreateResponse ::= SEQUENCE
|
|
|
|
* {
|
|
|
|
* nodeID UserID,
|
|
|
|
* tag INTEGER,
|
|
|
|
* result ENUMERATED
|
|
|
|
* {
|
|
|
|
* success (0),
|
|
|
|
* userRejected (1),
|
|
|
|
* resourcesNotAvailable (2),
|
|
|
|
* rejectedForSymmetryBreaking (3),
|
|
|
|
* lockedConferenceNotSupported (4)
|
|
|
|
* },
|
|
|
|
* userData UserData OPTIONAL,
|
|
|
|
* ...
|
|
|
|
* }
|
|
|
|
*
|
2011-07-05 03:13:01 +04:00
|
|
|
* ConferenceName ::= SEQUENCE
|
|
|
|
* {
|
|
|
|
* numeric SimpleNumericString
|
|
|
|
* text SimpleTextString OPTIONAL,
|
|
|
|
* ...
|
|
|
|
* }
|
|
|
|
*
|
|
|
|
* SimpleNumericString ::= NumericString (SIZE (1..255)) (FROM ("0123456789"))
|
|
|
|
*
|
|
|
|
* UserData ::= SET OF SEQUENCE
|
|
|
|
* {
|
|
|
|
* key Key,
|
|
|
|
* value OCTET_STRING OPTIONAL
|
|
|
|
* }
|
|
|
|
*
|
|
|
|
* H221NonStandardIdentifier ::= OCTET STRING (SIZE (4..255))
|
|
|
|
*
|
2011-07-10 01:28:30 +04:00
|
|
|
* UserID ::= DynamicChannelID
|
|
|
|
*
|
|
|
|
* ChannelID ::= INTEGER (1..65535)
|
|
|
|
* StaticChannelID ::= INTEGER (1..1000)
|
|
|
|
* DynamicChannelID ::= INTEGER (1001..65535)
|
|
|
|
*
|
2011-07-05 01:05:58 +04:00
|
|
|
*/
|
|
|
|
|
2011-07-05 03:13:01 +04:00
|
|
|
/*
|
|
|
|
* OID = 0.0.20.124.0.1
|
|
|
|
* { itu-t(0) recommendation(0) t(20) t124(124) version(0) 1 }
|
|
|
|
* v.1 of ITU-T Recommendation T.124 (Feb 1998): "Generic Conference Control"
|
|
|
|
*/
|
2021-07-28 16:18:03 +03:00
|
|
|
static const BYTE t124_02_98_oid[6] = { 0, 0, 20, 124, 0, 1 };
|
2011-07-05 03:13:01 +04:00
|
|
|
|
2021-07-28 16:18:03 +03:00
|
|
|
static const BYTE h221_cs_key[4] = "Duca";
|
|
|
|
static const BYTE h221_sc_key[4] = "McDn";
|
2011-07-10 01:28:30 +04:00
|
|
|
|
2011-08-19 13:39:37 +04:00
|
|
|
/**
|
2022-12-09 16:35:03 +03:00
|
|
|
* Read a GCC Conference Create Request.
|
|
|
|
* msdn{cc240836}
|
|
|
|
*
|
2011-08-19 13:39:37 +04:00
|
|
|
* @param s stream
|
2022-12-09 16:35:03 +03:00
|
|
|
* @param mcs The MCS instance
|
|
|
|
*
|
|
|
|
* @return \b TRUE for success, \b FALSE otherwise
|
2011-08-19 13:39:37 +04:00
|
|
|
*/
|
|
|
|
|
2014-02-14 02:50:38 +04:00
|
|
|
BOOL gcc_read_conference_create_request(wStream* s, rdpMcs* mcs)
|
2011-08-19 13:39:37 +04:00
|
|
|
{
|
2012-10-09 11:01:37 +04:00
|
|
|
UINT16 length;
|
|
|
|
BYTE choice;
|
|
|
|
BYTE number;
|
|
|
|
BYTE selection;
|
2011-08-19 13:39:37 +04:00
|
|
|
|
2022-12-12 14:17:18 +03:00
|
|
|
WINPR_ASSERT(s);
|
|
|
|
WINPR_ASSERT(mcs);
|
2011-08-19 13:39:37 +04:00
|
|
|
/* ConnectData */
|
|
|
|
if (!per_read_choice(s, &choice))
|
2012-10-09 10:31:28 +04:00
|
|
|
return FALSE;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2011-08-19 13:39:37 +04:00
|
|
|
if (!per_read_object_identifier(s, t124_02_98_oid))
|
2012-10-09 10:31:28 +04:00
|
|
|
return FALSE;
|
2011-08-19 13:39:37 +04:00
|
|
|
|
|
|
|
/* ConnectData::connectPDU (OCTET_STRING) */
|
|
|
|
if (!per_read_length(s, &length))
|
2012-10-09 10:31:28 +04:00
|
|
|
return FALSE;
|
2011-08-19 13:39:37 +04:00
|
|
|
|
|
|
|
/* ConnectGCCPDU */
|
|
|
|
if (!per_read_choice(s, &choice))
|
2012-10-09 10:31:28 +04:00
|
|
|
return FALSE;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2011-08-19 13:39:37 +04:00
|
|
|
if (!per_read_selection(s, &selection))
|
2012-10-09 10:31:28 +04:00
|
|
|
return FALSE;
|
2011-08-19 13:39:37 +04:00
|
|
|
|
|
|
|
/* ConferenceCreateRequest::conferenceName */
|
|
|
|
if (!per_read_numeric_string(s, 1)) /* ConferenceName::numeric */
|
2012-10-09 10:31:28 +04:00
|
|
|
return FALSE;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2011-08-19 13:39:37 +04:00
|
|
|
if (!per_read_padding(s, 1)) /* padding */
|
2012-10-09 10:31:28 +04:00
|
|
|
return FALSE;
|
2011-08-19 13:39:37 +04:00
|
|
|
|
|
|
|
/* UserData (SET OF SEQUENCE) */
|
2019-11-06 17:24:51 +03:00
|
|
|
if (!per_read_number_of_sets(s, &number) || number != 1) /* one set of UserData */
|
2012-10-09 10:31:28 +04:00
|
|
|
return FALSE;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2019-11-06 17:24:51 +03:00
|
|
|
if (!per_read_choice(s, &choice) ||
|
|
|
|
choice != 0xC0) /* UserData::value present + select h221NonStandard (1) */
|
2012-10-09 10:31:28 +04:00
|
|
|
return FALSE;
|
2011-08-19 13:39:37 +04:00
|
|
|
|
|
|
|
/* h221NonStandard */
|
2016-09-20 09:58:04 +03:00
|
|
|
if (!per_read_octet_string(s, h221_cs_key, 4,
|
|
|
|
4)) /* h221NonStandard, client-to-server H.221 key, "Duca" */
|
2012-10-09 10:31:28 +04:00
|
|
|
return FALSE;
|
2011-08-19 13:39:37 +04:00
|
|
|
|
|
|
|
/* userData::value (OCTET_STRING) */
|
|
|
|
if (!per_read_length(s, &length))
|
2012-10-09 10:31:28 +04:00
|
|
|
return FALSE;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2022-04-19 15:29:17 +03:00
|
|
|
if (!Stream_CheckAndLogRequiredLength(TAG, s, length))
|
2012-10-09 10:31:28 +04:00
|
|
|
return FALSE;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2014-02-14 02:50:38 +04:00
|
|
|
if (!gcc_read_client_data_blocks(s, mcs, length))
|
2012-10-09 10:31:28 +04:00
|
|
|
return FALSE;
|
2011-08-19 13:39:37 +04:00
|
|
|
|
2012-10-09 10:31:28 +04:00
|
|
|
return TRUE;
|
2011-08-19 13:39:37 +04:00
|
|
|
}
|
|
|
|
|
2011-07-05 05:35:32 +04:00
|
|
|
/**
|
2022-12-09 16:35:03 +03:00
|
|
|
* Write a GCC Conference Create Request.
|
|
|
|
* msdn{cc240836}
|
|
|
|
*
|
2011-07-05 05:35:32 +04:00
|
|
|
* @param s stream
|
2022-12-09 16:35:03 +03:00
|
|
|
* @param userData client data blocks
|
|
|
|
*
|
|
|
|
* @return \b TRUE for success, \b FALSE otherwise
|
2011-07-05 05:35:32 +04:00
|
|
|
*/
|
|
|
|
|
2020-11-18 09:51:45 +03:00
|
|
|
BOOL gcc_write_conference_create_request(wStream* s, wStream* userData)
|
2011-07-05 03:13:01 +04:00
|
|
|
{
|
2022-12-12 14:17:18 +03:00
|
|
|
WINPR_ASSERT(s);
|
|
|
|
WINPR_ASSERT(userData);
|
2011-07-05 03:13:01 +04:00
|
|
|
/* ConnectData */
|
2020-11-18 09:51:45 +03:00
|
|
|
if (!per_write_choice(s, 0)) /* From Key select object (0) of type OBJECT_IDENTIFIER */
|
|
|
|
return FALSE;
|
|
|
|
if (!per_write_object_identifier(s, t124_02_98_oid)) /* ITU-T T.124 (02/98) OBJECT_IDENTIFIER */
|
|
|
|
return FALSE;
|
2011-07-05 03:13:01 +04:00
|
|
|
/* ConnectData::connectPDU (OCTET_STRING) */
|
2020-11-18 09:51:45 +03:00
|
|
|
if (!per_write_length(s, Stream_GetPosition(userData) + 14)) /* connectPDU length */
|
|
|
|
return FALSE;
|
2011-07-05 03:13:01 +04:00
|
|
|
/* ConnectGCCPDU */
|
2020-11-18 09:51:45 +03:00
|
|
|
if (!per_write_choice(s, 0)) /* From ConnectGCCPDU select conferenceCreateRequest (0) of type
|
2019-11-06 17:24:51 +03:00
|
|
|
ConferenceCreateRequest */
|
2020-11-18 09:51:45 +03:00
|
|
|
return FALSE;
|
|
|
|
if (!per_write_selection(s, 0x08)) /* select optional userData from ConferenceCreateRequest */
|
|
|
|
return FALSE;
|
2011-07-05 03:13:01 +04:00
|
|
|
/* ConferenceCreateRequest::conferenceName */
|
2020-11-18 09:51:45 +03:00
|
|
|
if (!per_write_numeric_string(s, (BYTE*)"1", 1, 1)) /* ConferenceName::numeric */
|
|
|
|
return FALSE;
|
|
|
|
if (!per_write_padding(s, 1)) /* padding */
|
|
|
|
return FALSE;
|
2011-07-05 03:13:01 +04:00
|
|
|
/* UserData (SET OF SEQUENCE) */
|
2020-11-18 09:51:45 +03:00
|
|
|
if (!per_write_number_of_sets(s, 1)) /* one set of UserData */
|
|
|
|
return FALSE;
|
|
|
|
if (!per_write_choice(s, 0xC0)) /* UserData::value present + select h221NonStandard (1) */
|
|
|
|
return FALSE;
|
2011-07-05 03:13:01 +04:00
|
|
|
/* h221NonStandard */
|
2020-11-18 09:51:45 +03:00
|
|
|
if (!per_write_octet_string(s, h221_cs_key, 4,
|
|
|
|
4)) /* h221NonStandard, client-to-server H.221 key, "Duca" */
|
|
|
|
return FALSE;
|
2011-07-05 03:13:01 +04:00
|
|
|
/* userData::value (OCTET_STRING) */
|
2020-11-18 09:51:45 +03:00
|
|
|
return per_write_octet_string(s, Stream_Buffer(userData), Stream_GetPosition(userData),
|
|
|
|
0); /* array of client data blocks */
|
2011-07-05 03:13:01 +04:00
|
|
|
}
|
2011-07-05 06:02:00 +04:00
|
|
|
|
2014-02-14 02:50:38 +04:00
|
|
|
BOOL gcc_read_conference_create_response(wStream* s, rdpMcs* mcs)
|
2011-07-10 01:28:30 +04:00
|
|
|
{
|
2012-10-09 11:01:37 +04:00
|
|
|
UINT16 length;
|
2012-10-09 11:26:39 +04:00
|
|
|
UINT32 tag;
|
2012-10-09 11:01:37 +04:00
|
|
|
UINT16 nodeID;
|
|
|
|
BYTE result;
|
|
|
|
BYTE choice;
|
|
|
|
BYTE number;
|
2022-12-12 14:17:18 +03:00
|
|
|
WINPR_ASSERT(s);
|
|
|
|
WINPR_ASSERT(mcs);
|
2011-07-10 01:28:30 +04:00
|
|
|
/* ConnectData */
|
2019-11-06 17:24:51 +03:00
|
|
|
if (!per_read_choice(s, &choice) || !per_read_object_identifier(s, t124_02_98_oid))
|
2013-11-29 02:17:21 +04:00
|
|
|
return FALSE;
|
2011-07-10 01:28:30 +04:00
|
|
|
|
|
|
|
/* ConnectData::connectPDU (OCTET_STRING) */
|
2013-11-29 02:17:21 +04:00
|
|
|
if (!per_read_length(s, &length))
|
|
|
|
return FALSE;
|
2011-07-10 01:28:30 +04:00
|
|
|
|
|
|
|
/* ConnectGCCPDU */
|
2013-11-29 02:17:21 +04:00
|
|
|
if (!per_read_choice(s, &choice))
|
|
|
|
return FALSE;
|
2011-07-10 01:28:30 +04:00
|
|
|
|
|
|
|
/* ConferenceCreateResponse::nodeID (UserID) */
|
2013-11-29 02:17:21 +04:00
|
|
|
if (!per_read_integer16(s, &nodeID, 1001))
|
|
|
|
return FALSE;
|
2011-07-10 01:28:30 +04:00
|
|
|
|
|
|
|
/* ConferenceCreateResponse::tag (INTEGER) */
|
2013-11-29 02:17:21 +04:00
|
|
|
if (!per_read_integer(s, &tag))
|
|
|
|
return FALSE;
|
2011-07-10 01:28:30 +04:00
|
|
|
|
|
|
|
/* ConferenceCreateResponse::result (ENUMERATED) */
|
2013-11-29 02:17:21 +04:00
|
|
|
if (!per_read_enumerated(s, &result, MCS_Result_enum_length))
|
|
|
|
return FALSE;
|
2011-07-10 01:28:30 +04:00
|
|
|
|
|
|
|
/* number of UserData sets */
|
2013-11-29 02:17:21 +04:00
|
|
|
if (!per_read_number_of_sets(s, &number))
|
|
|
|
return FALSE;
|
2011-07-10 01:28:30 +04:00
|
|
|
|
|
|
|
/* UserData::value present + select h221NonStandard (1) */
|
2013-11-29 02:17:21 +04:00
|
|
|
if (!per_read_choice(s, &choice))
|
|
|
|
return FALSE;
|
2011-07-10 01:28:30 +04:00
|
|
|
|
|
|
|
/* h221NonStandard */
|
2016-09-20 09:58:04 +03:00
|
|
|
if (!per_read_octet_string(s, h221_sc_key, 4,
|
|
|
|
4)) /* h221NonStandard, server-to-client H.221 key, "McDn" */
|
2012-10-09 10:31:28 +04:00
|
|
|
return FALSE;
|
2011-07-10 01:28:30 +04:00
|
|
|
|
|
|
|
/* userData (OCTET_STRING) */
|
2013-11-29 02:17:21 +04:00
|
|
|
if (!per_read_length(s, &length))
|
|
|
|
return FALSE;
|
|
|
|
|
2014-02-14 02:50:38 +04:00
|
|
|
if (!gcc_read_server_data_blocks(s, mcs, length))
|
2011-09-05 22:02:52 +04:00
|
|
|
{
|
2019-11-06 17:24:51 +03:00
|
|
|
WLog_ERR(TAG, "gcc_read_conference_create_response: gcc_read_server_data_blocks failed");
|
2012-10-09 10:31:28 +04:00
|
|
|
return FALSE;
|
2011-09-05 22:02:52 +04:00
|
|
|
}
|
2011-08-22 11:03:58 +04:00
|
|
|
|
2012-10-09 10:31:28 +04:00
|
|
|
return TRUE;
|
2011-07-10 05:04:57 +04:00
|
|
|
}
|
|
|
|
|
2020-11-18 09:51:45 +03:00
|
|
|
BOOL gcc_write_conference_create_response(wStream* s, wStream* userData)
|
2011-08-19 19:56:47 +04:00
|
|
|
{
|
2022-12-12 14:17:18 +03:00
|
|
|
WINPR_ASSERT(s);
|
|
|
|
WINPR_ASSERT(userData);
|
2011-08-19 19:56:47 +04:00
|
|
|
/* ConnectData */
|
2020-11-18 09:51:45 +03:00
|
|
|
if (!per_write_choice(s, 0))
|
|
|
|
return FALSE;
|
|
|
|
if (!per_write_object_identifier(s, t124_02_98_oid))
|
|
|
|
return FALSE;
|
2011-08-19 19:56:47 +04:00
|
|
|
/* ConnectData::connectPDU (OCTET_STRING) */
|
2014-10-22 13:24:36 +04:00
|
|
|
/* This length MUST be ignored by the client according to [MS-RDPBCGR] */
|
2020-11-18 09:51:45 +03:00
|
|
|
if (!per_write_length(s, 0x2A))
|
|
|
|
return FALSE;
|
2011-08-19 19:56:47 +04:00
|
|
|
/* ConnectGCCPDU */
|
2020-11-18 09:51:45 +03:00
|
|
|
if (!per_write_choice(s, 0x14))
|
|
|
|
return FALSE;
|
2011-08-19 19:56:47 +04:00
|
|
|
/* ConferenceCreateResponse::nodeID (UserID) */
|
2020-11-18 09:51:45 +03:00
|
|
|
if (!per_write_integer16(s, 0x79F3, 1001))
|
|
|
|
return FALSE;
|
2011-08-19 19:56:47 +04:00
|
|
|
/* ConferenceCreateResponse::tag (INTEGER) */
|
2020-11-18 09:51:45 +03:00
|
|
|
if (!per_write_integer(s, 1))
|
|
|
|
return FALSE;
|
2011-08-19 19:56:47 +04:00
|
|
|
/* ConferenceCreateResponse::result (ENUMERATED) */
|
2020-11-18 09:51:45 +03:00
|
|
|
if (!per_write_enumerated(s, 0, MCS_Result_enum_length))
|
|
|
|
return FALSE;
|
2011-08-19 19:56:47 +04:00
|
|
|
/* number of UserData sets */
|
2020-11-18 09:51:45 +03:00
|
|
|
if (!per_write_number_of_sets(s, 1))
|
|
|
|
return FALSE;
|
2011-08-19 19:56:47 +04:00
|
|
|
/* UserData::value present + select h221NonStandard (1) */
|
2020-11-18 09:51:45 +03:00
|
|
|
if (!per_write_choice(s, 0xC0))
|
|
|
|
return FALSE;
|
2011-08-19 19:56:47 +04:00
|
|
|
/* h221NonStandard */
|
2020-11-18 09:51:45 +03:00
|
|
|
if (!per_write_octet_string(s, h221_sc_key, 4,
|
|
|
|
4)) /* h221NonStandard, server-to-client H.221 key, "McDn" */
|
|
|
|
return FALSE;
|
2011-08-19 19:56:47 +04:00
|
|
|
/* userData (OCTET_STRING) */
|
2020-11-18 09:51:45 +03:00
|
|
|
return per_write_octet_string(s, Stream_Buffer(userData), Stream_GetPosition(userData),
|
|
|
|
0); /* array of server data blocks */
|
2011-08-19 19:56:47 +04:00
|
|
|
}
|
|
|
|
|
2023-10-16 17:32:56 +03:00
|
|
|
static BOOL gcc_read_client_unused1_data(wStream* s)
|
2023-10-12 22:48:07 +03:00
|
|
|
{
|
|
|
|
return Stream_SafeSeek(s, 2);
|
|
|
|
}
|
|
|
|
|
2021-01-25 12:06:01 +03:00
|
|
|
BOOL gcc_read_client_data_blocks(wStream* s, rdpMcs* mcs, UINT16 length)
|
2011-08-19 13:39:37 +04:00
|
|
|
{
|
2022-12-12 14:17:18 +03:00
|
|
|
WINPR_ASSERT(s);
|
|
|
|
WINPR_ASSERT(mcs);
|
2011-08-19 13:39:37 +04:00
|
|
|
while (length > 0)
|
|
|
|
{
|
2023-06-26 12:38:11 +03:00
|
|
|
wStream sbuffer = { 0 };
|
2023-06-28 15:38:51 +03:00
|
|
|
UINT16 type = 0;
|
|
|
|
UINT16 blockLength = 0;
|
2014-01-24 01:00:02 +04:00
|
|
|
|
|
|
|
if (!gcc_read_user_data_header(s, &type, &blockLength))
|
|
|
|
return FALSE;
|
|
|
|
|
2022-04-19 15:29:17 +03:00
|
|
|
if (!Stream_CheckAndLogRequiredLength(TAG, s, (size_t)(blockLength - 4)))
|
2013-01-11 04:23:31 +04:00
|
|
|
return FALSE;
|
2011-08-19 13:39:37 +04:00
|
|
|
|
2023-06-26 12:38:11 +03:00
|
|
|
wStream* sub = Stream_StaticConstInit(&sbuffer, Stream_Pointer(s), blockLength - 4);
|
|
|
|
WINPR_ASSERT(sub);
|
|
|
|
|
2023-06-28 15:38:51 +03:00
|
|
|
Stream_Seek(s, blockLength - 4);
|
|
|
|
|
2011-08-19 13:39:37 +04:00
|
|
|
switch (type)
|
|
|
|
{
|
|
|
|
case CS_CORE:
|
2023-06-26 12:38:11 +03:00
|
|
|
if (!gcc_read_client_core_data(sub, mcs))
|
2012-10-09 10:31:28 +04:00
|
|
|
return FALSE;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2011-08-19 13:39:37 +04:00
|
|
|
break;
|
|
|
|
|
|
|
|
case CS_SECURITY:
|
2023-06-26 12:38:11 +03:00
|
|
|
if (!gcc_read_client_security_data(sub, mcs))
|
2012-10-09 10:31:28 +04:00
|
|
|
return FALSE;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2011-08-19 13:39:37 +04:00
|
|
|
break;
|
|
|
|
|
|
|
|
case CS_NET:
|
2023-06-26 12:38:11 +03:00
|
|
|
if (!gcc_read_client_network_data(sub, mcs))
|
2012-10-09 10:31:28 +04:00
|
|
|
return FALSE;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2011-08-19 13:39:37 +04:00
|
|
|
break;
|
|
|
|
|
|
|
|
case CS_CLUSTER:
|
2023-06-26 12:38:11 +03:00
|
|
|
if (!gcc_read_client_cluster_data(sub, mcs))
|
2012-10-09 10:31:28 +04:00
|
|
|
return FALSE;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2011-08-19 13:39:37 +04:00
|
|
|
break;
|
|
|
|
|
|
|
|
case CS_MONITOR:
|
2023-06-26 12:38:11 +03:00
|
|
|
if (!gcc_read_client_monitor_data(sub, mcs))
|
2012-10-09 10:31:28 +04:00
|
|
|
return FALSE;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2011-08-19 13:39:37 +04:00
|
|
|
break;
|
|
|
|
|
2014-01-24 01:00:02 +04:00
|
|
|
case CS_MCS_MSGCHANNEL:
|
2023-06-26 12:38:11 +03:00
|
|
|
if (!gcc_read_client_message_channel_data(sub, mcs))
|
2014-01-24 01:00:02 +04:00
|
|
|
return FALSE;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2014-01-24 01:00:02 +04:00
|
|
|
break;
|
|
|
|
|
|
|
|
case CS_MONITOR_EX:
|
2023-06-26 12:38:11 +03:00
|
|
|
if (!gcc_read_client_monitor_extended_data(sub, mcs))
|
2014-01-24 01:00:02 +04:00
|
|
|
return FALSE;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2014-01-24 01:00:02 +04:00
|
|
|
break;
|
|
|
|
|
2023-10-12 22:48:07 +03:00
|
|
|
case CS_UNUSED1:
|
|
|
|
if (!gcc_read_client_unused1_data(sub))
|
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
break;
|
|
|
|
|
2014-11-20 05:00:28 +03:00
|
|
|
case 0xC009:
|
2014-01-24 01:00:02 +04:00
|
|
|
case CS_MULTITRANSPORT:
|
2023-06-26 12:38:11 +03:00
|
|
|
if (!gcc_read_client_multitransport_channel_data(sub, mcs))
|
2014-01-24 01:00:02 +04:00
|
|
|
return FALSE;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2014-01-24 01:00:02 +04:00
|
|
|
break;
|
|
|
|
|
2011-08-19 13:39:37 +04:00
|
|
|
default:
|
2019-11-06 17:24:51 +03:00
|
|
|
WLog_ERR(TAG, "Unknown GCC client data block: 0x%04" PRIX16 "", type);
|
2023-06-26 12:38:11 +03:00
|
|
|
winpr_HexDump(TAG, WLOG_TRACE, Stream_Pointer(sub), Stream_GetRemainingLength(sub));
|
2011-08-19 13:39:37 +04:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2023-06-28 15:38:51 +03:00
|
|
|
const size_t rem = Stream_GetRemainingLength(sub);
|
|
|
|
if (rem > 0)
|
2014-01-24 01:00:02 +04:00
|
|
|
{
|
2023-06-28 15:38:51 +03:00
|
|
|
char buffer[128] = { 0 };
|
|
|
|
const size_t total = Stream_Length(sub);
|
2016-09-20 09:58:04 +03:00
|
|
|
WLog_ERR(TAG,
|
2023-06-28 15:38:51 +03:00
|
|
|
"Error parsing GCC client data block %s: Actual Offset: %" PRIuz
|
2022-09-29 15:55:27 +03:00
|
|
|
" Expected Offset: %" PRIuz,
|
2023-06-28 15:38:51 +03:00
|
|
|
gcc_block_type_string(type, buffer, sizeof(buffer)), total - rem, total);
|
2014-01-24 01:00:02 +04:00
|
|
|
}
|
|
|
|
|
2023-06-28 15:38:51 +03:00
|
|
|
if (blockLength > length)
|
|
|
|
{
|
|
|
|
char buffer[128] = { 0 };
|
|
|
|
WLog_ERR(TAG,
|
|
|
|
"Error parsing GCC client data block %s: got blockLength 0x%04" PRIx16
|
|
|
|
", but only 0x%04" PRIx16 "remaining",
|
|
|
|
gcc_block_type_string(type, buffer, sizeof(buffer)), blockLength, length);
|
|
|
|
length = 0;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
length -= blockLength;
|
2011-08-19 13:39:37 +04:00
|
|
|
}
|
|
|
|
|
2012-10-09 10:31:28 +04:00
|
|
|
return TRUE;
|
2011-08-19 13:39:37 +04:00
|
|
|
}
|
|
|
|
|
2022-10-10 12:41:34 +03:00
|
|
|
BOOL gcc_write_client_data_blocks(wStream* s, const rdpMcs* mcs)
|
2011-07-10 07:54:23 +04:00
|
|
|
{
|
2022-12-12 14:17:18 +03:00
|
|
|
const rdpSettings* settings = mcs_get_const_settings(mcs);
|
2021-09-03 12:31:21 +03:00
|
|
|
|
|
|
|
WINPR_ASSERT(s);
|
|
|
|
WINPR_ASSERT(settings);
|
|
|
|
|
2020-11-18 09:51:45 +03:00
|
|
|
if (!gcc_write_client_core_data(s, mcs) || !gcc_write_client_cluster_data(s, mcs) ||
|
|
|
|
!gcc_write_client_security_data(s, mcs) || !gcc_write_client_network_data(s, mcs))
|
|
|
|
return FALSE;
|
2011-12-18 21:10:56 +04:00
|
|
|
|
|
|
|
/* extended client data supported */
|
|
|
|
|
2012-12-13 23:38:02 +04:00
|
|
|
if (settings->NegotiationFlags & EXTENDED_CLIENT_DATA_SUPPORTED)
|
|
|
|
{
|
2014-03-25 22:39:21 +04:00
|
|
|
if (settings->UseMultimon && !settings->SpanMonitors)
|
2012-12-13 23:38:02 +04:00
|
|
|
{
|
2020-11-18 09:51:45 +03:00
|
|
|
if (!gcc_write_client_monitor_data(s, mcs) ||
|
|
|
|
!gcc_write_client_monitor_extended_data(s, mcs))
|
2021-01-21 16:24:38 +03:00
|
|
|
return FALSE;
|
2012-12-13 23:38:02 +04:00
|
|
|
}
|
2014-03-25 22:39:21 +04:00
|
|
|
|
2020-11-18 09:51:45 +03:00
|
|
|
if (!gcc_write_client_message_channel_data(s, mcs) ||
|
|
|
|
!gcc_write_client_multitransport_channel_data(s, mcs))
|
|
|
|
return FALSE;
|
2012-12-13 23:38:02 +04:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2014-03-25 22:39:21 +04:00
|
|
|
if (settings->UseMultimon && !settings->SpanMonitors)
|
2012-12-13 23:38:02 +04:00
|
|
|
{
|
2019-11-06 17:24:51 +03:00
|
|
|
WLog_ERR(TAG, "WARNING: true multi monitor support was not advertised by server!");
|
2012-12-13 23:38:02 +04:00
|
|
|
|
|
|
|
if (settings->ForceMultimon)
|
|
|
|
{
|
2019-11-06 17:24:51 +03:00
|
|
|
WLog_ERR(TAG, "Sending multi monitor information anyway (may break connectivity!)");
|
2020-11-18 09:51:45 +03:00
|
|
|
if (!gcc_write_client_monitor_data(s, mcs) ||
|
|
|
|
!gcc_write_client_monitor_extended_data(s, mcs))
|
2021-01-21 16:24:38 +03:00
|
|
|
return FALSE;
|
2012-12-13 23:38:02 +04:00
|
|
|
}
|
2012-12-14 01:29:16 +04:00
|
|
|
else
|
|
|
|
{
|
2019-11-06 17:24:51 +03:00
|
|
|
WLog_ERR(TAG, "Use /multimon:force to force sending multi monitor information");
|
2012-12-14 01:29:16 +04:00
|
|
|
}
|
2012-12-13 23:38:02 +04:00
|
|
|
}
|
|
|
|
}
|
2021-01-21 16:24:38 +03:00
|
|
|
return TRUE;
|
2011-07-10 07:54:23 +04:00
|
|
|
}
|
|
|
|
|
2023-06-28 15:38:51 +03:00
|
|
|
char* gcc_block_type_string(UINT16 type, char* buffer, size_t size)
|
2022-10-10 12:41:34 +03:00
|
|
|
{
|
|
|
|
switch (type)
|
|
|
|
{
|
|
|
|
case CS_CORE:
|
|
|
|
_snprintf(buffer, size, "CS_CORE [0x%04" PRIx16 "]", type);
|
|
|
|
break;
|
|
|
|
case CS_SECURITY:
|
|
|
|
_snprintf(buffer, size, "CS_SECURITY [0x%04" PRIx16 "]", type);
|
|
|
|
break;
|
|
|
|
case CS_NET:
|
|
|
|
_snprintf(buffer, size, "CS_NET [0x%04" PRIx16 "]", type);
|
|
|
|
break;
|
|
|
|
case CS_CLUSTER:
|
|
|
|
_snprintf(buffer, size, "CS_CLUSTER [0x%04" PRIx16 "]", type);
|
|
|
|
break;
|
|
|
|
case CS_MONITOR:
|
|
|
|
_snprintf(buffer, size, "CS_MONITOR [0x%04" PRIx16 "]", type);
|
|
|
|
break;
|
|
|
|
case CS_MCS_MSGCHANNEL:
|
|
|
|
_snprintf(buffer, size, "CS_MONITOR [0x%04" PRIx16 "]", type);
|
|
|
|
break;
|
|
|
|
case CS_MONITOR_EX:
|
|
|
|
_snprintf(buffer, size, "CS_MONITOR_EX [0x%04" PRIx16 "]", type);
|
|
|
|
break;
|
2023-10-12 22:48:07 +03:00
|
|
|
case CS_UNUSED1:
|
|
|
|
_snprintf(buffer, size, "CS_UNUSED1 [0x%04" PRIx16 "]", type);
|
|
|
|
break;
|
2022-10-10 12:41:34 +03:00
|
|
|
case CS_MULTITRANSPORT:
|
|
|
|
_snprintf(buffer, size, "CS_MONITOR_EX [0x%04" PRIx16 "]", type);
|
|
|
|
break;
|
|
|
|
case SC_CORE:
|
|
|
|
_snprintf(buffer, size, "SC_CORE [0x%04" PRIx16 "]", type);
|
|
|
|
break;
|
|
|
|
case SC_SECURITY:
|
|
|
|
_snprintf(buffer, size, "SC_SECURITY [0x%04" PRIx16 "]", type);
|
|
|
|
break;
|
|
|
|
case SC_NET:
|
|
|
|
_snprintf(buffer, size, "SC_NET [0x%04" PRIx16 "]", type);
|
|
|
|
break;
|
|
|
|
case SC_MCS_MSGCHANNEL:
|
|
|
|
_snprintf(buffer, size, "SC_MCS_MSGCHANNEL [0x%04" PRIx16 "]", type);
|
|
|
|
break;
|
|
|
|
case SC_MULTITRANSPORT:
|
|
|
|
_snprintf(buffer, size, "SC_MULTITRANSPORT [0x%04" PRIx16 "]", type);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
_snprintf(buffer, size, "UNKNOWN [0x%04" PRIx16 "]", type);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return buffer;
|
|
|
|
}
|
|
|
|
|
2021-01-25 12:06:01 +03:00
|
|
|
BOOL gcc_read_server_data_blocks(wStream* s, rdpMcs* mcs, UINT16 length)
|
2011-07-10 05:04:57 +04:00
|
|
|
{
|
2012-10-09 11:01:37 +04:00
|
|
|
UINT16 type;
|
|
|
|
UINT16 offset = 0;
|
|
|
|
UINT16 blockLength;
|
|
|
|
BYTE* holdp;
|
2011-07-10 05:04:57 +04:00
|
|
|
|
2022-12-12 14:17:18 +03:00
|
|
|
WINPR_ASSERT(s);
|
|
|
|
WINPR_ASSERT(mcs);
|
|
|
|
|
2011-07-10 05:04:57 +04:00
|
|
|
while (offset < length)
|
|
|
|
{
|
2022-10-10 12:41:34 +03:00
|
|
|
char buffer[64] = { 0 };
|
2020-04-01 10:56:13 +03:00
|
|
|
size_t rest;
|
2021-10-14 09:42:49 +03:00
|
|
|
wStream subbuffer;
|
|
|
|
wStream* sub;
|
2011-09-05 22:02:52 +04:00
|
|
|
|
2011-08-22 11:03:58 +04:00
|
|
|
if (!gcc_read_user_data_header(s, &type, &blockLength))
|
2011-09-05 22:02:52 +04:00
|
|
|
{
|
2019-11-06 17:24:51 +03:00
|
|
|
WLog_ERR(TAG, "gcc_read_server_data_blocks: gcc_read_user_data_header failed");
|
2012-10-09 10:31:28 +04:00
|
|
|
return FALSE;
|
2011-09-05 22:02:52 +04:00
|
|
|
}
|
2020-04-01 10:56:13 +03:00
|
|
|
holdp = Stream_Pointer(s);
|
2021-10-14 09:42:49 +03:00
|
|
|
sub = Stream_StaticInit(&subbuffer, holdp, blockLength - 4);
|
2020-04-01 10:56:13 +03:00
|
|
|
if (!Stream_SafeSeek(s, blockLength - 4))
|
|
|
|
{
|
|
|
|
WLog_ERR(TAG, "gcc_read_server_data_blocks: stream too short");
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
offset += blockLength;
|
2011-07-10 05:04:57 +04:00
|
|
|
|
|
|
|
switch (type)
|
|
|
|
{
|
|
|
|
case SC_CORE:
|
2021-10-14 09:42:49 +03:00
|
|
|
if (!gcc_read_server_core_data(sub, mcs))
|
2011-09-05 22:02:52 +04:00
|
|
|
{
|
2019-11-06 17:24:51 +03:00
|
|
|
WLog_ERR(TAG, "gcc_read_server_data_blocks: gcc_read_server_core_data failed");
|
2012-10-09 10:31:28 +04:00
|
|
|
return FALSE;
|
2011-09-05 22:02:52 +04:00
|
|
|
}
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2011-07-10 05:04:57 +04:00
|
|
|
break;
|
|
|
|
|
|
|
|
case SC_SECURITY:
|
2021-10-14 09:42:49 +03:00
|
|
|
if (!gcc_read_server_security_data(sub, mcs))
|
2012-10-09 10:31:28 +04:00
|
|
|
return FALSE;
|
2011-07-10 05:04:57 +04:00
|
|
|
break;
|
|
|
|
|
|
|
|
case SC_NET:
|
2021-10-14 09:42:49 +03:00
|
|
|
if (!gcc_read_server_network_data(sub, mcs))
|
2011-09-05 22:02:52 +04:00
|
|
|
{
|
2016-09-20 09:58:04 +03:00
|
|
|
WLog_ERR(TAG,
|
|
|
|
"gcc_read_server_data_blocks: gcc_read_server_network_data failed");
|
2012-10-09 10:31:28 +04:00
|
|
|
return FALSE;
|
2011-09-05 22:02:52 +04:00
|
|
|
}
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2011-07-10 05:04:57 +04:00
|
|
|
break;
|
|
|
|
|
2014-01-24 03:01:31 +04:00
|
|
|
case SC_MCS_MSGCHANNEL:
|
2021-10-14 09:42:49 +03:00
|
|
|
if (!gcc_read_server_message_channel_data(sub, mcs))
|
2014-01-24 03:01:31 +04:00
|
|
|
{
|
2019-11-06 17:24:51 +03:00
|
|
|
WLog_ERR(
|
|
|
|
TAG,
|
|
|
|
"gcc_read_server_data_blocks: gcc_read_server_message_channel_data failed");
|
2014-01-24 03:01:31 +04:00
|
|
|
return FALSE;
|
|
|
|
}
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2014-01-24 03:01:31 +04:00
|
|
|
break;
|
|
|
|
|
|
|
|
case SC_MULTITRANSPORT:
|
2021-10-14 09:42:49 +03:00
|
|
|
if (!gcc_read_server_multitransport_channel_data(sub, mcs))
|
2014-01-24 03:01:31 +04:00
|
|
|
{
|
2019-11-06 17:24:51 +03:00
|
|
|
WLog_ERR(TAG, "gcc_read_server_data_blocks: "
|
|
|
|
"gcc_read_server_multitransport_channel_data failed");
|
2014-01-24 03:01:31 +04:00
|
|
|
return FALSE;
|
|
|
|
}
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2014-01-24 03:01:31 +04:00
|
|
|
break;
|
|
|
|
|
2011-07-10 05:04:57 +04:00
|
|
|
default:
|
2022-10-10 12:41:34 +03:00
|
|
|
WLog_ERR(TAG, "gcc_read_server_data_blocks: ignoring type=%s",
|
|
|
|
gcc_block_type_string(type, buffer, sizeof(buffer)));
|
2023-06-26 10:58:19 +03:00
|
|
|
winpr_HexDump(TAG, WLOG_TRACE, Stream_Pointer(sub), Stream_GetRemainingLength(sub));
|
2011-07-10 05:04:57 +04:00
|
|
|
break;
|
|
|
|
}
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2021-10-14 09:42:49 +03:00
|
|
|
rest = Stream_GetRemainingLength(sub);
|
2020-04-01 10:56:13 +03:00
|
|
|
if (rest > 0)
|
|
|
|
{
|
2022-10-10 12:41:34 +03:00
|
|
|
WLog_WARN(TAG, "gcc_read_server_data_blocks: ignoring %" PRIuz " bytes with type=%s",
|
|
|
|
rest, gcc_block_type_string(type, buffer, sizeof(buffer)));
|
2020-04-01 10:56:13 +03:00
|
|
|
}
|
2011-07-10 05:04:57 +04:00
|
|
|
}
|
2011-08-22 11:03:58 +04:00
|
|
|
|
2012-10-09 10:31:28 +04:00
|
|
|
return TRUE;
|
2011-07-10 05:04:57 +04:00
|
|
|
}
|
|
|
|
|
2022-12-12 14:17:18 +03:00
|
|
|
BOOL gcc_write_server_data_blocks(wStream* s, rdpMcs* mcs)
|
2011-08-19 19:56:47 +04:00
|
|
|
{
|
2022-12-12 14:17:18 +03:00
|
|
|
WINPR_ASSERT(s);
|
|
|
|
WINPR_ASSERT(mcs);
|
2022-11-24 12:54:23 +03:00
|
|
|
|
|
|
|
if (!gcc_write_server_core_data(s, mcs) || /* serverCoreData */
|
|
|
|
!gcc_write_server_network_data(s, mcs) || /* serverNetworkData */
|
|
|
|
!gcc_write_server_security_data(s, mcs) || /* serverSecurityData */
|
|
|
|
!gcc_write_server_message_channel_data(s, mcs)) /* serverMessageChannelData */
|
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
const rdpSettings* settings = mcs_get_const_settings(mcs);
|
|
|
|
WINPR_ASSERT(settings);
|
|
|
|
|
|
|
|
if (settings->SupportMultitransport && (settings->MultitransportFlags != 0))
|
|
|
|
/* serverMultitransportChannelData */
|
|
|
|
return gcc_write_server_multitransport_channel_data(s, mcs);
|
|
|
|
|
|
|
|
return TRUE;
|
2011-08-19 19:56:47 +04:00
|
|
|
}
|
|
|
|
|
2013-03-21 23:19:33 +04:00
|
|
|
BOOL gcc_read_user_data_header(wStream* s, UINT16* type, UINT16* length)
|
2011-07-10 05:04:57 +04:00
|
|
|
{
|
2022-12-12 14:17:18 +03:00
|
|
|
WINPR_ASSERT(s);
|
2022-04-19 15:29:17 +03:00
|
|
|
if (!Stream_CheckAndLogRequiredLength(TAG, s, 4))
|
2013-01-11 04:23:31 +04:00
|
|
|
return FALSE;
|
|
|
|
|
2019-11-06 17:24:51 +03:00
|
|
|
Stream_Read_UINT16(s, *type); /* type */
|
2013-05-09 00:09:16 +04:00
|
|
|
Stream_Read_UINT16(s, *length); /* length */
|
2011-08-22 11:03:58 +04:00
|
|
|
|
2022-04-19 15:29:17 +03:00
|
|
|
if ((*length < 4) || (!Stream_CheckAndLogRequiredLength(TAG, s, (size_t)(*length - 4))))
|
2012-10-09 10:31:28 +04:00
|
|
|
return FALSE;
|
2011-08-22 11:03:58 +04:00
|
|
|
|
2012-10-09 10:31:28 +04:00
|
|
|
return TRUE;
|
2011-07-10 01:28:30 +04:00
|
|
|
}
|
|
|
|
|
2011-07-06 02:26:12 +04:00
|
|
|
/**
|
2022-12-09 16:35:03 +03:00
|
|
|
* Write a user data header (TS_UD_HEADER).
|
|
|
|
* msdn{cc240509}
|
|
|
|
*
|
2011-07-06 02:26:12 +04:00
|
|
|
* @param s stream
|
|
|
|
* @param type data block type
|
|
|
|
* @param length data block length
|
2022-12-09 16:35:03 +03:00
|
|
|
*
|
|
|
|
* @return \b TRUE for success, \b FALSE otherwise
|
2011-07-06 02:26:12 +04:00
|
|
|
*/
|
|
|
|
|
2020-11-18 09:51:45 +03:00
|
|
|
BOOL gcc_write_user_data_header(wStream* s, UINT16 type, UINT16 length)
|
2011-07-06 02:26:12 +04:00
|
|
|
{
|
2022-12-12 14:17:18 +03:00
|
|
|
|
|
|
|
WINPR_ASSERT(s);
|
2020-11-18 09:51:45 +03:00
|
|
|
if (!Stream_EnsureRemainingCapacity(s, 4 + length))
|
|
|
|
return FALSE;
|
2019-11-06 17:24:51 +03:00
|
|
|
Stream_Write_UINT16(s, type); /* type */
|
2013-05-09 00:09:16 +04:00
|
|
|
Stream_Write_UINT16(s, length); /* length */
|
2020-11-18 09:51:45 +03:00
|
|
|
return TRUE;
|
2011-07-06 02:26:12 +04:00
|
|
|
}
|
|
|
|
|
2023-01-19 17:49:05 +03:00
|
|
|
static UINT32 filterAndLogEarlyServerCapabilityFlags(UINT32 flags)
|
2022-10-10 12:41:34 +03:00
|
|
|
{
|
2023-01-19 17:49:05 +03:00
|
|
|
const UINT32 mask =
|
|
|
|
(RNS_UD_SC_EDGE_ACTIONS_SUPPORTED_V1 | RNS_UD_SC_DYNAMIC_DST_SUPPORTED |
|
2023-01-20 11:03:16 +03:00
|
|
|
RNS_UD_SC_EDGE_ACTIONS_SUPPORTED_V2 | RNS_UD_SC_SKIP_CHANNELJOIN_SUPPORTED);
|
2023-01-19 17:49:05 +03:00
|
|
|
const UINT32 filtered = flags & mask;
|
|
|
|
const UINT32 unknown = flags & (~mask);
|
|
|
|
if (unknown != 0)
|
|
|
|
{
|
|
|
|
char buffer[256] = { 0 };
|
|
|
|
WLog_WARN(TAG,
|
|
|
|
"TS_UD_SC_CORE::EarlyCapabilityFlags [0x%08" PRIx32 " & 0x%08" PRIx32
|
|
|
|
" --> 0x%08" PRIx32 "] filtering %s, feature not implemented",
|
|
|
|
flags, ~mask, unknown,
|
|
|
|
rdp_early_server_caps_string(unknown, buffer, sizeof(buffer)));
|
|
|
|
}
|
|
|
|
return filtered;
|
|
|
|
}
|
|
|
|
|
|
|
|
static UINT32 earlyServerCapsFromSettings(const rdpSettings* settings)
|
|
|
|
{
|
2023-01-19 19:39:17 +03:00
|
|
|
UINT32 EarlyCapabilityFlags = 0;
|
|
|
|
|
|
|
|
if (settings->SupportEdgeActionV1)
|
|
|
|
EarlyCapabilityFlags |= RNS_UD_SC_EDGE_ACTIONS_SUPPORTED_V1;
|
|
|
|
if (settings->SupportDynamicTimeZone)
|
|
|
|
EarlyCapabilityFlags |= RNS_UD_SC_DYNAMIC_DST_SUPPORTED;
|
|
|
|
if (settings->SupportEdgeActionV2)
|
|
|
|
EarlyCapabilityFlags |= RNS_UD_SC_EDGE_ACTIONS_SUPPORTED_V2;
|
|
|
|
if (settings->SupportSkipChannelJoin)
|
|
|
|
EarlyCapabilityFlags |= RNS_UD_SC_SKIP_CHANNELJOIN_SUPPORTED;
|
|
|
|
|
2023-01-19 17:49:05 +03:00
|
|
|
return filterAndLogEarlyServerCapabilityFlags(EarlyCapabilityFlags);
|
|
|
|
}
|
|
|
|
|
|
|
|
static UINT16 filterAndLogEarlyClientCapabilityFlags(UINT32 flags)
|
|
|
|
{
|
|
|
|
const UINT32 mask =
|
|
|
|
(RNS_UD_CS_SUPPORT_ERRINFO_PDU | RNS_UD_CS_WANT_32BPP_SESSION |
|
|
|
|
RNS_UD_CS_SUPPORT_STATUSINFO_PDU | RNS_UD_CS_STRONG_ASYMMETRIC_KEYS |
|
|
|
|
RNS_UD_CS_VALID_CONNECTION_TYPE | RNS_UD_CS_SUPPORT_MONITOR_LAYOUT_PDU |
|
|
|
|
RNS_UD_CS_SUPPORT_NETCHAR_AUTODETECT | RNS_UD_CS_SUPPORT_DYNVC_GFX_PROTOCOL |
|
2023-01-20 11:03:16 +03:00
|
|
|
RNS_UD_CS_SUPPORT_DYNAMIC_TIME_ZONE | RNS_UD_CS_SUPPORT_HEARTBEAT_PDU |
|
|
|
|
RNS_UD_CS_SUPPORT_SKIP_CHANNELJOIN);
|
2023-01-19 17:49:05 +03:00
|
|
|
const UINT32 filtered = flags & mask;
|
|
|
|
const UINT32 unknown = flags & ~mask;
|
|
|
|
if (unknown != 0)
|
|
|
|
{
|
|
|
|
char buffer[256] = { 0 };
|
|
|
|
WLog_WARN(TAG,
|
|
|
|
"(TS_UD_CS_CORE)::EarlyCapabilityFlags [0x%08" PRIx32 " & 0x%08" PRIx32
|
|
|
|
" --> 0x%08" PRIx32 "] filtering %s, feature not implemented",
|
|
|
|
flags, ~mask, unknown,
|
|
|
|
rdp_early_client_caps_string(unknown, buffer, sizeof(buffer)));
|
|
|
|
}
|
|
|
|
return filtered;
|
|
|
|
}
|
|
|
|
|
|
|
|
static UINT16 earlyClientCapsFromSettings(const rdpSettings* settings)
|
|
|
|
{
|
2023-01-19 19:39:17 +03:00
|
|
|
UINT32 earlyCapabilityFlags = 0;
|
2022-10-10 12:41:34 +03:00
|
|
|
|
|
|
|
WINPR_ASSERT(settings);
|
|
|
|
if (settings->SupportErrorInfoPdu)
|
|
|
|
earlyCapabilityFlags |= RNS_UD_CS_SUPPORT_ERRINFO_PDU;
|
|
|
|
|
2023-01-19 19:39:17 +03:00
|
|
|
if (freerdp_settings_get_uint32(settings, FreeRDP_ColorDepth) == 32)
|
|
|
|
earlyCapabilityFlags |= RNS_UD_CS_WANT_32BPP_SESSION;
|
|
|
|
|
|
|
|
if (settings->SupportStatusInfoPdu)
|
|
|
|
earlyCapabilityFlags |= RNS_UD_CS_SUPPORT_STATUSINFO_PDU;
|
|
|
|
|
2022-10-10 12:41:34 +03:00
|
|
|
if (settings->ConnectionType)
|
|
|
|
earlyCapabilityFlags |= RNS_UD_CS_VALID_CONNECTION_TYPE;
|
|
|
|
|
2023-01-19 19:39:17 +03:00
|
|
|
if (settings->SupportMonitorLayoutPdu)
|
|
|
|
earlyCapabilityFlags |= RNS_UD_CS_SUPPORT_MONITOR_LAYOUT_PDU;
|
2022-10-10 12:41:34 +03:00
|
|
|
|
|
|
|
if (freerdp_settings_get_bool(settings, FreeRDP_NetworkAutoDetect))
|
|
|
|
earlyCapabilityFlags |= RNS_UD_CS_SUPPORT_NETCHAR_AUTODETECT;
|
|
|
|
|
|
|
|
if (settings->SupportGraphicsPipeline)
|
|
|
|
earlyCapabilityFlags |= RNS_UD_CS_SUPPORT_DYNVC_GFX_PROTOCOL;
|
|
|
|
|
|
|
|
if (settings->SupportDynamicTimeZone)
|
|
|
|
earlyCapabilityFlags |= RNS_UD_CS_SUPPORT_DYNAMIC_TIME_ZONE;
|
|
|
|
|
2023-01-19 19:39:17 +03:00
|
|
|
if (settings->SupportHeartbeatPdu)
|
|
|
|
earlyCapabilityFlags |= RNS_UD_CS_SUPPORT_HEARTBEAT_PDU;
|
2022-10-10 12:41:34 +03:00
|
|
|
|
2023-01-19 19:39:17 +03:00
|
|
|
if (settings->SupportAsymetricKeys)
|
|
|
|
earlyCapabilityFlags |= RNS_UD_CS_STRONG_ASYMMETRIC_KEYS;
|
|
|
|
|
|
|
|
if (settings->SupportSkipChannelJoin)
|
|
|
|
earlyCapabilityFlags |= RNS_UD_CS_SUPPORT_SKIP_CHANNELJOIN;
|
2022-10-10 12:41:34 +03:00
|
|
|
|
2023-01-19 17:49:05 +03:00
|
|
|
return filterAndLogEarlyClientCapabilityFlags(earlyCapabilityFlags);
|
2022-10-10 12:41:34 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static BOOL updateEarlyClientCaps(rdpSettings* settings, UINT32 earlyCapabilityFlags,
|
|
|
|
UINT32 connectionType)
|
|
|
|
{
|
|
|
|
WINPR_ASSERT(settings);
|
|
|
|
|
2023-01-19 19:39:17 +03:00
|
|
|
if (settings->SupportErrorInfoPdu)
|
|
|
|
settings->SupportErrorInfoPdu =
|
|
|
|
(earlyCapabilityFlags & RNS_UD_CS_SUPPORT_ERRINFO_PDU) ? TRUE : FALSE;
|
|
|
|
|
|
|
|
/* RNS_UD_CS_WANT_32BPP_SESSION is already handled in gcc_read_client_core_data:
|
|
|
|
*
|
|
|
|
* it is evaluated in combination with highColorDepth and the server side
|
|
|
|
* settings to determine the session color depth to use.
|
|
|
|
*/
|
|
|
|
|
|
|
|
if (settings->SupportStatusInfoPdu)
|
|
|
|
settings->SupportStatusInfoPdu =
|
|
|
|
(earlyCapabilityFlags & RNS_UD_CS_SUPPORT_STATUSINFO_PDU) ? TRUE : FALSE;
|
|
|
|
|
|
|
|
if (settings->SupportAsymetricKeys)
|
|
|
|
settings->SupportAsymetricKeys =
|
|
|
|
(earlyCapabilityFlags & RNS_UD_CS_STRONG_ASYMMETRIC_KEYS) ? TRUE : FALSE;
|
|
|
|
|
|
|
|
if (settings->NetworkAutoDetect)
|
|
|
|
settings->NetworkAutoDetect =
|
|
|
|
(earlyCapabilityFlags & RNS_UD_CS_SUPPORT_NETCHAR_AUTODETECT) ? TRUE : FALSE;
|
|
|
|
|
|
|
|
if (settings->SupportSkipChannelJoin)
|
|
|
|
settings->SupportSkipChannelJoin =
|
|
|
|
(earlyCapabilityFlags & RNS_UD_CS_SUPPORT_SKIP_CHANNELJOIN) ? TRUE : FALSE;
|
|
|
|
|
2022-10-10 12:41:34 +03:00
|
|
|
if (settings->SupportMonitorLayoutPdu)
|
|
|
|
settings->SupportMonitorLayoutPdu =
|
2023-01-19 19:39:17 +03:00
|
|
|
(earlyCapabilityFlags & RNS_UD_CS_SUPPORT_MONITOR_LAYOUT_PDU) ? TRUE : FALSE;
|
2022-10-10 12:41:34 +03:00
|
|
|
|
|
|
|
if (settings->SupportHeartbeatPdu)
|
|
|
|
settings->SupportHeartbeatPdu =
|
|
|
|
(earlyCapabilityFlags & RNS_UD_CS_SUPPORT_HEARTBEAT_PDU) ? TRUE : FALSE;
|
|
|
|
|
|
|
|
if (settings->SupportGraphicsPipeline)
|
|
|
|
settings->SupportGraphicsPipeline =
|
|
|
|
(earlyCapabilityFlags & RNS_UD_CS_SUPPORT_DYNVC_GFX_PROTOCOL) ? TRUE : FALSE;
|
|
|
|
|
|
|
|
if (settings->SupportDynamicTimeZone)
|
|
|
|
settings->SupportDynamicTimeZone =
|
|
|
|
(earlyCapabilityFlags & RNS_UD_CS_SUPPORT_DYNAMIC_TIME_ZONE) ? TRUE : FALSE;
|
|
|
|
|
2023-01-19 19:39:17 +03:00
|
|
|
if ((earlyCapabilityFlags & RNS_UD_CS_VALID_CONNECTION_TYPE) == 0)
|
2022-10-10 12:41:34 +03:00
|
|
|
connectionType = 0;
|
|
|
|
settings->ConnectionType = connectionType;
|
|
|
|
|
2023-01-19 17:49:05 +03:00
|
|
|
filterAndLogEarlyClientCapabilityFlags(earlyCapabilityFlags);
|
2022-10-10 12:41:34 +03:00
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
static BOOL updateEarlyServerCaps(rdpSettings* settings, UINT32 earlyCapabilityFlags,
|
|
|
|
UINT32 connectionType)
|
|
|
|
{
|
|
|
|
WINPR_ASSERT(settings);
|
|
|
|
|
2023-01-19 19:39:17 +03:00
|
|
|
settings->SupportEdgeActionV1 =
|
|
|
|
settings->SupportEdgeActionV1 &&
|
|
|
|
(earlyCapabilityFlags & RNS_UD_SC_EDGE_ACTIONS_SUPPORTED_V1)
|
|
|
|
? TRUE
|
|
|
|
: FALSE;
|
2022-10-10 12:41:34 +03:00
|
|
|
settings->SupportDynamicTimeZone =
|
|
|
|
settings->SupportDynamicTimeZone && (earlyCapabilityFlags & RNS_UD_SC_DYNAMIC_DST_SUPPORTED)
|
|
|
|
? TRUE
|
|
|
|
: FALSE;
|
2023-01-19 19:39:17 +03:00
|
|
|
settings->SupportEdgeActionV2 =
|
|
|
|
settings->SupportEdgeActionV2 &&
|
|
|
|
(earlyCapabilityFlags & RNS_UD_SC_EDGE_ACTIONS_SUPPORTED_V2)
|
|
|
|
? TRUE
|
|
|
|
: FALSE;
|
|
|
|
settings->SupportSkipChannelJoin =
|
|
|
|
settings->SupportSkipChannelJoin &&
|
|
|
|
(earlyCapabilityFlags & RNS_UD_SC_SKIP_CHANNELJOIN_SUPPORTED)
|
|
|
|
? TRUE
|
|
|
|
: FALSE;
|
|
|
|
|
2023-01-19 17:49:05 +03:00
|
|
|
filterAndLogEarlyServerCapabilityFlags(earlyCapabilityFlags);
|
2022-10-10 12:41:34 +03:00
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
2011-08-19 13:39:37 +04:00
|
|
|
/**
|
2022-12-09 16:35:03 +03:00
|
|
|
* Read a client core data block (TS_UD_CS_CORE).
|
|
|
|
* msdn{cc240510}
|
2011-08-19 13:39:37 +04:00
|
|
|
* @param s stream
|
2022-12-09 16:35:03 +03:00
|
|
|
* @param mcs The MCS instance
|
|
|
|
*
|
|
|
|
* @return \b TRUE for success, \b FALSE otherwise
|
2011-08-19 13:39:37 +04:00
|
|
|
*/
|
|
|
|
|
2023-06-26 12:38:11 +03:00
|
|
|
BOOL gcc_read_client_core_data(wStream* s, rdpMcs* mcs)
|
2011-08-19 13:39:37 +04:00
|
|
|
{
|
2022-10-10 12:41:34 +03:00
|
|
|
char buffer[2048] = { 0 };
|
2022-10-28 09:09:27 +03:00
|
|
|
char strbuffer[130] = { 0 };
|
2012-10-09 11:26:39 +04:00
|
|
|
UINT32 version;
|
2014-09-24 02:19:05 +04:00
|
|
|
BYTE connectionType = 0;
|
2014-09-22 19:38:33 +04:00
|
|
|
UINT32 clientColorDepth;
|
2012-10-09 11:01:37 +04:00
|
|
|
UINT16 colorDepth = 0;
|
|
|
|
UINT16 postBeta2ColorDepth = 0;
|
|
|
|
UINT16 highColorDepth = 0;
|
2012-10-09 11:26:39 +04:00
|
|
|
UINT32 serverSelectedProtocol = 0;
|
2022-12-12 14:17:18 +03:00
|
|
|
rdpSettings* settings = mcs_get_settings(mcs);
|
2021-09-03 12:31:21 +03:00
|
|
|
|
|
|
|
WINPR_ASSERT(s);
|
|
|
|
WINPR_ASSERT(settings);
|
2011-08-19 13:39:37 +04:00
|
|
|
|
2023-06-26 12:38:11 +03:00
|
|
|
size_t blockLength = Stream_GetRemainingLength(s);
|
2011-08-19 13:39:37 +04:00
|
|
|
/* Length of all required fields, until imeFileName */
|
|
|
|
if (blockLength < 128)
|
2012-10-09 10:31:28 +04:00
|
|
|
return FALSE;
|
2011-08-19 13:39:37 +04:00
|
|
|
|
2014-01-24 01:00:02 +04:00
|
|
|
Stream_Read_UINT32(s, version); /* version (4 bytes) */
|
2018-11-14 12:14:48 +03:00
|
|
|
settings->RdpVersion = rdp_version_common(version, settings->RdpVersion);
|
2019-11-06 17:24:51 +03:00
|
|
|
Stream_Read_UINT16(s, settings->DesktopWidth); /* DesktopWidth (2 bytes) */
|
2014-01-24 01:00:02 +04:00
|
|
|
Stream_Read_UINT16(s, settings->DesktopHeight); /* DesktopHeight (2 bytes) */
|
2019-11-06 17:24:51 +03:00
|
|
|
Stream_Read_UINT16(s, colorDepth); /* ColorDepth (2 bytes) */
|
2014-01-24 01:00:02 +04:00
|
|
|
Stream_Seek_UINT16(s); /* SASSequence (Secure Access Sequence) (2 bytes) */
|
|
|
|
Stream_Read_UINT32(s, settings->KeyboardLayout); /* KeyboardLayout (4 bytes) */
|
2019-11-06 17:24:51 +03:00
|
|
|
Stream_Read_UINT32(s, settings->ClientBuild); /* ClientBuild (4 bytes) */
|
2012-02-11 17:22:13 +04:00
|
|
|
|
2011-08-19 13:39:37 +04:00
|
|
|
/* clientName (32 bytes, null-terminated unicode, truncated to 15 characters) */
|
2022-10-28 09:09:27 +03:00
|
|
|
if (Stream_Read_UTF16_String_As_UTF8_Buffer(s, 32 / sizeof(WCHAR), strbuffer,
|
|
|
|
ARRAYSIZE(strbuffer)) < 0)
|
2016-03-03 18:21:12 +03:00
|
|
|
{
|
|
|
|
WLog_ERR(TAG, "failed to convert client host name");
|
|
|
|
return FALSE;
|
|
|
|
}
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2022-10-28 09:09:27 +03:00
|
|
|
if (!freerdp_settings_set_string(settings, FreeRDP_ClientHostname, strbuffer))
|
|
|
|
return FALSE;
|
|
|
|
|
2019-11-06 17:24:51 +03:00
|
|
|
Stream_Read_UINT32(s, settings->KeyboardType); /* KeyboardType (4 bytes) */
|
|
|
|
Stream_Read_UINT32(s, settings->KeyboardSubType); /* KeyboardSubType (4 bytes) */
|
|
|
|
Stream_Read_UINT32(s, settings->KeyboardFunctionKey); /* KeyboardFunctionKey (4 bytes) */
|
|
|
|
Stream_Seek(s, 64); /* imeFileName (64 bytes) */
|
2011-08-19 13:39:37 +04:00
|
|
|
blockLength -= 128;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* The following fields are all optional. If one field is present, all of the preceding
|
|
|
|
* fields MUST also be present. If one field is not present, all of the subsequent fields
|
|
|
|
* MUST NOT be present.
|
|
|
|
* We must check the bytes left before reading each field.
|
|
|
|
*/
|
|
|
|
|
|
|
|
do
|
|
|
|
{
|
2022-10-10 12:41:34 +03:00
|
|
|
UINT16 clientProductIdLen;
|
2011-08-19 13:39:37 +04:00
|
|
|
if (blockLength < 2)
|
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2014-01-24 01:00:02 +04:00
|
|
|
Stream_Read_UINT16(s, postBeta2ColorDepth); /* postBeta2ColorDepth (2 bytes) */
|
2011-08-19 13:39:37 +04:00
|
|
|
blockLength -= 2;
|
|
|
|
|
|
|
|
if (blockLength < 2)
|
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2022-10-10 12:41:34 +03:00
|
|
|
Stream_Read_UINT16(s, clientProductIdLen); /* clientProductID (2 bytes) */
|
2011-08-19 13:39:37 +04:00
|
|
|
blockLength -= 2;
|
|
|
|
|
|
|
|
if (blockLength < 4)
|
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2014-01-24 01:00:02 +04:00
|
|
|
Stream_Seek_UINT32(s); /* serialNumber (4 bytes) */
|
2011-08-19 13:39:37 +04:00
|
|
|
blockLength -= 4;
|
|
|
|
|
|
|
|
if (blockLength < 2)
|
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2014-01-24 01:00:02 +04:00
|
|
|
Stream_Read_UINT16(s, highColorDepth); /* highColorDepth (2 bytes) */
|
2011-08-19 13:39:37 +04:00
|
|
|
blockLength -= 2;
|
|
|
|
|
|
|
|
if (blockLength < 2)
|
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2023-04-13 13:39:59 +03:00
|
|
|
Stream_Read_UINT16(s, settings->SupportedColorDepths); /* supportedColorDepths (2 bytes) */
|
2011-08-19 13:39:37 +04:00
|
|
|
blockLength -= 2;
|
|
|
|
|
|
|
|
if (blockLength < 2)
|
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2023-01-19 19:39:17 +03:00
|
|
|
Stream_Read_UINT16(s, settings->EarlyCapabilityFlags); /* earlyCapabilityFlags (2 bytes) */
|
2011-08-19 13:39:37 +04:00
|
|
|
blockLength -= 2;
|
|
|
|
|
2016-03-03 18:21:12 +03:00
|
|
|
/* clientDigProductId (64 bytes): Contains a value that uniquely identifies the client */
|
|
|
|
|
2011-08-19 13:39:37 +04:00
|
|
|
if (blockLength < 64)
|
|
|
|
break;
|
2012-09-24 04:11:50 +04:00
|
|
|
|
2022-10-28 09:09:27 +03:00
|
|
|
if (Stream_Read_UTF16_String_As_UTF8_Buffer(s, 64 / sizeof(WCHAR), strbuffer,
|
|
|
|
ARRAYSIZE(strbuffer)) < 0)
|
2016-03-03 18:21:12 +03:00
|
|
|
{
|
|
|
|
WLog_ERR(TAG, "failed to convert the client product identifier");
|
|
|
|
return FALSE;
|
|
|
|
}
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2022-10-28 09:09:27 +03:00
|
|
|
if (!freerdp_settings_set_string(settings, FreeRDP_ClientProductId, strbuffer))
|
|
|
|
return FALSE;
|
2011-08-19 13:39:37 +04:00
|
|
|
blockLength -= 64;
|
|
|
|
|
|
|
|
if (blockLength < 1)
|
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2014-09-24 02:19:05 +04:00
|
|
|
Stream_Read_UINT8(s, connectionType); /* connectionType (1 byte) */
|
2011-08-19 13:39:37 +04:00
|
|
|
blockLength -= 1;
|
|
|
|
|
|
|
|
if (blockLength < 1)
|
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2014-01-24 01:00:02 +04:00
|
|
|
Stream_Seek_UINT8(s); /* pad1octet (1 byte) */
|
2011-08-19 13:39:37 +04:00
|
|
|
blockLength -= 1;
|
|
|
|
|
|
|
|
if (blockLength < 4)
|
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2019-11-06 17:24:51 +03:00
|
|
|
Stream_Read_UINT32(s, serverSelectedProtocol); /* serverSelectedProtocol (4 bytes) */
|
2014-01-24 01:00:02 +04:00
|
|
|
blockLength -= 4;
|
|
|
|
|
|
|
|
if (blockLength < 4)
|
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2019-11-06 17:24:51 +03:00
|
|
|
Stream_Read_UINT32(s, settings->DesktopPhysicalWidth); /* desktopPhysicalWidth (4 bytes) */
|
2014-01-24 01:00:02 +04:00
|
|
|
blockLength -= 4;
|
|
|
|
|
|
|
|
if (blockLength < 4)
|
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
|
|
|
Stream_Read_UINT32(s,
|
|
|
|
settings->DesktopPhysicalHeight); /* desktopPhysicalHeight (4 bytes) */
|
2014-01-24 01:00:02 +04:00
|
|
|
blockLength -= 4;
|
|
|
|
|
|
|
|
if (blockLength < 2)
|
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2019-11-06 17:24:51 +03:00
|
|
|
Stream_Read_UINT16(s, settings->DesktopOrientation); /* desktopOrientation (2 bytes) */
|
2014-01-24 01:00:02 +04:00
|
|
|
blockLength -= 2;
|
|
|
|
|
|
|
|
if (blockLength < 4)
|
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2019-11-06 17:24:51 +03:00
|
|
|
Stream_Read_UINT32(s, settings->DesktopScaleFactor); /* desktopScaleFactor (4 bytes) */
|
2014-01-24 01:00:02 +04:00
|
|
|
blockLength -= 4;
|
|
|
|
|
|
|
|
if (blockLength < 4)
|
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2019-11-06 17:24:51 +03:00
|
|
|
Stream_Read_UINT32(s, settings->DeviceScaleFactor); /* deviceScaleFactor (4 bytes) */
|
2011-08-19 13:39:37 +04:00
|
|
|
|
2022-10-10 12:41:34 +03:00
|
|
|
if (freerdp_settings_get_bool(settings, FreeRDP_TransportDumpReplay))
|
|
|
|
settings->SelectedProtocol = serverSelectedProtocol;
|
|
|
|
else if (settings->SelectedProtocol != serverSelectedProtocol)
|
2012-10-09 10:31:28 +04:00
|
|
|
return FALSE;
|
2019-11-06 17:24:51 +03:00
|
|
|
} while (0);
|
2011-08-19 13:39:37 +04:00
|
|
|
|
2011-08-19 14:11:33 +04:00
|
|
|
if (highColorDepth > 0)
|
2012-11-07 19:33:06 +04:00
|
|
|
{
|
2023-01-19 19:39:17 +03:00
|
|
|
if (settings->EarlyCapabilityFlags & RNS_UD_CS_WANT_32BPP_SESSION)
|
2014-09-22 19:38:33 +04:00
|
|
|
clientColorDepth = 32;
|
2013-01-28 02:17:04 +04:00
|
|
|
else
|
2014-09-22 19:38:33 +04:00
|
|
|
clientColorDepth = highColorDepth;
|
2012-11-07 19:33:06 +04:00
|
|
|
}
|
2011-08-19 14:11:33 +04:00
|
|
|
else if (postBeta2ColorDepth > 0)
|
|
|
|
{
|
|
|
|
switch (postBeta2ColorDepth)
|
|
|
|
{
|
|
|
|
case RNS_UD_COLOR_4BPP:
|
2014-09-22 19:38:33 +04:00
|
|
|
clientColorDepth = 4;
|
2011-08-19 14:11:33 +04:00
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2011-08-19 14:11:33 +04:00
|
|
|
case RNS_UD_COLOR_8BPP:
|
2014-09-22 19:38:33 +04:00
|
|
|
clientColorDepth = 8;
|
2011-08-19 14:11:33 +04:00
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2011-08-19 14:11:33 +04:00
|
|
|
case RNS_UD_COLOR_16BPP_555:
|
2014-09-22 19:38:33 +04:00
|
|
|
clientColorDepth = 15;
|
2011-08-19 14:11:33 +04:00
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2011-08-19 14:11:33 +04:00
|
|
|
case RNS_UD_COLOR_16BPP_565:
|
2014-09-22 19:38:33 +04:00
|
|
|
clientColorDepth = 16;
|
2011-08-19 14:11:33 +04:00
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2011-08-19 14:11:33 +04:00
|
|
|
case RNS_UD_COLOR_24BPP:
|
2014-09-22 19:38:33 +04:00
|
|
|
clientColorDepth = 24;
|
2011-08-19 14:11:33 +04:00
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2011-08-19 14:11:33 +04:00
|
|
|
default:
|
2012-10-09 10:31:28 +04:00
|
|
|
return FALSE;
|
2011-08-19 14:11:33 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
switch (colorDepth)
|
|
|
|
{
|
|
|
|
case RNS_UD_COLOR_4BPP:
|
2014-09-22 19:38:33 +04:00
|
|
|
clientColorDepth = 4;
|
2011-08-19 14:11:33 +04:00
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2011-08-19 14:11:33 +04:00
|
|
|
case RNS_UD_COLOR_8BPP:
|
2014-09-22 19:38:33 +04:00
|
|
|
clientColorDepth = 8;
|
2011-08-19 14:11:33 +04:00
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2011-08-19 14:11:33 +04:00
|
|
|
default:
|
2012-10-09 10:31:28 +04:00
|
|
|
return FALSE;
|
2011-08-19 14:11:33 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-02-11 17:22:13 +04:00
|
|
|
/*
|
2012-09-24 03:49:13 +04:00
|
|
|
* If we are in server mode, accept client's color depth only if
|
2012-02-11 17:22:13 +04:00
|
|
|
* it is smaller than ours. This is what Windows server does.
|
|
|
|
*/
|
2022-10-10 12:41:34 +03:00
|
|
|
if ((clientColorDepth < freerdp_settings_get_uint32(settings, FreeRDP_ColorDepth)) ||
|
|
|
|
!settings->ServerMode)
|
|
|
|
freerdp_settings_set_uint32(settings, FreeRDP_ColorDepth, clientColorDepth);
|
|
|
|
|
|
|
|
WLog_DBG(TAG, "Received EarlyCapabilityFlags=%s",
|
2023-01-19 19:39:17 +03:00
|
|
|
rdp_early_client_caps_string(settings->EarlyCapabilityFlags, buffer, sizeof(buffer)));
|
2023-01-19 17:49:05 +03:00
|
|
|
|
2023-01-19 19:39:17 +03:00
|
|
|
return updateEarlyClientCaps(settings, settings->EarlyCapabilityFlags, connectionType);
|
2011-08-19 13:39:37 +04:00
|
|
|
}
|
|
|
|
|
2011-07-05 06:02:00 +04:00
|
|
|
/**
|
2022-12-09 16:35:03 +03:00
|
|
|
* Write a client core data block (TS_UD_CS_CORE).
|
|
|
|
* msdn{cc240510}
|
|
|
|
* @param s The stream to write to
|
|
|
|
* @param mcs The MSC instance to get the data from
|
|
|
|
*
|
|
|
|
* @return \b TRUE for success, \b FALSE otherwise
|
2011-07-05 06:02:00 +04:00
|
|
|
*/
|
|
|
|
|
2022-10-10 12:41:34 +03:00
|
|
|
BOOL gcc_write_client_core_data(wStream* s, const rdpMcs* mcs)
|
2011-07-05 06:02:00 +04:00
|
|
|
{
|
2022-10-10 12:41:34 +03:00
|
|
|
char buffer[2048] = { 0 };
|
2023-04-13 13:52:38 +03:00
|
|
|
char dbuffer[2048] = { 0 };
|
2013-01-11 00:30:32 +04:00
|
|
|
WCHAR* clientName = NULL;
|
2022-10-28 09:09:27 +03:00
|
|
|
size_t clientNameLength;
|
2012-10-09 11:01:37 +04:00
|
|
|
BYTE connectionType;
|
2023-04-13 13:39:59 +03:00
|
|
|
HIGH_COLOR_DEPTH highColorDepth;
|
|
|
|
|
2012-10-09 11:01:37 +04:00
|
|
|
UINT16 earlyCapabilityFlags;
|
2013-01-11 00:30:32 +04:00
|
|
|
WCHAR* clientDigProductId = NULL;
|
2022-10-28 09:09:27 +03:00
|
|
|
size_t clientDigProductIdLength;
|
2022-12-12 14:17:18 +03:00
|
|
|
const rdpSettings* settings = mcs_get_const_settings(mcs);
|
2021-09-03 12:31:21 +03:00
|
|
|
|
|
|
|
WINPR_ASSERT(s);
|
|
|
|
WINPR_ASSERT(settings);
|
|
|
|
|
2023-04-13 13:39:59 +03:00
|
|
|
const UINT16 SupportedColorDepths =
|
|
|
|
freerdp_settings_get_uint16(settings, FreeRDP_SupportedColorDepths);
|
|
|
|
const UINT32 ColorDepth = freerdp_settings_get_uint32(settings, FreeRDP_ColorDepth);
|
|
|
|
|
2020-11-18 09:51:45 +03:00
|
|
|
if (!gcc_write_user_data_header(s, CS_CORE, 234))
|
|
|
|
return FALSE;
|
2022-10-28 09:09:27 +03:00
|
|
|
clientName = ConvertUtf8ToWCharAlloc(settings->ClientHostname, &clientNameLength);
|
|
|
|
clientDigProductId =
|
|
|
|
ConvertUtf8ToWCharAlloc(settings->ClientProductId, &clientDigProductIdLength);
|
|
|
|
|
2019-11-06 17:24:51 +03:00
|
|
|
Stream_Write_UINT32(s, settings->RdpVersion); /* Version */
|
|
|
|
Stream_Write_UINT16(s, settings->DesktopWidth); /* DesktopWidth */
|
2013-05-09 00:09:16 +04:00
|
|
|
Stream_Write_UINT16(s, settings->DesktopHeight); /* DesktopHeight */
|
2016-09-20 09:58:04 +03:00
|
|
|
Stream_Write_UINT16(s,
|
|
|
|
RNS_UD_COLOR_8BPP); /* ColorDepth, ignored because of postBeta2ColorDepth */
|
2019-11-06 17:24:51 +03:00
|
|
|
Stream_Write_UINT16(s, RNS_UD_SAS_DEL); /* SASSequence (Secure Access Sequence) */
|
2013-05-09 00:09:16 +04:00
|
|
|
Stream_Write_UINT32(s, settings->KeyboardLayout); /* KeyboardLayout */
|
2019-11-06 17:24:51 +03:00
|
|
|
Stream_Write_UINT32(s, settings->ClientBuild); /* ClientBuild */
|
2011-07-06 02:26:12 +04:00
|
|
|
|
2011-07-08 08:37:25 +04:00
|
|
|
/* clientName (32 bytes, null-terminated unicode, truncated to 15 characters) */
|
2012-09-24 03:49:13 +04:00
|
|
|
|
2012-12-18 17:55:43 +04:00
|
|
|
if (clientNameLength >= 16)
|
2011-07-08 08:37:25 +04:00
|
|
|
{
|
2012-12-18 17:55:43 +04:00
|
|
|
clientNameLength = 16;
|
2014-09-22 19:38:33 +04:00
|
|
|
clientName[clientNameLength - 1] = 0;
|
2011-07-08 08:37:25 +04:00
|
|
|
}
|
2020-11-18 09:51:45 +03:00
|
|
|
if (!Stream_EnsureRemainingCapacity(s, 32 + 12 + 64 + 8))
|
|
|
|
return FALSE;
|
2012-09-24 03:49:13 +04:00
|
|
|
|
2013-05-09 00:09:16 +04:00
|
|
|
Stream_Write(s, clientName, (clientNameLength * 2));
|
2013-05-09 00:27:21 +04:00
|
|
|
Stream_Zero(s, 32 - (clientNameLength * 2));
|
2012-10-09 07:21:26 +04:00
|
|
|
free(clientName);
|
2019-11-06 17:24:51 +03:00
|
|
|
Stream_Write_UINT32(s, settings->KeyboardType); /* KeyboardType */
|
|
|
|
Stream_Write_UINT32(s, settings->KeyboardSubType); /* KeyboardSubType */
|
2013-05-09 00:09:16 +04:00
|
|
|
Stream_Write_UINT32(s, settings->KeyboardFunctionKey); /* KeyboardFunctionKey */
|
2019-11-06 17:24:51 +03:00
|
|
|
Stream_Zero(s, 64); /* imeFileName */
|
|
|
|
Stream_Write_UINT16(s, RNS_UD_COLOR_8BPP); /* postBeta2ColorDepth */
|
|
|
|
Stream_Write_UINT16(s, 1); /* clientProductID */
|
2013-05-09 00:09:16 +04:00
|
|
|
Stream_Write_UINT32(s, 0); /* serialNumber (should be initialized to 0) */
|
2023-04-13 13:39:59 +03:00
|
|
|
highColorDepth = ColorDepthToHighColor(ColorDepth);
|
2023-01-19 17:49:05 +03:00
|
|
|
earlyCapabilityFlags = earlyClientCapsFromSettings(settings);
|
2011-07-06 02:26:12 +04:00
|
|
|
|
2014-09-25 01:23:12 +04:00
|
|
|
connectionType = settings->ConnectionType;
|
2011-12-16 21:14:16 +04:00
|
|
|
|
2020-11-18 09:51:45 +03:00
|
|
|
if (!Stream_EnsureRemainingCapacity(s, 6))
|
|
|
|
return FALSE;
|
2017-02-09 13:50:46 +03:00
|
|
|
|
2023-04-13 13:52:38 +03:00
|
|
|
WLog_DBG(TAG, "Sending highColorDepth=%s, supportedColorDepths=%s, earlyCapabilityFlags=%s",
|
|
|
|
HighColorToString(highColorDepth),
|
|
|
|
freerdp_supported_color_depths_string(SupportedColorDepths, dbuffer, sizeof(dbuffer)),
|
2023-01-19 17:49:05 +03:00
|
|
|
rdp_early_client_caps_string(earlyCapabilityFlags, buffer, sizeof(buffer)));
|
2019-11-06 17:24:51 +03:00
|
|
|
Stream_Write_UINT16(s, highColorDepth); /* highColorDepth */
|
2023-04-13 13:39:59 +03:00
|
|
|
Stream_Write_UINT16(s, SupportedColorDepths); /* supportedColorDepths */
|
2013-05-09 00:09:16 +04:00
|
|
|
Stream_Write_UINT16(s, earlyCapabilityFlags); /* earlyCapabilityFlags */
|
2011-07-08 08:37:25 +04:00
|
|
|
|
2012-12-18 17:55:43 +04:00
|
|
|
/* clientDigProductId (64 bytes, null-terminated unicode, truncated to 31 characters) */
|
|
|
|
if (clientDigProductIdLength >= 32)
|
2011-07-08 08:37:25 +04:00
|
|
|
{
|
2012-12-18 17:55:43 +04:00
|
|
|
clientDigProductIdLength = 32;
|
2014-09-22 19:38:33 +04:00
|
|
|
clientDigProductId[clientDigProductIdLength - 1] = 0;
|
2011-07-08 08:37:25 +04:00
|
|
|
}
|
2011-07-06 02:26:12 +04:00
|
|
|
|
2020-11-18 09:51:45 +03:00
|
|
|
if (!Stream_EnsureRemainingCapacity(s, 64 + 24))
|
|
|
|
return FALSE;
|
2016-09-20 09:58:04 +03:00
|
|
|
Stream_Write(s, clientDigProductId, (clientDigProductIdLength * 2));
|
|
|
|
Stream_Zero(s, 64 - (clientDigProductIdLength * 2));
|
|
|
|
free(clientDigProductId);
|
2019-11-06 17:24:51 +03:00
|
|
|
Stream_Write_UINT8(s, connectionType); /* connectionType */
|
|
|
|
Stream_Write_UINT8(s, 0); /* pad1octet */
|
|
|
|
Stream_Write_UINT32(s, settings->SelectedProtocol); /* serverSelectedProtocol */
|
|
|
|
Stream_Write_UINT32(s, settings->DesktopPhysicalWidth); /* desktopPhysicalWidth */
|
|
|
|
Stream_Write_UINT32(s, settings->DesktopPhysicalHeight); /* desktopPhysicalHeight */
|
|
|
|
Stream_Write_UINT16(s, settings->DesktopOrientation); /* desktopOrientation */
|
|
|
|
Stream_Write_UINT32(s, settings->DesktopScaleFactor); /* desktopScaleFactor */
|
|
|
|
Stream_Write_UINT32(s, settings->DeviceScaleFactor); /* deviceScaleFactor */
|
2020-11-18 09:51:45 +03:00
|
|
|
return TRUE;
|
2011-07-05 06:02:00 +04:00
|
|
|
}
|
|
|
|
|
2014-02-14 02:50:38 +04:00
|
|
|
BOOL gcc_read_server_core_data(wStream* s, rdpMcs* mcs)
|
2011-07-10 05:04:57 +04:00
|
|
|
{
|
2018-11-14 12:14:48 +03:00
|
|
|
UINT32 serverVersion;
|
2022-12-12 14:17:18 +03:00
|
|
|
rdpSettings* settings = mcs_get_settings(mcs);
|
2021-09-03 12:31:21 +03:00
|
|
|
|
|
|
|
WINPR_ASSERT(s);
|
|
|
|
WINPR_ASSERT(settings);
|
2011-07-10 05:04:57 +04:00
|
|
|
|
2022-04-19 15:29:17 +03:00
|
|
|
if (!Stream_CheckAndLogRequiredLength(TAG, s, 4))
|
2013-01-11 04:23:31 +04:00
|
|
|
return FALSE;
|
2014-01-24 22:03:37 +04:00
|
|
|
|
2018-11-14 12:14:48 +03:00
|
|
|
Stream_Read_UINT32(s, serverVersion); /* version */
|
|
|
|
settings->RdpVersion = rdp_version_common(serverVersion, settings->RdpVersion);
|
2011-08-22 11:03:58 +04:00
|
|
|
|
2014-01-24 22:03:37 +04:00
|
|
|
if (Stream_GetRemainingLength(s) >= 4)
|
|
|
|
{
|
2022-10-10 12:41:34 +03:00
|
|
|
Stream_Read_UINT32(s, settings->RequestedProtocols); /* clientRequestedProtocols */
|
2014-01-24 22:03:37 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
if (Stream_GetRemainingLength(s) >= 4)
|
|
|
|
{
|
2022-10-10 12:41:34 +03:00
|
|
|
char buffer[2048] = { 0 };
|
|
|
|
|
2023-01-19 19:39:17 +03:00
|
|
|
Stream_Read_UINT32(s, settings->EarlyCapabilityFlags); /* earlyCapabilityFlags */
|
|
|
|
WLog_DBG(
|
|
|
|
TAG, "Received EarlyCapabilityFlags=%s",
|
|
|
|
rdp_early_client_caps_string(settings->EarlyCapabilityFlags, buffer, sizeof(buffer)));
|
2014-01-24 22:03:37 +04:00
|
|
|
}
|
|
|
|
|
2023-01-19 19:39:17 +03:00
|
|
|
return updateEarlyServerCaps(settings, settings->EarlyCapabilityFlags,
|
|
|
|
settings->ConnectionType);
|
2011-07-10 05:04:57 +04:00
|
|
|
}
|
|
|
|
|
2022-12-12 14:17:18 +03:00
|
|
|
/* TODO: This function modifies rdpMcs
|
|
|
|
* TODO: Split this out of this function
|
|
|
|
*/
|
|
|
|
BOOL gcc_write_server_core_data(wStream* s, rdpMcs* mcs)
|
2011-08-19 19:56:47 +04:00
|
|
|
{
|
2022-12-12 14:17:18 +03:00
|
|
|
rdpSettings* settings = mcs_get_settings(mcs);
|
2021-09-03 12:31:21 +03:00
|
|
|
|
|
|
|
WINPR_ASSERT(s);
|
|
|
|
WINPR_ASSERT(settings);
|
2014-02-14 02:50:38 +04:00
|
|
|
|
2020-11-18 09:51:45 +03:00
|
|
|
if (!gcc_write_user_data_header(s, SC_CORE, 16))
|
2015-04-01 16:11:57 +03:00
|
|
|
return FALSE;
|
|
|
|
|
2023-01-19 17:49:05 +03:00
|
|
|
const UINT32 EarlyCapabilityFlags = earlyServerCapsFromSettings(settings);
|
2019-11-06 17:24:51 +03:00
|
|
|
Stream_Write_UINT32(s, settings->RdpVersion); /* version (4 bytes) */
|
|
|
|
Stream_Write_UINT32(s, settings->RequestedProtocols); /* clientRequestedProtocols (4 bytes) */
|
2023-01-19 17:49:05 +03:00
|
|
|
Stream_Write_UINT32(s, EarlyCapabilityFlags); /* earlyCapabilityFlags (4 bytes) */
|
2015-04-01 16:11:57 +03:00
|
|
|
return TRUE;
|
2011-08-19 19:56:47 +04:00
|
|
|
}
|
|
|
|
|
2011-08-19 13:39:37 +04:00
|
|
|
/**
|
2022-12-09 16:35:03 +03:00
|
|
|
* Read a client security data block (TS_UD_CS_SEC).
|
|
|
|
* msdn{cc240511}
|
2011-08-19 13:39:37 +04:00
|
|
|
* @param s stream
|
2022-12-09 16:35:03 +03:00
|
|
|
* @param mcs MCS instance
|
|
|
|
*
|
|
|
|
* @return \b TRUE for success, \b FALSE otherwise
|
2011-08-19 13:39:37 +04:00
|
|
|
*/
|
|
|
|
|
2023-06-26 12:38:11 +03:00
|
|
|
BOOL gcc_read_client_security_data(wStream* s, rdpMcs* mcs)
|
2011-08-19 13:39:37 +04:00
|
|
|
{
|
2022-12-12 14:17:18 +03:00
|
|
|
rdpSettings* settings = mcs_get_settings(mcs);
|
2021-09-03 12:31:21 +03:00
|
|
|
|
|
|
|
WINPR_ASSERT(s);
|
|
|
|
WINPR_ASSERT(settings);
|
2014-02-14 02:50:38 +04:00
|
|
|
|
2023-06-26 12:38:11 +03:00
|
|
|
const size_t blockLength = Stream_GetRemainingLength(s);
|
2011-08-19 14:11:33 +04:00
|
|
|
if (blockLength < 8)
|
2012-10-09 10:31:28 +04:00
|
|
|
return FALSE;
|
2011-08-19 14:11:33 +04:00
|
|
|
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
if (settings->UseRdpSecurityLayer)
|
2012-01-25 20:04:19 +04:00
|
|
|
{
|
2013-05-09 00:09:16 +04:00
|
|
|
Stream_Read_UINT32(s, settings->EncryptionMethods); /* encryptionMethods */
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2023-01-19 16:31:45 +03:00
|
|
|
if (settings->EncryptionMethods == ENCRYPTION_METHOD_NONE)
|
2013-05-09 00:09:16 +04:00
|
|
|
Stream_Read_UINT32(s, settings->EncryptionMethods); /* extEncryptionMethods */
|
2014-04-02 16:17:39 +04:00
|
|
|
else
|
|
|
|
Stream_Seek(s, 4);
|
2012-01-25 20:04:19 +04:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2013-04-30 06:35:15 +04:00
|
|
|
Stream_Seek(s, 8);
|
2012-01-25 20:04:19 +04:00
|
|
|
}
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2012-10-09 10:31:28 +04:00
|
|
|
return TRUE;
|
2011-08-19 13:39:37 +04:00
|
|
|
}
|
|
|
|
|
2011-07-05 06:02:00 +04:00
|
|
|
/**
|
2022-12-09 16:35:03 +03:00
|
|
|
* Write a client security data block (TS_UD_CS_SEC).
|
|
|
|
* msdn{cc240511}
|
2011-07-05 06:02:00 +04:00
|
|
|
* @param s stream
|
2022-12-09 16:35:03 +03:00
|
|
|
* @param mcs The MCS instance
|
|
|
|
*
|
|
|
|
* @return \b TRUE for success, \b FALSE otherwise
|
2011-07-05 06:02:00 +04:00
|
|
|
*/
|
|
|
|
|
2020-11-18 09:51:45 +03:00
|
|
|
BOOL gcc_write_client_security_data(wStream* s, const rdpMcs* mcs)
|
2011-07-05 06:02:00 +04:00
|
|
|
{
|
2022-12-12 14:17:18 +03:00
|
|
|
const rdpSettings* settings = mcs_get_const_settings(mcs);
|
2021-09-03 12:31:21 +03:00
|
|
|
|
|
|
|
WINPR_ASSERT(s);
|
|
|
|
WINPR_ASSERT(settings);
|
|
|
|
|
2020-11-18 09:51:45 +03:00
|
|
|
if (!gcc_write_user_data_header(s, CS_SECURITY, 12))
|
|
|
|
return FALSE;
|
2011-07-06 02:26:12 +04:00
|
|
|
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
if (settings->UseRdpSecurityLayer)
|
2011-07-06 02:26:12 +04:00
|
|
|
{
|
2013-05-09 00:09:16 +04:00
|
|
|
Stream_Write_UINT32(s, settings->EncryptionMethods); /* encryptionMethods */
|
2019-11-06 17:24:51 +03:00
|
|
|
Stream_Write_UINT32(s, 0); /* extEncryptionMethods */
|
2011-07-06 02:26:12 +04:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* French locale, disable encryption */
|
2019-11-06 17:24:51 +03:00
|
|
|
Stream_Write_UINT32(s, 0); /* encryptionMethods */
|
2013-05-09 00:09:16 +04:00
|
|
|
Stream_Write_UINT32(s, settings->EncryptionMethods); /* extEncryptionMethods */
|
2011-07-06 02:26:12 +04:00
|
|
|
}
|
2020-11-18 09:51:45 +03:00
|
|
|
return TRUE;
|
2011-07-05 06:02:00 +04:00
|
|
|
}
|
|
|
|
|
2014-02-14 02:50:38 +04:00
|
|
|
BOOL gcc_read_server_security_data(wStream* s, rdpMcs* mcs)
|
2011-07-10 05:04:57 +04:00
|
|
|
{
|
2023-01-19 16:31:45 +03:00
|
|
|
const BYTE* data = NULL;
|
|
|
|
UINT32 length = 0;
|
2021-09-06 12:01:36 +03:00
|
|
|
BOOL validCryptoConfig = FALSE;
|
2023-01-19 16:31:45 +03:00
|
|
|
UINT32 EncryptionMethod = 0;
|
|
|
|
UINT32 EncryptionLevel = 0;
|
2022-12-12 14:17:18 +03:00
|
|
|
rdpSettings* settings = mcs_get_settings(mcs);
|
2021-09-03 12:31:21 +03:00
|
|
|
|
|
|
|
WINPR_ASSERT(s);
|
2021-09-06 12:01:36 +03:00
|
|
|
WINPR_ASSERT(settings);
|
2011-07-10 05:04:57 +04:00
|
|
|
|
2022-04-19 15:29:17 +03:00
|
|
|
if (!Stream_CheckAndLogRequiredLength(TAG, s, 8))
|
2013-01-11 04:23:31 +04:00
|
|
|
return FALSE;
|
2014-02-14 02:50:38 +04:00
|
|
|
|
2023-01-19 16:31:45 +03:00
|
|
|
Stream_Read_UINT32(s, EncryptionMethod); /* encryptionMethod */
|
|
|
|
Stream_Read_UINT32(s, EncryptionLevel); /* encryptionLevel */
|
2011-07-10 05:04:57 +04:00
|
|
|
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
/* Only accept valid/known encryption methods */
|
2023-01-19 16:31:45 +03:00
|
|
|
switch (EncryptionMethod)
|
2011-07-10 05:04:57 +04:00
|
|
|
{
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
case ENCRYPTION_METHOD_NONE:
|
|
|
|
WLog_DBG(TAG, "Server rdp encryption method: NONE");
|
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
case ENCRYPTION_METHOD_40BIT:
|
|
|
|
WLog_DBG(TAG, "Server rdp encryption method: 40BIT");
|
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
case ENCRYPTION_METHOD_56BIT:
|
|
|
|
WLog_DBG(TAG, "Server rdp encryption method: 56BIT");
|
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
case ENCRYPTION_METHOD_128BIT:
|
|
|
|
WLog_DBG(TAG, "Server rdp encryption method: 128BIT");
|
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
case ENCRYPTION_METHOD_FIPS:
|
|
|
|
WLog_DBG(TAG, "Server rdp encryption method: FIPS");
|
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
default:
|
2023-01-19 16:31:45 +03:00
|
|
|
WLog_ERR(TAG, "Received unknown encryption method %08" PRIX32 "", EncryptionMethod);
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
2023-01-19 16:31:45 +03:00
|
|
|
if (settings->UseRdpSecurityLayer && !(settings->EncryptionMethods & EncryptionMethod))
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
{
|
2019-11-06 17:24:51 +03:00
|
|
|
WLog_WARN(TAG, "Server uses non-advertised encryption method 0x%08" PRIX32 "",
|
2023-01-19 16:31:45 +03:00
|
|
|
EncryptionMethod);
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
/* FIXME: Should we return FALSE; in this case ?? */
|
|
|
|
}
|
|
|
|
|
2023-01-19 16:31:45 +03:00
|
|
|
settings->EncryptionMethods = EncryptionMethod;
|
|
|
|
settings->EncryptionLevel = EncryptionLevel;
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
/* Verify encryption level/method combinations according to MS-RDPBCGR Section 5.3.2 */
|
|
|
|
switch (settings->EncryptionLevel)
|
|
|
|
{
|
|
|
|
case ENCRYPTION_LEVEL_NONE:
|
|
|
|
if (settings->EncryptionMethods == ENCRYPTION_METHOD_NONE)
|
|
|
|
{
|
|
|
|
validCryptoConfig = TRUE;
|
|
|
|
}
|
2016-09-20 09:58:04 +03:00
|
|
|
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
case ENCRYPTION_LEVEL_FIPS:
|
|
|
|
if (settings->EncryptionMethods == ENCRYPTION_METHOD_FIPS)
|
|
|
|
{
|
|
|
|
validCryptoConfig = TRUE;
|
|
|
|
}
|
2016-09-20 09:58:04 +03:00
|
|
|
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
case ENCRYPTION_LEVEL_LOW:
|
|
|
|
case ENCRYPTION_LEVEL_HIGH:
|
|
|
|
case ENCRYPTION_LEVEL_CLIENT_COMPATIBLE:
|
|
|
|
if (settings->EncryptionMethods == ENCRYPTION_METHOD_40BIT ||
|
|
|
|
settings->EncryptionMethods == ENCRYPTION_METHOD_56BIT ||
|
|
|
|
settings->EncryptionMethods == ENCRYPTION_METHOD_128BIT ||
|
|
|
|
settings->EncryptionMethods == ENCRYPTION_METHOD_FIPS)
|
|
|
|
{
|
|
|
|
validCryptoConfig = TRUE;
|
|
|
|
}
|
2016-09-20 09:58:04 +03:00
|
|
|
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
default:
|
2019-11-06 17:24:51 +03:00
|
|
|
WLog_ERR(TAG, "Received unknown encryption level 0x%08" PRIX32 "",
|
2016-09-20 09:58:04 +03:00
|
|
|
settings->EncryptionLevel);
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!validCryptoConfig)
|
|
|
|
{
|
2016-09-20 09:58:04 +03:00
|
|
|
WLog_ERR(TAG,
|
2019-11-06 17:24:51 +03:00
|
|
|
"Received invalid cryptographic configuration (level=0x%08" PRIX32
|
|
|
|
" method=0x%08" PRIX32 ")",
|
2016-09-20 09:58:04 +03:00
|
|
|
settings->EncryptionLevel, settings->EncryptionMethods);
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (settings->EncryptionLevel == ENCRYPTION_LEVEL_NONE)
|
|
|
|
{
|
|
|
|
/* serverRandomLen and serverCertLen must not be present */
|
|
|
|
settings->UseRdpSecurityLayer = FALSE;
|
2012-10-09 10:31:28 +04:00
|
|
|
return TRUE;
|
2011-07-10 05:04:57 +04:00
|
|
|
}
|
|
|
|
|
2022-04-19 15:29:17 +03:00
|
|
|
if (!Stream_CheckAndLogRequiredLength(TAG, s, 8))
|
2013-01-11 04:23:31 +04:00
|
|
|
return FALSE;
|
2014-02-14 02:50:38 +04:00
|
|
|
|
2019-11-06 17:24:51 +03:00
|
|
|
Stream_Read_UINT32(s, settings->ServerRandomLength); /* serverRandomLen */
|
2013-05-09 00:09:16 +04:00
|
|
|
Stream_Read_UINT32(s, settings->ServerCertificateLength); /* serverCertLen */
|
2011-08-22 11:03:58 +04:00
|
|
|
|
2017-05-29 11:50:22 +03:00
|
|
|
if ((settings->ServerRandomLength == 0) || (settings->ServerCertificateLength == 0))
|
2013-01-11 04:23:31 +04:00
|
|
|
return FALSE;
|
|
|
|
|
2022-04-19 15:29:17 +03:00
|
|
|
if (!Stream_CheckAndLogRequiredLength(TAG, s, settings->ServerRandomLength))
|
2012-10-09 10:31:28 +04:00
|
|
|
return FALSE;
|
2011-07-10 05:04:57 +04:00
|
|
|
|
2014-05-10 00:37:47 +04:00
|
|
|
/* serverRandom */
|
2021-10-18 15:13:22 +03:00
|
|
|
if (!freerdp_settings_set_pointer_len(settings, FreeRDP_ServerRandom, NULL,
|
2022-06-23 08:57:38 +03:00
|
|
|
settings->ServerRandomLength))
|
2017-05-29 11:50:22 +03:00
|
|
|
goto fail;
|
2012-01-14 23:42:36 +04:00
|
|
|
|
2016-09-20 09:58:04 +03:00
|
|
|
Stream_Read(s, settings->ServerRandom, settings->ServerRandomLength);
|
2017-05-29 11:50:22 +03:00
|
|
|
|
2022-04-19 15:29:17 +03:00
|
|
|
if (!Stream_CheckAndLogRequiredLength(TAG, s, settings->ServerCertificateLength))
|
2017-05-29 11:50:22 +03:00
|
|
|
goto fail;
|
|
|
|
|
2014-05-10 00:37:47 +04:00
|
|
|
/* serverCertificate */
|
2021-10-18 15:13:22 +03:00
|
|
|
if (!freerdp_settings_set_pointer_len(settings, FreeRDP_ServerCertificate, NULL,
|
2022-06-23 08:57:38 +03:00
|
|
|
settings->ServerCertificateLength))
|
2017-05-29 11:50:22 +03:00
|
|
|
goto fail;
|
2011-08-22 11:03:58 +04:00
|
|
|
|
2016-09-20 09:58:04 +03:00
|
|
|
Stream_Read(s, settings->ServerCertificate, settings->ServerCertificateLength);
|
2021-10-18 15:13:22 +03:00
|
|
|
|
2014-05-10 00:37:47 +04:00
|
|
|
data = settings->ServerCertificate;
|
|
|
|
length = settings->ServerCertificateLength;
|
2017-11-14 15:58:31 +03:00
|
|
|
|
2023-02-03 13:53:49 +03:00
|
|
|
if (!freerdp_certificate_read_server_cert(settings->RdpServerCertificate, data, length))
|
2017-05-29 11:50:22 +03:00
|
|
|
goto fail;
|
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
fail:
|
2017-11-14 15:58:31 +03:00
|
|
|
free(settings->ServerRandom);
|
|
|
|
free(settings->ServerCertificate);
|
2017-05-29 11:50:22 +03:00
|
|
|
settings->ServerRandom = NULL;
|
|
|
|
settings->ServerCertificate = NULL;
|
|
|
|
return FALSE;
|
2011-07-10 05:04:57 +04:00
|
|
|
}
|
|
|
|
|
2023-01-20 13:03:05 +03:00
|
|
|
static BOOL gcc_update_server_random(rdpSettings* settings)
|
|
|
|
{
|
|
|
|
const size_t length = 32;
|
|
|
|
WINPR_ASSERT(settings);
|
|
|
|
if (!freerdp_settings_set_pointer_len(settings, FreeRDP_ServerRandom, NULL, length))
|
|
|
|
return FALSE;
|
2023-01-30 14:18:35 +03:00
|
|
|
BYTE* data = freerdp_settings_get_pointer_writable(settings, FreeRDP_ServerRandom);
|
2023-01-20 13:03:05 +03:00
|
|
|
if (!data)
|
|
|
|
return FALSE;
|
|
|
|
winpr_RAND(data, length);
|
|
|
|
return TRUE;
|
|
|
|
}
|
2012-01-25 20:00:40 +04:00
|
|
|
|
2022-12-12 14:17:18 +03:00
|
|
|
/* TODO: This function does manipulate data in rdpMcs
|
|
|
|
* TODO: Split this out of this function
|
|
|
|
*/
|
|
|
|
BOOL gcc_write_server_security_data(wStream* s, rdpMcs* mcs)
|
2011-08-19 19:56:47 +04:00
|
|
|
{
|
2022-12-12 14:17:18 +03:00
|
|
|
rdpSettings* settings = mcs_get_settings(mcs);
|
2021-09-03 12:31:21 +03:00
|
|
|
|
|
|
|
WINPR_ASSERT(s);
|
|
|
|
WINPR_ASSERT(settings);
|
2012-01-25 20:00:40 +04:00
|
|
|
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
/**
|
|
|
|
* Re: settings->EncryptionLevel:
|
|
|
|
* This is configured/set by the server implementation and serves the same
|
|
|
|
* purpose as the "Encryption Level" setting in the RDP-Tcp configuration
|
|
|
|
* dialog of Microsoft's Remote Desktop Session Host Configuration.
|
|
|
|
* Re: settings->EncryptionMethods:
|
|
|
|
* at this point this setting contains the client's supported encryption
|
|
|
|
* methods we've received in gcc_read_client_security_data()
|
|
|
|
*/
|
|
|
|
|
|
|
|
if (!settings->UseRdpSecurityLayer)
|
2012-01-30 00:05:34 +04:00
|
|
|
{
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
/* TLS/NLA is used: disable rdp style encryption */
|
2012-11-07 20:02:46 +04:00
|
|
|
settings->EncryptionLevel = ENCRYPTION_LEVEL_NONE;
|
2012-01-25 20:00:40 +04:00
|
|
|
}
|
2023-05-22 22:02:44 +03:00
|
|
|
else
|
2012-01-25 20:00:40 +04:00
|
|
|
{
|
2023-05-22 22:02:44 +03:00
|
|
|
/* verify server encryption level value */
|
|
|
|
switch (settings->EncryptionLevel)
|
|
|
|
{
|
|
|
|
case ENCRYPTION_LEVEL_NONE:
|
|
|
|
WLog_INFO(TAG, "Active rdp encryption level: NONE");
|
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2023-05-22 22:02:44 +03:00
|
|
|
case ENCRYPTION_LEVEL_FIPS:
|
|
|
|
WLog_INFO(TAG, "Active rdp encryption level: FIPS Compliant");
|
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2023-05-22 22:02:44 +03:00
|
|
|
case ENCRYPTION_LEVEL_HIGH:
|
|
|
|
WLog_INFO(TAG, "Active rdp encryption level: HIGH");
|
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2023-05-22 22:02:44 +03:00
|
|
|
case ENCRYPTION_LEVEL_LOW:
|
|
|
|
WLog_INFO(TAG, "Active rdp encryption level: LOW");
|
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2023-05-22 22:02:44 +03:00
|
|
|
case ENCRYPTION_LEVEL_CLIENT_COMPATIBLE:
|
|
|
|
WLog_INFO(TAG, "Active rdp encryption level: CLIENT-COMPATIBLE");
|
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2023-05-22 22:02:44 +03:00
|
|
|
default:
|
|
|
|
WLog_ERR(TAG, "Invalid server encryption level 0x%08" PRIX32 "",
|
|
|
|
settings->EncryptionLevel);
|
|
|
|
WLog_ERR(TAG, "Switching to encryption level CLIENT-COMPATIBLE");
|
|
|
|
settings->EncryptionLevel = ENCRYPTION_LEVEL_CLIENT_COMPATIBLE;
|
|
|
|
}
|
2012-01-25 20:00:40 +04:00
|
|
|
}
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
|
|
|
|
/* choose rdp encryption method based on server level and client methods */
|
|
|
|
switch (settings->EncryptionLevel)
|
2014-04-02 16:17:39 +04:00
|
|
|
{
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
case ENCRYPTION_LEVEL_NONE:
|
|
|
|
/* The only valid method is NONE in this case */
|
|
|
|
settings->EncryptionMethods = ENCRYPTION_METHOD_NONE;
|
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
case ENCRYPTION_LEVEL_FIPS:
|
2016-09-20 09:58:04 +03:00
|
|
|
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
/* The only valid method is FIPS in this case */
|
|
|
|
if (!(settings->EncryptionMethods & ENCRYPTION_METHOD_FIPS))
|
|
|
|
{
|
2019-11-06 17:24:51 +03:00
|
|
|
WLog_WARN(TAG, "client does not support FIPS as required by server configuration");
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
}
|
2016-09-20 09:58:04 +03:00
|
|
|
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
settings->EncryptionMethods = ENCRYPTION_METHOD_FIPS;
|
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
case ENCRYPTION_LEVEL_HIGH:
|
2016-09-20 09:58:04 +03:00
|
|
|
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
/* Maximum key strength supported by the server must be used (128 bit)*/
|
|
|
|
if (!(settings->EncryptionMethods & ENCRYPTION_METHOD_128BIT))
|
|
|
|
{
|
2019-11-06 17:24:51 +03:00
|
|
|
WLog_WARN(TAG, "client does not support 128 bit encryption method as required by "
|
|
|
|
"server configuration");
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
}
|
2016-09-20 09:58:04 +03:00
|
|
|
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
settings->EncryptionMethods = ENCRYPTION_METHOD_128BIT;
|
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
case ENCRYPTION_LEVEL_LOW:
|
|
|
|
case ENCRYPTION_LEVEL_CLIENT_COMPATIBLE:
|
2016-09-20 09:58:04 +03:00
|
|
|
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
/* Maximum key strength supported by the client must be used */
|
|
|
|
if (settings->EncryptionMethods & ENCRYPTION_METHOD_128BIT)
|
|
|
|
settings->EncryptionMethods = ENCRYPTION_METHOD_128BIT;
|
|
|
|
else if (settings->EncryptionMethods & ENCRYPTION_METHOD_56BIT)
|
|
|
|
settings->EncryptionMethods = ENCRYPTION_METHOD_56BIT;
|
|
|
|
else if (settings->EncryptionMethods & ENCRYPTION_METHOD_40BIT)
|
|
|
|
settings->EncryptionMethods = ENCRYPTION_METHOD_40BIT;
|
|
|
|
else if (settings->EncryptionMethods & ENCRYPTION_METHOD_FIPS)
|
|
|
|
settings->EncryptionMethods = ENCRYPTION_METHOD_FIPS;
|
|
|
|
else
|
|
|
|
{
|
|
|
|
WLog_WARN(TAG, "client has not announced any supported encryption methods");
|
|
|
|
settings->EncryptionMethods = ENCRYPTION_METHOD_128BIT;
|
|
|
|
}
|
2016-09-20 09:58:04 +03:00
|
|
|
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
default:
|
|
|
|
WLog_ERR(TAG, "internal error: unknown encryption level");
|
2015-04-01 16:11:57 +03:00
|
|
|
return FALSE;
|
2014-04-02 16:17:39 +04:00
|
|
|
}
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
|
|
|
|
/* log selected encryption method */
|
2023-05-22 22:02:44 +03:00
|
|
|
if (settings->UseRdpSecurityLayer)
|
2012-01-25 20:00:40 +04:00
|
|
|
{
|
2023-05-22 22:02:44 +03:00
|
|
|
switch (settings->EncryptionMethods)
|
|
|
|
{
|
|
|
|
case ENCRYPTION_METHOD_NONE:
|
|
|
|
WLog_INFO(TAG, "Selected rdp encryption method: NONE");
|
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2023-05-22 22:02:44 +03:00
|
|
|
case ENCRYPTION_METHOD_40BIT:
|
|
|
|
WLog_INFO(TAG, "Selected rdp encryption method: 40BIT");
|
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2023-05-22 22:02:44 +03:00
|
|
|
case ENCRYPTION_METHOD_56BIT:
|
|
|
|
WLog_INFO(TAG, "Selected rdp encryption method: 56BIT");
|
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2023-05-22 22:02:44 +03:00
|
|
|
case ENCRYPTION_METHOD_128BIT:
|
|
|
|
WLog_INFO(TAG, "Selected rdp encryption method: 128BIT");
|
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2023-05-22 22:02:44 +03:00
|
|
|
case ENCRYPTION_METHOD_FIPS:
|
|
|
|
WLog_INFO(TAG, "Selected rdp encryption method: FIPS");
|
|
|
|
break;
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2023-05-22 22:02:44 +03:00
|
|
|
default:
|
|
|
|
WLog_ERR(TAG, "internal error: unknown encryption method");
|
|
|
|
return FALSE;
|
|
|
|
}
|
2012-01-25 20:00:40 +04:00
|
|
|
}
|
|
|
|
|
2023-01-20 13:03:05 +03:00
|
|
|
const size_t posHeader = Stream_GetPosition(s);
|
|
|
|
if (!gcc_write_user_data_header(s, SC_SECURITY, 12))
|
2015-04-01 16:11:57 +03:00
|
|
|
return FALSE;
|
2012-01-25 20:00:40 +04:00
|
|
|
|
2013-05-09 00:09:16 +04:00
|
|
|
Stream_Write_UINT32(s, settings->EncryptionMethods); /* encryptionMethod */
|
2019-11-06 17:24:51 +03:00
|
|
|
Stream_Write_UINT32(s, settings->EncryptionLevel); /* encryptionLevel */
|
2012-01-30 00:05:34 +04:00
|
|
|
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
if (settings->EncryptionMethods == ENCRYPTION_METHOD_NONE)
|
2015-04-01 16:11:57 +03:00
|
|
|
return TRUE;
|
2023-01-20 13:03:05 +03:00
|
|
|
if (!gcc_update_server_random(settings))
|
|
|
|
return FALSE;
|
2012-01-25 20:00:40 +04:00
|
|
|
|
2023-01-28 14:48:00 +03:00
|
|
|
if (!Stream_EnsureRemainingCapacity(s, sizeof(UINT32) + settings->ServerRandomLength))
|
|
|
|
return FALSE;
|
2023-01-20 13:03:05 +03:00
|
|
|
Stream_Write_UINT32(s, settings->ServerRandomLength); /* serverRandomLen */
|
|
|
|
const size_t posCertLen = Stream_GetPosition(s);
|
|
|
|
Stream_Seek_UINT32(s); /* serverCertLen */
|
2023-01-28 14:48:00 +03:00
|
|
|
Stream_Write(s, settings->ServerRandom, settings->ServerRandomLength);
|
2017-11-14 15:58:31 +03:00
|
|
|
|
2023-02-03 13:53:49 +03:00
|
|
|
const SSIZE_T len = freerdp_certificate_write_server_cert(
|
2023-01-30 14:18:35 +03:00
|
|
|
settings->RdpServerCertificate, CERT_TEMPORARILY_ISSUED | CERT_CHAIN_VERSION_1, s);
|
2023-01-20 13:03:05 +03:00
|
|
|
if (len < 0)
|
2017-09-26 10:20:38 +03:00
|
|
|
return FALSE;
|
2023-01-20 13:03:05 +03:00
|
|
|
const size_t end = Stream_GetPosition(s);
|
|
|
|
Stream_SetPosition(s, posHeader);
|
|
|
|
if (!gcc_write_user_data_header(s, SC_SECURITY, end - posHeader))
|
|
|
|
return FALSE;
|
|
|
|
Stream_SetPosition(s, posCertLen);
|
|
|
|
WINPR_ASSERT(len <= UINT32_MAX);
|
|
|
|
Stream_Write_UINT32(s, (UINT32)len);
|
|
|
|
Stream_SetPosition(s, end);
|
2015-04-01 16:11:57 +03:00
|
|
|
return TRUE;
|
2011-08-19 19:56:47 +04:00
|
|
|
}
|
|
|
|
|
2011-08-19 13:39:37 +04:00
|
|
|
/**
|
2022-12-09 16:35:03 +03:00
|
|
|
* Read a client network data block (TS_UD_CS_NET).
|
|
|
|
* msdn{cc240512}
|
|
|
|
*
|
2011-08-19 13:39:37 +04:00
|
|
|
* @param s stream
|
2022-12-09 16:35:03 +03:00
|
|
|
* @param mcs The MCS instance
|
|
|
|
*
|
|
|
|
* @return \b TRUE for success, \b FALSE otherwise
|
2011-08-19 13:39:37 +04:00
|
|
|
*/
|
|
|
|
|
2023-06-26 12:38:11 +03:00
|
|
|
BOOL gcc_read_client_network_data(wStream* s, rdpMcs* mcs)
|
2011-08-19 13:39:37 +04:00
|
|
|
{
|
2014-02-11 07:12:13 +04:00
|
|
|
UINT32 i;
|
2011-08-19 14:11:33 +04:00
|
|
|
|
2022-12-12 14:17:18 +03:00
|
|
|
WINPR_ASSERT(s);
|
|
|
|
WINPR_ASSERT(mcs);
|
2023-06-26 12:38:11 +03:00
|
|
|
|
|
|
|
const size_t blockLength = Stream_GetRemainingLength(s);
|
2011-08-19 14:11:33 +04:00
|
|
|
if (blockLength < 4)
|
2012-10-09 10:31:28 +04:00
|
|
|
return FALSE;
|
2011-08-19 14:11:33 +04:00
|
|
|
|
2014-02-16 01:32:38 +04:00
|
|
|
Stream_Read_UINT32(s, mcs->channelCount); /* channelCount */
|
2014-02-11 07:12:13 +04:00
|
|
|
|
2014-02-16 01:32:38 +04:00
|
|
|
if (blockLength < 4 + mcs->channelCount * 12)
|
2012-10-09 10:31:28 +04:00
|
|
|
return FALSE;
|
Standard RDP Security Layer Levels/Method Overhaul
[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
2014-12-12 04:17:12 +03:00
|
|
|
|
2017-11-23 18:18:44 +03:00
|
|
|
if (mcs->channelCount > CHANNEL_MAX_COUNT)
|
2012-10-09 10:31:28 +04:00
|
|
|
return FALSE;
|
2011-08-19 14:11:33 +04:00
|
|
|
|
|
|
|
/* channelDefArray */
|
2014-02-16 01:32:38 +04:00
|
|
|
for (i = 0; i < mcs->channelCount; i++)
|
2011-08-19 14:11:33 +04:00
|
|
|
{
|
2016-05-30 15:40:23 +03:00
|
|
|
/**
|
|
|
|
* CHANNEL_DEF
|
|
|
|
* - name: an 8-byte array containing a null-terminated collection
|
|
|
|
* of seven ANSI characters that uniquely identify the channel.
|
|
|
|
* - options: a 32-bit, unsigned integer. Channel option flags
|
|
|
|
*/
|
2021-08-24 15:09:40 +03:00
|
|
|
rdpMcsChannel* channel = &mcs->channels[i];
|
|
|
|
Stream_Read(s, channel->Name, CHANNEL_NAME_LEN + 1); /* name (8 bytes) */
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2021-08-24 15:09:40 +03:00
|
|
|
if (!memchr(channel->Name, 0, CHANNEL_NAME_LEN + 1))
|
2016-05-30 15:40:23 +03:00
|
|
|
{
|
2019-11-06 17:24:51 +03:00
|
|
|
WLog_ERR(
|
|
|
|
TAG,
|
|
|
|
"protocol violation: received a static channel name with missing null-termination");
|
2016-05-30 15:40:23 +03:00
|
|
|
return FALSE;
|
|
|
|
}
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2021-08-24 15:09:40 +03:00
|
|
|
Stream_Read_UINT32(s, channel->options); /* options (4 bytes) */
|
|
|
|
channel->ChannelId = mcs->baseChannelId++;
|
2011-08-19 14:11:33 +04:00
|
|
|
}
|
|
|
|
|
2012-10-09 10:31:28 +04:00
|
|
|
return TRUE;
|
2011-08-19 13:39:37 +04:00
|
|
|
}
|
|
|
|
|
2011-07-05 06:02:00 +04:00
|
|
|
/**
|
2022-12-09 16:35:03 +03:00
|
|
|
* Write a client network data block (TS_UD_CS_NET).
|
|
|
|
* msdn{cc240512}
|
2011-07-05 06:02:00 +04:00
|
|
|
* @param s stream
|
2022-12-09 16:35:03 +03:00
|
|
|
* @param mcs The MCS to use
|
|
|
|
*
|
|
|
|
* @return \b TRUE for success, \b FALSE otherwise
|
2011-07-05 06:02:00 +04:00
|
|
|
*/
|
|
|
|
|
2020-11-18 09:51:45 +03:00
|
|
|
BOOL gcc_write_client_network_data(wStream* s, const rdpMcs* mcs)
|
2011-07-05 06:02:00 +04:00
|
|
|
{
|
2014-02-11 07:12:13 +04:00
|
|
|
UINT32 i;
|
2012-10-09 11:01:37 +04:00
|
|
|
UINT16 length;
|
2022-12-12 14:17:18 +03:00
|
|
|
WINPR_ASSERT(s);
|
|
|
|
WINPR_ASSERT(mcs);
|
2014-02-16 01:32:38 +04:00
|
|
|
if (mcs->channelCount > 0)
|
2011-07-06 02:26:12 +04:00
|
|
|
{
|
2014-02-16 01:32:38 +04:00
|
|
|
length = mcs->channelCount * 12 + 8;
|
2020-11-18 09:51:45 +03:00
|
|
|
if (!gcc_write_user_data_header(s, CS_NET, length))
|
|
|
|
return FALSE;
|
2014-02-16 01:32:38 +04:00
|
|
|
Stream_Write_UINT32(s, mcs->channelCount); /* channelCount */
|
2011-07-06 02:26:12 +04:00
|
|
|
|
|
|
|
/* channelDefArray */
|
2014-02-16 01:32:38 +04:00
|
|
|
for (i = 0; i < mcs->channelCount; i++)
|
2011-07-06 02:26:12 +04:00
|
|
|
{
|
|
|
|
/* CHANNEL_DEF */
|
2021-08-24 15:09:40 +03:00
|
|
|
rdpMcsChannel* channel = &mcs->channels[i];
|
|
|
|
Stream_Write(s, channel->Name, CHANNEL_NAME_LEN + 1); /* name (8 bytes) */
|
|
|
|
Stream_Write_UINT32(s, channel->options); /* options (4 bytes) */
|
2011-07-06 02:26:12 +04:00
|
|
|
}
|
|
|
|
}
|
2020-11-18 09:51:45 +03:00
|
|
|
return TRUE;
|
2011-07-05 06:02:00 +04:00
|
|
|
}
|
|
|
|
|
2014-02-14 02:50:38 +04:00
|
|
|
BOOL gcc_read_server_network_data(wStream* s, rdpMcs* mcs)
|
2011-07-10 05:04:57 +04:00
|
|
|
{
|
2012-10-09 11:01:37 +04:00
|
|
|
UINT16 channelId;
|
2014-02-16 01:32:38 +04:00
|
|
|
UINT16 MCSChannelId;
|
|
|
|
UINT16 channelCount;
|
2022-10-10 12:41:34 +03:00
|
|
|
UINT32 parsedChannelCount;
|
2022-12-12 14:17:18 +03:00
|
|
|
WINPR_ASSERT(s);
|
|
|
|
WINPR_ASSERT(mcs);
|
2022-04-19 15:29:17 +03:00
|
|
|
if (!Stream_CheckAndLogRequiredLength(TAG, s, 4))
|
2013-01-11 04:23:31 +04:00
|
|
|
return FALSE;
|
2014-01-24 01:00:02 +04:00
|
|
|
|
2013-05-09 00:09:16 +04:00
|
|
|
Stream_Read_UINT16(s, MCSChannelId); /* MCSChannelId */
|
|
|
|
Stream_Read_UINT16(s, channelCount); /* channelCount */
|
2014-02-16 01:32:38 +04:00
|
|
|
parsedChannelCount = channelCount;
|
2014-01-24 01:00:02 +04:00
|
|
|
|
2014-02-16 01:32:38 +04:00
|
|
|
if (channelCount != mcs->channelCount)
|
2011-07-10 05:04:57 +04:00
|
|
|
{
|
2019-11-06 17:24:51 +03:00
|
|
|
WLog_ERR(TAG, "requested %" PRIu32 " channels, got %" PRIu16 " instead", mcs->channelCount,
|
|
|
|
channelCount);
|
2013-11-29 02:17:21 +04:00
|
|
|
|
2014-01-24 01:00:02 +04:00
|
|
|
/* we ensure that the response is not bigger than the request */
|
2014-02-16 01:32:38 +04:00
|
|
|
|
2022-10-10 12:41:34 +03:00
|
|
|
mcs->channelCount = channelCount;
|
2011-07-10 05:04:57 +04:00
|
|
|
}
|
|
|
|
|
2023-01-24 16:53:36 +03:00
|
|
|
if (!Stream_CheckAndLogRequiredLengthOfSize(TAG, s, channelCount, 2ull))
|
2013-01-11 04:23:31 +04:00
|
|
|
return FALSE;
|
|
|
|
|
2023-01-20 11:03:16 +03:00
|
|
|
for (UINT32 i = 0; i < parsedChannelCount; i++)
|
2011-07-10 05:04:57 +04:00
|
|
|
{
|
2021-08-24 15:09:40 +03:00
|
|
|
rdpMcsChannel* channel = &mcs->channels[i];
|
2013-05-09 00:09:16 +04:00
|
|
|
Stream_Read_UINT16(s, channelId); /* channelId */
|
2021-08-24 15:09:40 +03:00
|
|
|
channel->ChannelId = channelId;
|
2011-07-10 05:04:57 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
if (channelCount % 2 == 1)
|
2013-05-09 01:48:30 +04:00
|
|
|
return Stream_SafeSeek(s, 2); /* padding */
|
2011-08-22 11:03:58 +04:00
|
|
|
|
2012-10-09 10:31:28 +04:00
|
|
|
return TRUE;
|
2011-07-10 05:04:57 +04:00
|
|
|
}
|
|
|
|
|
2020-11-18 09:51:45 +03:00
|
|
|
BOOL gcc_write_server_network_data(wStream* s, const rdpMcs* mcs)
|
2011-08-19 19:56:47 +04:00
|
|
|
{
|
2014-02-11 07:12:13 +04:00
|
|
|
UINT32 i;
|
2022-12-12 14:17:18 +03:00
|
|
|
WINPR_ASSERT(s);
|
|
|
|
WINPR_ASSERT(mcs);
|
2020-11-18 09:51:45 +03:00
|
|
|
const size_t payloadLen = 8 + mcs->channelCount * 2 + (mcs->channelCount % 2 == 1 ? 2 : 0);
|
2015-04-01 16:11:57 +03:00
|
|
|
|
2020-11-18 09:51:45 +03:00
|
|
|
if (!gcc_write_user_data_header(s, SC_NET, payloadLen))
|
2015-04-01 16:11:57 +03:00
|
|
|
return FALSE;
|
2011-08-19 19:56:47 +04:00
|
|
|
|
2013-05-09 00:09:16 +04:00
|
|
|
Stream_Write_UINT16(s, MCS_GLOBAL_CHANNEL_ID); /* MCSChannelId */
|
2019-11-06 17:24:51 +03:00
|
|
|
Stream_Write_UINT16(s, mcs->channelCount); /* channelCount */
|
2011-08-19 19:56:47 +04:00
|
|
|
|
2014-02-16 01:32:38 +04:00
|
|
|
for (i = 0; i < mcs->channelCount; i++)
|
2011-08-19 19:56:47 +04:00
|
|
|
{
|
2021-08-24 15:09:40 +03:00
|
|
|
const rdpMcsChannel* channel = &mcs->channels[i];
|
|
|
|
Stream_Write_UINT16(s, channel->ChannelId);
|
2011-08-19 19:56:47 +04:00
|
|
|
}
|
|
|
|
|
2014-02-16 01:32:38 +04:00
|
|
|
if (mcs->channelCount % 2 == 1)
|
2013-05-09 00:09:16 +04:00
|
|
|
Stream_Write_UINT16(s, 0);
|
2016-09-20 09:58:04 +03:00
|
|
|
|
2015-04-01 16:11:57 +03:00
|
|
|
return TRUE;
|
2011-08-19 19:56:47 +04:00
|
|
|
}
|
|
|
|
|
2011-08-19 13:39:37 +04:00
|
|
|
/**
|
2022-12-09 16:35:03 +03:00
|
|
|
* Read a client cluster data block (TS_UD_CS_CLUSTER).
|
|
|
|
* msdn{cc240514}
|
2011-08-19 13:39:37 +04:00
|
|
|
* @param s stream
|
2022-12-09 16:35:03 +03:00
|
|
|
* @param mcs The MCS instance
|
|
|
|
*
|
|
|
|
* @return \b TRUE for success, \b FALSE otherwise
|
2011-08-19 13:39:37 +04:00
|
|
|
*/
|
|
|
|
|
2023-06-26 12:38:11 +03:00
|
|
|
BOOL gcc_read_client_cluster_data(wStream* s, rdpMcs* mcs)
|
2011-08-19 13:39:37 +04:00
|
|
|
{
|
2023-01-21 11:45:11 +03:00
|
|
|
char buffer[128] = { 0 };
|
2014-01-24 01:00:02 +04:00
|
|
|
UINT32 redirectedSessionId;
|
2022-12-12 14:17:18 +03:00
|
|
|
rdpSettings* settings = mcs_get_settings(mcs);
|
2021-09-03 12:31:21 +03:00
|
|
|
|
|
|
|
WINPR_ASSERT(s);
|
|
|
|
WINPR_ASSERT(settings);
|
2011-08-19 14:11:33 +04:00
|
|
|
|
2023-06-26 12:38:11 +03:00
|
|
|
const size_t blockLength = Stream_GetRemainingLength(s);
|
2014-01-24 01:00:02 +04:00
|
|
|
if (blockLength < 8)
|
2012-10-09 10:31:28 +04:00
|
|
|
return FALSE;
|
2011-08-19 14:11:33 +04:00
|
|
|
|
2022-10-10 12:41:34 +03:00
|
|
|
Stream_Read_UINT32(s, settings->ClusterInfoFlags); /* flags */
|
|
|
|
Stream_Read_UINT32(s, redirectedSessionId); /* redirectedSessionId */
|
2011-08-19 14:11:33 +04:00
|
|
|
|
2023-01-23 14:03:18 +03:00
|
|
|
WLog_VRB(TAG, "read ClusterInfoFlags=%s, RedirectedSessionId=0x%08" PRIx32,
|
2023-01-21 11:45:11 +03:00
|
|
|
rdp_cluster_info_flags_to_string(settings->ClusterInfoFlags, buffer, sizeof(buffer)),
|
|
|
|
redirectedSessionId);
|
2022-10-10 12:41:34 +03:00
|
|
|
if (settings->ClusterInfoFlags & REDIRECTED_SESSIONID_FIELD_VALID)
|
2014-01-24 01:00:02 +04:00
|
|
|
settings->RedirectedSessionId = redirectedSessionId;
|
2022-10-10 12:41:34 +03:00
|
|
|
|
2023-07-04 10:26:52 +03:00
|
|
|
settings->ConsoleSession =
|
|
|
|
(settings->ClusterInfoFlags & REDIRECTED_SESSIONID_FIELD_VALID) ? TRUE : FALSE;
|
|
|
|
settings->RedirectSmartCards =
|
|
|
|
(settings->ClusterInfoFlags & REDIRECTED_SMARTCARD) ? TRUE : FALSE;
|
2011-08-19 14:11:33 +04:00
|
|
|
|
2014-09-19 06:18:58 +04:00
|
|
|
if (blockLength != 8)
|
|
|
|
{
|
2018-10-24 18:24:35 +03:00
|
|
|
if (Stream_GetRemainingLength(s) >= (size_t)(blockLength - 8))
|
2014-09-19 06:18:58 +04:00
|
|
|
{
|
|
|
|
/* The old Microsoft Mac RDP client can send a pad here */
|
|
|
|
Stream_Seek(s, (blockLength - 8));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-10-09 10:31:28 +04:00
|
|
|
return TRUE;
|
2011-08-19 13:39:37 +04:00
|
|
|
}
|
|
|
|
|
2011-07-05 06:02:00 +04:00
|
|
|
/**
|
2022-12-09 16:35:03 +03:00
|
|
|
* Write a client cluster data block (TS_UD_CS_CLUSTER).
|
|
|
|
* msdn{cc240514}
|
2011-07-05 06:02:00 +04:00
|
|
|
* @param s stream
|
2022-12-09 16:35:03 +03:00
|
|
|
* @param mcs The MCS instance
|
|
|
|
*
|
|
|
|
* @return \b TRUE for success, \b FALSE otherwise
|
2011-07-05 06:02:00 +04:00
|
|
|
*/
|
|
|
|
|
2020-11-18 09:51:45 +03:00
|
|
|
BOOL gcc_write_client_cluster_data(wStream* s, const rdpMcs* mcs)
|
2011-07-05 06:02:00 +04:00
|
|
|
{
|
2023-01-21 11:45:11 +03:00
|
|
|
char buffer[128] = { 0 };
|
2012-10-09 11:26:39 +04:00
|
|
|
UINT32 flags;
|
2022-12-12 14:17:18 +03:00
|
|
|
const rdpSettings* settings = mcs_get_const_settings(mcs);
|
2021-09-03 12:31:21 +03:00
|
|
|
|
|
|
|
WINPR_ASSERT(s);
|
|
|
|
WINPR_ASSERT(settings);
|
|
|
|
|
2020-11-18 09:51:45 +03:00
|
|
|
if (!gcc_write_user_data_header(s, CS_CLUSTER, 12))
|
|
|
|
return FALSE;
|
2022-10-10 12:41:34 +03:00
|
|
|
flags = settings->ClusterInfoFlags;
|
2011-07-05 06:02:00 +04:00
|
|
|
|
2012-11-08 00:13:14 +04:00
|
|
|
if (settings->ConsoleSession || settings->RedirectedSessionId)
|
2011-07-06 02:26:12 +04:00
|
|
|
flags |= REDIRECTED_SESSIONID_FIELD_VALID;
|
|
|
|
|
2023-01-21 11:45:11 +03:00
|
|
|
if (settings->RedirectSmartCards && settings->SmartcardLogon)
|
2019-11-26 18:57:21 +03:00
|
|
|
flags |= REDIRECTED_SMARTCARD;
|
|
|
|
|
2023-02-20 15:26:44 +03:00
|
|
|
if (flags & REDIRECTION_SUPPORTED)
|
|
|
|
{
|
|
|
|
/* REDIRECTION_VERSION6 requires multitransport enabled.
|
|
|
|
* if we run without that use REDIRECTION_VERSION5 */
|
|
|
|
if (freerdp_settings_get_bool(settings, FreeRDP_SupportMultitransport))
|
2023-02-21 15:56:43 +03:00
|
|
|
flags |= (REDIRECTION_VERSION6 << 2);
|
2023-02-20 15:26:44 +03:00
|
|
|
else
|
2023-02-21 15:56:43 +03:00
|
|
|
flags |= (REDIRECTION_VERSION5 << 2);
|
2023-02-20 15:26:44 +03:00
|
|
|
}
|
|
|
|
|
2023-01-23 14:03:18 +03:00
|
|
|
WLog_VRB(TAG, "write ClusterInfoFlags=%s, RedirectedSessionId=0x%08" PRIx32,
|
2023-01-21 11:45:11 +03:00
|
|
|
rdp_cluster_info_flags_to_string(flags, buffer, sizeof(buffer)),
|
|
|
|
settings->RedirectedSessionId);
|
2019-11-06 17:24:51 +03:00
|
|
|
Stream_Write_UINT32(s, flags); /* flags */
|
2013-05-09 00:09:16 +04:00
|
|
|
Stream_Write_UINT32(s, settings->RedirectedSessionId); /* redirectedSessionID */
|
2020-11-18 09:51:45 +03:00
|
|
|
return TRUE;
|
2011-07-05 06:02:00 +04:00
|
|
|
}
|
|
|
|
|
2011-08-19 13:39:37 +04:00
|
|
|
/**
|
2022-12-09 16:35:03 +03:00
|
|
|
* Read a client monitor data block (TS_UD_CS_MONITOR).
|
|
|
|
* msdn{dd305336}
|
2011-08-19 13:39:37 +04:00
|
|
|
* @param s stream
|
2022-12-09 16:35:03 +03:00
|
|
|
* @param mcs The MCS instance
|
|
|
|
*
|
|
|
|
* @return \b TRUE for success, \b FALSE otherwise
|
2011-08-19 13:39:37 +04:00
|
|
|
*/
|
|
|
|
|
2023-06-26 12:38:11 +03:00
|
|
|
BOOL gcc_read_client_monitor_data(wStream* s, rdpMcs* mcs)
|
2011-08-19 13:39:37 +04:00
|
|
|
{
|
2014-01-24 01:00:02 +04:00
|
|
|
UINT32 index;
|
|
|
|
UINT32 monitorCount;
|
2022-12-12 14:17:18 +03:00
|
|
|
rdpSettings* settings = mcs_get_settings(mcs);
|
2021-09-03 12:31:21 +03:00
|
|
|
|
|
|
|
WINPR_ASSERT(s);
|
|
|
|
WINPR_ASSERT(settings);
|
2014-01-24 01:00:02 +04:00
|
|
|
|
2023-06-26 12:38:11 +03:00
|
|
|
const size_t blockLength = Stream_GetRemainingLength(s);
|
2014-01-24 01:00:02 +04:00
|
|
|
if (blockLength < 8)
|
|
|
|
return FALSE;
|
|
|
|
|
2022-10-10 12:41:34 +03:00
|
|
|
Stream_Read_UINT32(s, settings->MonitorFlags); /* flags */
|
|
|
|
Stream_Read_UINT32(s, monitorCount); /* monitorCount */
|
2014-01-24 01:00:02 +04:00
|
|
|
|
2017-02-21 17:03:00 +03:00
|
|
|
/* 2.2.1.3.6 Client Monitor Data -
|
|
|
|
* monitorCount (4 bytes): A 32-bit, unsigned integer. The number of display
|
|
|
|
* monitor definitions in the monitorDefArray field (the maximum allowed is 16).
|
|
|
|
*/
|
2017-02-21 13:02:12 +03:00
|
|
|
if (monitorCount > 16)
|
|
|
|
{
|
2019-11-06 17:24:51 +03:00
|
|
|
WLog_ERR(TAG, "announced monitors(%" PRIu32 ") exceed the 16 limit", monitorCount);
|
2017-02-21 13:02:12 +03:00
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
2016-01-14 23:00:41 +03:00
|
|
|
if (monitorCount > settings->MonitorDefArraySize)
|
|
|
|
{
|
2019-11-06 17:24:51 +03:00
|
|
|
WLog_ERR(TAG, "too many announced monitors(%" PRIu32 "), clamping to %" PRIu32 "",
|
|
|
|
monitorCount, settings->MonitorDefArraySize);
|
2016-01-14 23:00:41 +03:00
|
|
|
monitorCount = settings->MonitorDefArraySize;
|
|
|
|
}
|
|
|
|
|
2019-11-06 17:24:51 +03:00
|
|
|
if ((UINT32)((blockLength - 8) / 20) < monitorCount)
|
2014-01-24 01:00:02 +04:00
|
|
|
return FALSE;
|
|
|
|
|
2015-08-27 09:10:42 +03:00
|
|
|
settings->MonitorCount = monitorCount;
|
2014-01-24 01:00:02 +04:00
|
|
|
|
|
|
|
for (index = 0; index < monitorCount; index++)
|
|
|
|
{
|
2022-10-10 12:41:34 +03:00
|
|
|
UINT32 left, top, right, bottom, flags;
|
2021-12-16 14:42:36 +03:00
|
|
|
rdpMonitor* current = &settings->MonitorDefArray[index];
|
|
|
|
|
2019-11-06 17:24:51 +03:00
|
|
|
Stream_Read_UINT32(s, left); /* left */
|
|
|
|
Stream_Read_UINT32(s, top); /* top */
|
|
|
|
Stream_Read_UINT32(s, right); /* right */
|
2015-08-27 09:10:42 +03:00
|
|
|
Stream_Read_UINT32(s, bottom); /* bottom */
|
2019-11-06 17:24:51 +03:00
|
|
|
Stream_Read_UINT32(s, flags); /* flags */
|
2021-12-16 14:42:36 +03:00
|
|
|
current->x = left;
|
|
|
|
current->y = top;
|
|
|
|
current->width = right - left + 1;
|
|
|
|
current->height = bottom - top + 1;
|
2023-07-04 10:26:52 +03:00
|
|
|
current->is_primary = (flags & MONITOR_PRIMARY) ? TRUE : FALSE;
|
2014-01-24 01:00:02 +04:00
|
|
|
}
|
|
|
|
|
2012-10-09 10:31:28 +04:00
|
|
|
return TRUE;
|
2011-08-19 13:39:37 +04:00
|
|
|
}
|
|
|
|
|
2011-07-05 06:02:00 +04:00
|
|
|
/**
|
2022-12-09 16:35:03 +03:00
|
|
|
* Write a client monitor data block (TS_UD_CS_MONITOR).
|
|
|
|
* msdn{dd305336}
|
2011-07-05 06:02:00 +04:00
|
|
|
* @param s stream
|
2022-12-09 16:35:03 +03:00
|
|
|
* @param mcs The MCS to use
|
|
|
|
*
|
|
|
|
* @return \b TRUE for success, \b FALSE otherwise
|
2011-07-05 06:02:00 +04:00
|
|
|
*/
|
|
|
|
|
2020-11-18 09:51:45 +03:00
|
|
|
BOOL gcc_write_client_monitor_data(wStream* s, const rdpMcs* mcs)
|
2011-07-05 06:02:00 +04:00
|
|
|
{
|
2019-01-30 11:51:39 +03:00
|
|
|
UINT32 i;
|
2012-10-09 11:01:37 +04:00
|
|
|
UINT16 length;
|
2017-11-14 15:58:31 +03:00
|
|
|
INT32 baseX = 0, baseY = 0;
|
2022-12-12 14:17:18 +03:00
|
|
|
const rdpSettings* settings = mcs_get_const_settings(mcs);
|
2021-09-03 12:31:21 +03:00
|
|
|
|
|
|
|
WINPR_ASSERT(s);
|
|
|
|
WINPR_ASSERT(settings);
|
2011-07-06 02:26:12 +04:00
|
|
|
|
2023-01-23 14:03:18 +03:00
|
|
|
WLog_DBG(TAG, "MonitorCount=%" PRIu32, settings->MonitorCount);
|
2012-11-08 08:29:24 +04:00
|
|
|
if (settings->MonitorCount > 1)
|
2011-07-06 02:26:12 +04:00
|
|
|
{
|
2012-11-08 08:29:24 +04:00
|
|
|
length = (20 * settings->MonitorCount) + 12;
|
2020-11-18 09:51:45 +03:00
|
|
|
if (!gcc_write_user_data_header(s, CS_MONITOR, length))
|
2021-01-21 16:24:38 +03:00
|
|
|
return FALSE;
|
2022-10-10 12:41:34 +03:00
|
|
|
Stream_Write_UINT32(s, settings->MonitorFlags); /* flags */
|
2013-05-09 00:09:16 +04:00
|
|
|
Stream_Write_UINT32(s, settings->MonitorCount); /* monitorCount */
|
2011-07-06 02:26:12 +04:00
|
|
|
|
2017-10-17 15:07:23 +03:00
|
|
|
/* first pass to get the primary monitor coordinates (it is supposed to be
|
|
|
|
* in (0,0) */
|
2012-11-08 08:29:24 +04:00
|
|
|
for (i = 0; i < settings->MonitorCount; i++)
|
2011-07-06 02:26:12 +04:00
|
|
|
{
|
2021-12-16 14:42:36 +03:00
|
|
|
const rdpMonitor* current = &settings->MonitorDefArray[i];
|
|
|
|
if (current->is_primary)
|
2017-10-17 15:07:23 +03:00
|
|
|
{
|
2021-12-16 14:42:36 +03:00
|
|
|
baseX = current->x;
|
|
|
|
baseY = current->y;
|
2018-12-13 16:16:50 +03:00
|
|
|
break;
|
2017-10-17 15:07:23 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < settings->MonitorCount; i++)
|
|
|
|
{
|
2021-12-16 14:42:36 +03:00
|
|
|
const rdpMonitor* current = &settings->MonitorDefArray[i];
|
|
|
|
const UINT32 left = current->x - baseX;
|
|
|
|
const UINT32 top = current->y - baseY;
|
|
|
|
const UINT32 right = left + current->width - 1;
|
|
|
|
const UINT32 bottom = top + current->height - 1;
|
|
|
|
const UINT32 flags = current->is_primary ? MONITOR_PRIMARY : 0;
|
2021-12-17 11:41:50 +03:00
|
|
|
WLog_DBG(TAG,
|
2023-01-23 14:03:18 +03:00
|
|
|
"Monitor[%" PRIu32 "]: top=%" PRIu32 ", left=%" PRIu32 ", bottom=%" PRIu32
|
2023-07-28 12:45:58 +03:00
|
|
|
", right=%" PRIu32 ", flags=%" PRIu32,
|
2023-01-23 14:03:18 +03:00
|
|
|
i, top, left, bottom, right, flags);
|
2019-11-06 17:24:51 +03:00
|
|
|
Stream_Write_UINT32(s, left); /* left */
|
|
|
|
Stream_Write_UINT32(s, top); /* top */
|
|
|
|
Stream_Write_UINT32(s, right); /* right */
|
2013-05-09 00:09:16 +04:00
|
|
|
Stream_Write_UINT32(s, bottom); /* bottom */
|
2019-11-06 17:24:51 +03:00
|
|
|
Stream_Write_UINT32(s, flags); /* flags */
|
2011-07-06 02:26:12 +04:00
|
|
|
}
|
|
|
|
}
|
2023-01-23 14:03:18 +03:00
|
|
|
WLog_DBG(TAG, "FINISHED");
|
2021-01-21 16:24:38 +03:00
|
|
|
return TRUE;
|
2011-07-05 06:02:00 +04:00
|
|
|
}
|
2014-01-24 01:00:02 +04:00
|
|
|
|
2023-06-26 12:38:11 +03:00
|
|
|
BOOL gcc_read_client_monitor_extended_data(wStream* s, rdpMcs* mcs)
|
2014-01-24 01:00:02 +04:00
|
|
|
{
|
|
|
|
UINT32 index;
|
|
|
|
UINT32 monitorCount;
|
|
|
|
UINT32 monitorAttributeSize;
|
2022-12-12 14:17:18 +03:00
|
|
|
rdpSettings* settings = mcs_get_settings(mcs);
|
2021-09-03 12:31:21 +03:00
|
|
|
|
|
|
|
WINPR_ASSERT(s);
|
|
|
|
WINPR_ASSERT(settings);
|
2014-01-24 01:00:02 +04:00
|
|
|
|
2023-06-26 12:38:11 +03:00
|
|
|
const size_t blockLength = Stream_GetRemainingLength(s);
|
2015-06-16 16:42:07 +03:00
|
|
|
if (blockLength < 12)
|
2014-01-24 01:00:02 +04:00
|
|
|
return FALSE;
|
|
|
|
|
2022-10-10 12:41:34 +03:00
|
|
|
Stream_Read_UINT32(s, settings->MonitorAttributeFlags); /* flags */
|
|
|
|
Stream_Read_UINT32(s, monitorAttributeSize); /* monitorAttributeSize */
|
|
|
|
Stream_Read_UINT32(s, monitorCount); /* monitorCount */
|
2014-01-24 01:00:02 +04:00
|
|
|
|
|
|
|
if (monitorAttributeSize != 20)
|
|
|
|
return FALSE;
|
|
|
|
|
2015-06-16 16:42:07 +03:00
|
|
|
if ((blockLength - 12) / monitorAttributeSize < monitorCount)
|
2014-01-24 01:00:02 +04:00
|
|
|
return FALSE;
|
|
|
|
|
2015-08-27 09:10:42 +03:00
|
|
|
if (settings->MonitorCount != monitorCount)
|
2015-06-16 16:42:07 +03:00
|
|
|
return FALSE;
|
2014-01-24 01:00:02 +04:00
|
|
|
|
2015-08-27 09:10:42 +03:00
|
|
|
settings->HasMonitorAttributes = TRUE;
|
|
|
|
|
2014-01-24 01:00:02 +04:00
|
|
|
for (index = 0; index < monitorCount; index++)
|
|
|
|
{
|
2021-12-16 14:42:36 +03:00
|
|
|
rdpMonitor* current = &settings->MonitorDefArray[index];
|
|
|
|
Stream_Read_UINT32(s, current->attributes.physicalWidth); /* physicalWidth */
|
|
|
|
Stream_Read_UINT32(s, current->attributes.physicalHeight); /* physicalHeight */
|
|
|
|
Stream_Read_UINT32(s, current->attributes.orientation); /* orientation */
|
|
|
|
Stream_Read_UINT32(s, current->attributes.desktopScaleFactor); /* desktopScaleFactor */
|
|
|
|
Stream_Read_UINT32(s, current->attributes.deviceScaleFactor); /* deviceScaleFactor */
|
2014-01-24 01:00:02 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
2020-11-18 09:51:45 +03:00
|
|
|
BOOL gcc_write_client_monitor_extended_data(wStream* s, const rdpMcs* mcs)
|
2014-01-24 01:00:02 +04:00
|
|
|
{
|
2018-11-15 19:53:28 +03:00
|
|
|
UINT32 i;
|
2015-08-27 09:10:42 +03:00
|
|
|
UINT16 length;
|
2022-12-12 14:17:18 +03:00
|
|
|
const rdpSettings* settings = mcs_get_const_settings(mcs);
|
2021-09-03 12:31:21 +03:00
|
|
|
|
|
|
|
WINPR_ASSERT(s);
|
|
|
|
WINPR_ASSERT(settings);
|
2014-01-24 01:00:02 +04:00
|
|
|
|
2015-08-27 09:10:42 +03:00
|
|
|
if (settings->HasMonitorAttributes)
|
|
|
|
{
|
|
|
|
length = (20 * settings->MonitorCount) + 16;
|
2020-11-18 09:51:45 +03:00
|
|
|
if (!gcc_write_user_data_header(s, CS_MONITOR_EX, length))
|
2021-01-21 16:24:38 +03:00
|
|
|
return FALSE;
|
2022-10-10 12:41:34 +03:00
|
|
|
Stream_Write_UINT32(s, settings->MonitorAttributeFlags); /* flags */
|
|
|
|
Stream_Write_UINT32(s, 20); /* monitorAttributeSize */
|
|
|
|
Stream_Write_UINT32(s, settings->MonitorCount); /* monitorCount */
|
2015-08-27 09:10:42 +03:00
|
|
|
|
|
|
|
for (i = 0; i < settings->MonitorCount; i++)
|
|
|
|
{
|
2021-12-16 14:42:36 +03:00
|
|
|
const rdpMonitor* current = &settings->MonitorDefArray[i];
|
|
|
|
Stream_Write_UINT32(s, current->attributes.physicalWidth); /* physicalWidth */
|
|
|
|
Stream_Write_UINT32(s, current->attributes.physicalHeight); /* physicalHeight */
|
|
|
|
Stream_Write_UINT32(s, current->attributes.orientation); /* orientation */
|
|
|
|
Stream_Write_UINT32(s, current->attributes.desktopScaleFactor); /* desktopScaleFactor */
|
|
|
|
Stream_Write_UINT32(s, current->attributes.deviceScaleFactor); /* deviceScaleFactor */
|
2015-08-27 09:10:42 +03:00
|
|
|
}
|
|
|
|
}
|
2021-01-21 16:24:38 +03:00
|
|
|
return TRUE;
|
2014-01-24 01:00:02 +04:00
|
|
|
}
|
|
|
|
|
2014-01-24 03:01:31 +04:00
|
|
|
/**
|
2022-12-09 16:35:03 +03:00
|
|
|
* Read a client message channel data block (TS_UD_CS_MCS_MSGCHANNEL).
|
|
|
|
* msdn{jj217627}
|
2014-01-24 03:01:31 +04:00
|
|
|
* @param s stream
|
2022-12-09 16:35:03 +03:00
|
|
|
* @param mcs The MCS instance
|
|
|
|
*
|
|
|
|
* @return \b TRUE for success, \b FALSE otherwise
|
2014-01-24 03:01:31 +04:00
|
|
|
*/
|
|
|
|
|
2023-06-26 12:38:11 +03:00
|
|
|
BOOL gcc_read_client_message_channel_data(wStream* s, rdpMcs* mcs)
|
2014-01-24 01:00:02 +04:00
|
|
|
{
|
2022-12-12 14:17:18 +03:00
|
|
|
WINPR_ASSERT(s);
|
|
|
|
WINPR_ASSERT(mcs);
|
2023-06-26 12:38:11 +03:00
|
|
|
|
|
|
|
const size_t blockLength = Stream_GetRemainingLength(s);
|
2014-01-24 01:00:02 +04:00
|
|
|
if (blockLength < 4)
|
|
|
|
return FALSE;
|
|
|
|
|
2022-10-10 12:41:34 +03:00
|
|
|
Stream_Read_UINT32(s, mcs->flags);
|
2014-10-28 11:06:04 +03:00
|
|
|
mcs->messageChannelId = mcs->baseChannelId++;
|
2014-01-24 01:00:02 +04:00
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
2014-01-24 03:01:31 +04:00
|
|
|
/**
|
2022-12-09 16:35:03 +03:00
|
|
|
* Write a client message channel data block (TS_UD_CS_MCS_MSGCHANNEL).
|
|
|
|
* msdn{jj217627}
|
2014-01-24 03:01:31 +04:00
|
|
|
* @param s stream
|
2022-12-09 16:35:03 +03:00
|
|
|
* @param mcs The MCS instance
|
|
|
|
*
|
|
|
|
* @return \b TRUE for success, \b FALSE otherwise
|
2014-01-24 03:01:31 +04:00
|
|
|
*/
|
|
|
|
|
2020-11-18 09:51:45 +03:00
|
|
|
BOOL gcc_write_client_message_channel_data(wStream* s, const rdpMcs* mcs)
|
2014-01-24 01:00:02 +04:00
|
|
|
{
|
2022-12-12 14:17:18 +03:00
|
|
|
const rdpSettings* settings = mcs_get_const_settings(mcs);
|
2021-09-03 12:31:21 +03:00
|
|
|
|
|
|
|
WINPR_ASSERT(s);
|
|
|
|
WINPR_ASSERT(mcs);
|
|
|
|
WINPR_ASSERT(settings);
|
2022-10-10 12:41:34 +03:00
|
|
|
if (freerdp_settings_get_bool(settings, FreeRDP_NetworkAutoDetect) ||
|
|
|
|
settings->SupportHeartbeatPdu || settings->SupportMultitransport)
|
2014-01-24 03:01:31 +04:00
|
|
|
{
|
2020-11-18 09:51:45 +03:00
|
|
|
if (!gcc_write_user_data_header(s, CS_MCS_MSGCHANNEL, 8))
|
|
|
|
return FALSE;
|
2022-10-10 12:41:34 +03:00
|
|
|
Stream_Write_UINT32(s, mcs->flags); /* flags */
|
2014-01-24 03:01:31 +04:00
|
|
|
}
|
2020-11-18 09:51:45 +03:00
|
|
|
return TRUE;
|
2014-01-24 03:01:31 +04:00
|
|
|
}
|
|
|
|
|
2014-02-14 02:50:38 +04:00
|
|
|
BOOL gcc_read_server_message_channel_data(wStream* s, rdpMcs* mcs)
|
2014-01-24 03:01:31 +04:00
|
|
|
{
|
|
|
|
UINT16 MCSChannelId;
|
2022-12-12 14:17:18 +03:00
|
|
|
WINPR_ASSERT(s);
|
|
|
|
WINPR_ASSERT(mcs);
|
2022-04-19 15:29:17 +03:00
|
|
|
if (!Stream_CheckAndLogRequiredLength(TAG, s, 2))
|
2014-01-24 03:01:31 +04:00
|
|
|
return FALSE;
|
2014-01-26 02:08:43 +04:00
|
|
|
|
2014-01-24 03:01:31 +04:00
|
|
|
Stream_Read_UINT16(s, MCSChannelId); /* MCSChannelId */
|
|
|
|
/* Save the MCS message channel id */
|
2014-02-14 02:50:38 +04:00
|
|
|
mcs->messageChannelId = MCSChannelId;
|
2014-01-24 03:01:31 +04:00
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
2020-11-18 09:51:45 +03:00
|
|
|
BOOL gcc_write_server_message_channel_data(wStream* s, const rdpMcs* mcs)
|
2014-01-24 03:01:31 +04:00
|
|
|
{
|
2022-12-12 14:17:18 +03:00
|
|
|
WINPR_ASSERT(s);
|
|
|
|
WINPR_ASSERT(mcs);
|
2014-10-28 11:06:04 +03:00
|
|
|
if (mcs->messageChannelId == 0)
|
2015-04-01 16:11:57 +03:00
|
|
|
return TRUE;
|
|
|
|
|
2020-11-18 09:51:45 +03:00
|
|
|
if (!gcc_write_user_data_header(s, SC_MCS_MSGCHANNEL, 6))
|
2015-04-01 16:11:57 +03:00
|
|
|
return FALSE;
|
2014-01-24 01:00:02 +04:00
|
|
|
|
2014-10-28 11:06:04 +03:00
|
|
|
Stream_Write_UINT16(s, mcs->messageChannelId); /* mcsChannelId (2 bytes) */
|
2015-04-01 16:11:57 +03:00
|
|
|
return TRUE;
|
2014-01-24 01:00:02 +04:00
|
|
|
}
|
|
|
|
|
2014-01-24 03:01:31 +04:00
|
|
|
/**
|
2022-12-09 16:35:03 +03:00
|
|
|
* Read a client multitransport channel data block (TS_UD_CS_MULTITRANSPORT).
|
|
|
|
* msdn{jj217498}
|
2014-01-24 03:01:31 +04:00
|
|
|
* @param s stream
|
2022-12-09 16:35:03 +03:00
|
|
|
* @param mcs The MCS instance
|
|
|
|
*
|
|
|
|
* @return \b TRUE for success, \b FALSE otherwise
|
2014-01-24 03:01:31 +04:00
|
|
|
*/
|
|
|
|
|
2023-06-26 12:38:11 +03:00
|
|
|
BOOL gcc_read_client_multitransport_channel_data(wStream* s, rdpMcs* mcs)
|
2014-01-24 01:00:02 +04:00
|
|
|
{
|
2022-12-12 14:17:18 +03:00
|
|
|
rdpSettings* settings = mcs_get_settings(mcs);
|
2022-10-10 12:41:34 +03:00
|
|
|
|
|
|
|
WINPR_ASSERT(s);
|
|
|
|
WINPR_ASSERT(settings);
|
2023-06-26 12:38:11 +03:00
|
|
|
|
|
|
|
const size_t blockLength = Stream_GetRemainingLength(s);
|
2014-01-24 01:00:02 +04:00
|
|
|
if (blockLength < 4)
|
|
|
|
return FALSE;
|
|
|
|
|
2022-11-24 12:54:23 +03:00
|
|
|
UINT32 remoteFlags;
|
|
|
|
Stream_Read_UINT32(s, remoteFlags);
|
|
|
|
settings->MultitransportFlags &= remoteFlags; /* merge local and remote flags */
|
2014-01-24 01:00:02 +04:00
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
2014-01-24 03:01:31 +04:00
|
|
|
/**
|
2022-12-09 16:35:03 +03:00
|
|
|
* Write a client multitransport channel data block (TS_UD_CS_MULTITRANSPORT).
|
|
|
|
* msdn{jj217498}
|
|
|
|
*
|
2014-01-24 03:01:31 +04:00
|
|
|
* @param s stream
|
2022-12-09 16:35:03 +03:00
|
|
|
* @param mcs The MCS instance
|
|
|
|
*
|
|
|
|
* @return \b TRUE for success, \b FALSE otherwise
|
2014-01-24 03:01:31 +04:00
|
|
|
*/
|
|
|
|
|
2020-11-18 09:51:45 +03:00
|
|
|
BOOL gcc_write_client_multitransport_channel_data(wStream* s, const rdpMcs* mcs)
|
2014-01-24 01:00:02 +04:00
|
|
|
{
|
2022-12-12 14:17:18 +03:00
|
|
|
const rdpSettings* settings = mcs_get_const_settings(mcs);
|
2021-09-03 12:31:21 +03:00
|
|
|
|
|
|
|
WINPR_ASSERT(s);
|
|
|
|
WINPR_ASSERT(settings);
|
2020-11-18 09:51:45 +03:00
|
|
|
if (!gcc_write_user_data_header(s, CS_MULTITRANSPORT, 8))
|
|
|
|
return FALSE;
|
2020-01-23 17:16:14 +03:00
|
|
|
Stream_Write_UINT32(s, settings->MultitransportFlags); /* flags */
|
2020-11-18 09:51:45 +03:00
|
|
|
return TRUE;
|
2014-01-24 03:01:31 +04:00
|
|
|
}
|
|
|
|
|
2014-02-14 02:50:38 +04:00
|
|
|
BOOL gcc_read_server_multitransport_channel_data(wStream* s, rdpMcs* mcs)
|
2014-01-24 03:01:31 +04:00
|
|
|
{
|
2022-12-12 14:17:18 +03:00
|
|
|
rdpSettings* settings = mcs_get_settings(mcs);
|
2022-11-24 12:54:23 +03:00
|
|
|
UINT32 remoteFlags;
|
|
|
|
|
2022-10-10 12:41:34 +03:00
|
|
|
WINPR_ASSERT(s);
|
|
|
|
WINPR_ASSERT(settings);
|
2022-04-19 15:29:17 +03:00
|
|
|
if (!Stream_CheckAndLogRequiredLength(TAG, s, 4))
|
2014-01-24 03:01:31 +04:00
|
|
|
return FALSE;
|
2014-01-24 01:00:02 +04:00
|
|
|
|
2022-11-24 12:54:23 +03:00
|
|
|
Stream_Read_UINT32(s, remoteFlags);
|
|
|
|
settings->MultitransportFlags &= remoteFlags; /* merge with client setting */
|
2014-01-24 03:01:31 +04:00
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
2020-11-18 09:51:45 +03:00
|
|
|
BOOL gcc_write_server_multitransport_channel_data(wStream* s, const rdpMcs* mcs)
|
2014-01-24 03:01:31 +04:00
|
|
|
{
|
2022-12-12 14:17:18 +03:00
|
|
|
const rdpSettings* settings = mcs_get_const_settings(mcs);
|
|
|
|
|
|
|
|
WINPR_ASSERT(s);
|
|
|
|
WINPR_ASSERT(settings);
|
2022-11-24 12:54:23 +03:00
|
|
|
|
2020-11-18 09:51:45 +03:00
|
|
|
if (!gcc_write_user_data_header(s, SC_MULTITRANSPORT, 8))
|
|
|
|
return FALSE;
|
2022-11-24 12:54:23 +03:00
|
|
|
|
|
|
|
Stream_Write_UINT32(s, settings->MultitransportFlags); /* flags (4 bytes) */
|
2020-11-18 09:51:45 +03:00
|
|
|
return TRUE;
|
2014-01-24 01:00:02 +04:00
|
|
|
}
|