FreeRDP/server/Sample/sfreerdp.c

940 lines
24 KiB
C
Raw Normal View History

2011-08-18 12:06:32 +04:00
/**
2012-10-09 07:02:04 +04:00
* FreeRDP: A Remote Desktop Protocol Implementation
2011-08-18 12:06:32 +04:00
* FreeRDP Test Server
*
* Copyright 2011 Marc-Andre Moreau <marcandre.moreau@gmail.com>
* Copyright 2011 Vic Lee
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>
2011-08-18 12:06:32 +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.
*/
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
2011-08-18 12:06:32 +04:00
#include <errno.h>
2011-08-25 09:18:01 +04:00
#include <signal.h>
#include <winpr/crt.h>
#include <winpr/synch.h>
#include <winpr/string.h>
#include <winpr/path.h>
2014-11-12 22:06:34 +03:00
#include <winpr/winsock.h>
2014-03-03 21:10:06 +04:00
#include <freerdp/channels/wtsvc.h>
#include <freerdp/channels/channels.h>
2014-09-12 19:38:12 +04:00
#include <freerdp/constants.h>
#include <freerdp/server/rdpsnd.h>
#include "sf_audin.h"
#include "sf_rdpsnd.h"
#include "sf_encomsp.h"
#include "sfreerdp.h"
2011-08-18 12:06:32 +04:00
2014-09-12 19:38:12 +04:00
#include <freerdp/log.h>
#define TAG SERVER_TAG("sample")
2013-06-24 20:02:21 +04:00
#define SAMPLE_SERVER_USE_CLIENT_RESOLUTION 1
#define SAMPLE_SERVER_DEFAULT_WIDTH 1024
#define SAMPLE_SERVER_DEFAULT_HEIGHT 768
static char* test_pcap_file = NULL;
static BOOL test_dump_rfx_realtime = TRUE;
BOOL test_peer_context_new(freerdp_peer* client, testPeerContext* context)
{
if (!(context->rfx_context = rfx_context_new(TRUE)))
goto fail_rfx_context;
context->rfx_context->mode = RLGR3;
context->rfx_context->width = SAMPLE_SERVER_DEFAULT_WIDTH;
context->rfx_context->height = SAMPLE_SERVER_DEFAULT_HEIGHT;
2012-03-13 15:02:19 +04:00
rfx_context_set_pixel_format(context->rfx_context, RDP_PIXEL_FORMAT_R8G8B8);
2011-08-24 19:10:23 +04:00
if (!(context->nsc_context = nsc_context_new()))
goto fail_nsc_context;
2012-03-18 12:36:38 +04:00
nsc_context_set_pixel_format(context->nsc_context, RDP_PIXEL_FORMAT_R8G8B8);
if (!(context->s = Stream_New(NULL, 65536)))
goto fail_stream_new;
context->icon_x = -1;
context->icon_y = -1;
2011-12-12 12:42:42 +04:00
context->vcm = WTSOpenServerA((LPSTR) client->context);
if (!context->vcm || context->vcm == INVALID_HANDLE_VALUE)
goto fail_open_server;
return TRUE;
fail_open_server:
context->vcm = NULL;
Stream_Free(context->s, TRUE);
context->s = NULL;
fail_stream_new:
nsc_context_free(context->nsc_context);
context->nsc_context = NULL;
fail_nsc_context:
rfx_context_free(context->rfx_context);
context->rfx_context = NULL;
fail_rfx_context:
return FALSE;
}
void test_peer_context_free(freerdp_peer* client, testPeerContext* context)
{
if (context)
{
if (context->debug_channel_thread)
{
SetEvent(context->stopEvent);
WaitForSingleObject(context->debug_channel_thread, INFINITE);
CloseHandle(context->debug_channel_thread);
}
2013-05-09 01:48:30 +04:00
Stream_Free(context->s, TRUE);
free(context->icon_data);
free(context->bg_data);
rfx_context_free(context->rfx_context);
2012-03-18 12:36:38 +04:00
nsc_context_free(context->nsc_context);
2011-12-12 12:42:42 +04:00
if (context->debug_channel)
WTSVirtualChannelClose(context->debug_channel);
if (context->audin)
audin_server_context_free(context->audin);
if (context->rdpsnd)
rdpsnd_server_context_free(context->rdpsnd);
if (context->encomsp)
encomsp_server_context_free(context->encomsp);
WTSCloseServer((HANDLE) context->vcm);
}
}
static BOOL test_peer_init(freerdp_peer* client)
{
2013-06-14 05:34:46 +04:00
client->ContextSize = sizeof(testPeerContext);
client->ContextNew = (psPeerContextNew) test_peer_context_new;
client->ContextFree = (psPeerContextFree) test_peer_context_free;
return freerdp_peer_context_new(client);
}
static wStream* test_peer_stream_init(testPeerContext* context)
{
2013-05-02 02:15:55 +04:00
Stream_Clear(context->s);
Stream_SetPosition(context->s, 0);
return context->s;
}
2011-08-24 12:25:18 +04:00
static void test_peer_begin_frame(freerdp_peer* client)
{
rdpUpdate* update = client->update;
SURFACE_FRAME_MARKER* fm = &update->surface_frame_marker;
testPeerContext* context = (testPeerContext*) client->context;
fm->frameAction = SURFACECMD_FRAMEACTION_BEGIN;
fm->frameId = context->frame_id;
update->SurfaceFrameMarker(update->context, fm);
}
static void test_peer_end_frame(freerdp_peer* client)
{
rdpUpdate* update = client->update;
SURFACE_FRAME_MARKER* fm = &update->surface_frame_marker;
testPeerContext* context = (testPeerContext*) client->context;
fm->frameAction = SURFACECMD_FRAMEACTION_END;
fm->frameId = context->frame_id;
update->SurfaceFrameMarker(update->context, fm);
context->frame_id++;
}
static BOOL test_peer_draw_background(freerdp_peer* client)
{
int size;
wStream* s;
RFX_RECT rect;
BYTE* rgb_data;
rdpUpdate* update = client->update;
SURFACE_BITS_COMMAND* cmd = &update->surface_bits_command;
testPeerContext* context = (testPeerContext*) client->context;
BOOL ret= FALSE;
2011-08-24 12:25:18 +04:00
if (!client->settings->RemoteFxCodec && !client->settings->NSCodec)
return FALSE;
s = test_peer_stream_init(context);
rect.x = 0;
rect.y = 0;
2012-11-26 21:38:28 +04:00
rect.width = client->settings->DesktopWidth;
rect.height = client->settings->DesktopHeight;
size = rect.width * rect.height * 3;
codec/rfx: error checking and various fixes - removed some unneeded null checks for free() - fixed a memory leak in shadow_client - removed rfx_compose_message_header from API Changed the following functions to BOOL, check the result where they are called and handle failures: - rfx_compose_message - rfx_compose_message_header - rfx_write_tile - rfx_write_message_tileset - rfx_write_message_frame_begin - rfx_write_message_region - rfx_write_message_frame_end - rfx_write_message rfx_process_message: - check memory allocation failures - verify protocol-conform order of data messages to prevents memory leaks caused by repeated allocations - verify that header messages were parsed/received before the data messages - treat unknown rlgr mode as error - fixed/added error handling - fixed all callers to check/handle result rfx_encode_message: - fixed incorrect usage of realloc - missing malloc check - missing check of CreateThreadpoolWork - correct cleanup on failure (threadpool, memory) - check rfx_encode_message result rfx_encode_messages: - check rfx_split_message result - correct cleanup on failure - prevent memory leak on failure rfx_write_message_context: - fixed invalid channelId value (must be 0xFF for WBT_CONTEXT) rfx_process_message_codec_versions: - fixed invalid read size of codec_version (it is 16bit) rfx_process_message_channels: - verify protocol conform channelId value rfx_process_message_region: - replaced invalid reallocs with malloc - read and verify regionType and numTileSets from stream rfx_process_message_tileset: - check allocation results - fixed incorrect usages of realloc setupWorkers: - fixed incorrect usages of realloc rfx_split_message: - removed dead code - missing malloc check rfx_compose_message: - fixed a memory leak - check/handle rfx_encode_message result
2015-04-23 16:42:21 +03:00
if (!(rgb_data = malloc(size)))
{
WLog_ERR(TAG, "Problem allocating memory");
return FALSE;
}
codec/rfx: error checking and various fixes - removed some unneeded null checks for free() - fixed a memory leak in shadow_client - removed rfx_compose_message_header from API Changed the following functions to BOOL, check the result where they are called and handle failures: - rfx_compose_message - rfx_compose_message_header - rfx_write_tile - rfx_write_message_tileset - rfx_write_message_frame_begin - rfx_write_message_region - rfx_write_message_frame_end - rfx_write_message rfx_process_message: - check memory allocation failures - verify protocol-conform order of data messages to prevents memory leaks caused by repeated allocations - verify that header messages were parsed/received before the data messages - treat unknown rlgr mode as error - fixed/added error handling - fixed all callers to check/handle result rfx_encode_message: - fixed incorrect usage of realloc - missing malloc check - missing check of CreateThreadpoolWork - correct cleanup on failure (threadpool, memory) - check rfx_encode_message result rfx_encode_messages: - check rfx_split_message result - correct cleanup on failure - prevent memory leak on failure rfx_write_message_context: - fixed invalid channelId value (must be 0xFF for WBT_CONTEXT) rfx_process_message_codec_versions: - fixed invalid read size of codec_version (it is 16bit) rfx_process_message_channels: - verify protocol conform channelId value rfx_process_message_region: - replaced invalid reallocs with malloc - read and verify regionType and numTileSets from stream rfx_process_message_tileset: - check allocation results - fixed incorrect usages of realloc setupWorkers: - fixed incorrect usages of realloc rfx_split_message: - removed dead code - missing malloc check rfx_compose_message: - fixed a memory leak - check/handle rfx_encode_message result
2015-04-23 16:42:21 +03:00
memset(rgb_data, 0xA0, size);
if (client->settings->RemoteFxCodec)
2012-03-18 12:36:38 +04:00
{
codec/rfx: error checking and various fixes - removed some unneeded null checks for free() - fixed a memory leak in shadow_client - removed rfx_compose_message_header from API Changed the following functions to BOOL, check the result where they are called and handle failures: - rfx_compose_message - rfx_compose_message_header - rfx_write_tile - rfx_write_message_tileset - rfx_write_message_frame_begin - rfx_write_message_region - rfx_write_message_frame_end - rfx_write_message rfx_process_message: - check memory allocation failures - verify protocol-conform order of data messages to prevents memory leaks caused by repeated allocations - verify that header messages were parsed/received before the data messages - treat unknown rlgr mode as error - fixed/added error handling - fixed all callers to check/handle result rfx_encode_message: - fixed incorrect usage of realloc - missing malloc check - missing check of CreateThreadpoolWork - correct cleanup on failure (threadpool, memory) - check rfx_encode_message result rfx_encode_messages: - check rfx_split_message result - correct cleanup on failure - prevent memory leak on failure rfx_write_message_context: - fixed invalid channelId value (must be 0xFF for WBT_CONTEXT) rfx_process_message_codec_versions: - fixed invalid read size of codec_version (it is 16bit) rfx_process_message_channels: - verify protocol conform channelId value rfx_process_message_region: - replaced invalid reallocs with malloc - read and verify regionType and numTileSets from stream rfx_process_message_tileset: - check allocation results - fixed incorrect usages of realloc setupWorkers: - fixed incorrect usages of realloc rfx_split_message: - removed dead code - missing malloc check rfx_compose_message: - fixed a memory leak - check/handle rfx_encode_message result
2015-04-23 16:42:21 +03:00
if (!rfx_compose_message(context->rfx_context, s,
&rect, 1, rgb_data, rect.width, rect.height, rect.width * 3))
{
goto out;
}
cmd->codecID = client->settings->RemoteFxCodecId;
2012-03-18 12:36:38 +04:00
}
else
{
nsc_compose_message(context->nsc_context, s,
rgb_data, rect.width, rect.height, rect.width * 3);
cmd->codecID = client->settings->NSCodecId;
2012-03-18 12:36:38 +04:00
}
cmd->destLeft = 0;
cmd->destTop = 0;
cmd->destRight = rect.width;
cmd->destBottom = rect.height;
cmd->bpp = 32;
cmd->width = rect.width;
cmd->height = rect.height;
cmd->bitmapDataLength = Stream_GetPosition(s);
2013-05-09 00:27:21 +04:00
cmd->bitmapData = Stream_Buffer(s);
codec/rfx: error checking and various fixes - removed some unneeded null checks for free() - fixed a memory leak in shadow_client - removed rfx_compose_message_header from API Changed the following functions to BOOL, check the result where they are called and handle failures: - rfx_compose_message - rfx_compose_message_header - rfx_write_tile - rfx_write_message_tileset - rfx_write_message_frame_begin - rfx_write_message_region - rfx_write_message_frame_end - rfx_write_message rfx_process_message: - check memory allocation failures - verify protocol-conform order of data messages to prevents memory leaks caused by repeated allocations - verify that header messages were parsed/received before the data messages - treat unknown rlgr mode as error - fixed/added error handling - fixed all callers to check/handle result rfx_encode_message: - fixed incorrect usage of realloc - missing malloc check - missing check of CreateThreadpoolWork - correct cleanup on failure (threadpool, memory) - check rfx_encode_message result rfx_encode_messages: - check rfx_split_message result - correct cleanup on failure - prevent memory leak on failure rfx_write_message_context: - fixed invalid channelId value (must be 0xFF for WBT_CONTEXT) rfx_process_message_codec_versions: - fixed invalid read size of codec_version (it is 16bit) rfx_process_message_channels: - verify protocol conform channelId value rfx_process_message_region: - replaced invalid reallocs with malloc - read and verify regionType and numTileSets from stream rfx_process_message_tileset: - check allocation results - fixed incorrect usages of realloc setupWorkers: - fixed incorrect usages of realloc rfx_split_message: - removed dead code - missing malloc check rfx_compose_message: - fixed a memory leak - check/handle rfx_encode_message result
2015-04-23 16:42:21 +03:00
test_peer_begin_frame(client);
update->SurfaceBits(update->context, cmd);
codec/rfx: error checking and various fixes - removed some unneeded null checks for free() - fixed a memory leak in shadow_client - removed rfx_compose_message_header from API Changed the following functions to BOOL, check the result where they are called and handle failures: - rfx_compose_message - rfx_compose_message_header - rfx_write_tile - rfx_write_message_tileset - rfx_write_message_frame_begin - rfx_write_message_region - rfx_write_message_frame_end - rfx_write_message rfx_process_message: - check memory allocation failures - verify protocol-conform order of data messages to prevents memory leaks caused by repeated allocations - verify that header messages were parsed/received before the data messages - treat unknown rlgr mode as error - fixed/added error handling - fixed all callers to check/handle result rfx_encode_message: - fixed incorrect usage of realloc - missing malloc check - missing check of CreateThreadpoolWork - correct cleanup on failure (threadpool, memory) - check rfx_encode_message result rfx_encode_messages: - check rfx_split_message result - correct cleanup on failure - prevent memory leak on failure rfx_write_message_context: - fixed invalid channelId value (must be 0xFF for WBT_CONTEXT) rfx_process_message_codec_versions: - fixed invalid read size of codec_version (it is 16bit) rfx_process_message_channels: - verify protocol conform channelId value rfx_process_message_region: - replaced invalid reallocs with malloc - read and verify regionType and numTileSets from stream rfx_process_message_tileset: - check allocation results - fixed incorrect usages of realloc setupWorkers: - fixed incorrect usages of realloc rfx_split_message: - removed dead code - missing malloc check rfx_compose_message: - fixed a memory leak - check/handle rfx_encode_message result
2015-04-23 16:42:21 +03:00
test_peer_end_frame(client);
ret = TRUE;
codec/rfx: error checking and various fixes - removed some unneeded null checks for free() - fixed a memory leak in shadow_client - removed rfx_compose_message_header from API Changed the following functions to BOOL, check the result where they are called and handle failures: - rfx_compose_message - rfx_compose_message_header - rfx_write_tile - rfx_write_message_tileset - rfx_write_message_frame_begin - rfx_write_message_region - rfx_write_message_frame_end - rfx_write_message rfx_process_message: - check memory allocation failures - verify protocol-conform order of data messages to prevents memory leaks caused by repeated allocations - verify that header messages were parsed/received before the data messages - treat unknown rlgr mode as error - fixed/added error handling - fixed all callers to check/handle result rfx_encode_message: - fixed incorrect usage of realloc - missing malloc check - missing check of CreateThreadpoolWork - correct cleanup on failure (threadpool, memory) - check rfx_encode_message result rfx_encode_messages: - check rfx_split_message result - correct cleanup on failure - prevent memory leak on failure rfx_write_message_context: - fixed invalid channelId value (must be 0xFF for WBT_CONTEXT) rfx_process_message_codec_versions: - fixed invalid read size of codec_version (it is 16bit) rfx_process_message_channels: - verify protocol conform channelId value rfx_process_message_region: - replaced invalid reallocs with malloc - read and verify regionType and numTileSets from stream rfx_process_message_tileset: - check allocation results - fixed incorrect usages of realloc setupWorkers: - fixed incorrect usages of realloc rfx_split_message: - removed dead code - missing malloc check rfx_compose_message: - fixed a memory leak - check/handle rfx_encode_message result
2015-04-23 16:42:21 +03:00
out:
free(rgb_data);
return ret;
}
static BOOL test_peer_load_icon(freerdp_peer* client)
2011-08-24 19:10:23 +04:00
{
testPeerContext* context = (testPeerContext*) client->context;
2011-08-24 19:10:23 +04:00
FILE* fp;
int i;
char line[50];
2015-06-23 13:09:42 +03:00
BYTE* rgb_data = NULL;
2011-08-24 19:10:23 +04:00
int c;
if (!client->settings->RemoteFxCodec && !client->settings->NSCodec)
{
WLog_ERR(TAG, "Client doesn't support RemoteFX or NSCodec");
return FALSE;
}
2011-08-24 19:10:23 +04:00
if ((fp = fopen("test_icon.ppm", "r")) == NULL)
{
WLog_ERR(TAG, "Unable to open test icon");
return FALSE;
}
2011-08-24 19:10:23 +04:00
/* P3 */
fgets(line, sizeof(line), fp);
/* Creater comment */
fgets(line, sizeof(line), fp);
/* width height */
fgets(line, sizeof(line), fp);
if (sscanf(line, "%d %d", &context->icon_width, &context->icon_height) < 2)
{
WLog_ERR(TAG, "Problem while extracting width/height from the icon file");
goto out_fail;
}
2011-08-24 19:10:23 +04:00
/* Max */
fgets(line, sizeof(line), fp);
if (!(rgb_data = malloc(context->icon_width * context->icon_height * 3)))
goto out_fail;
2011-08-24 19:10:23 +04:00
for (i = 0; i < context->icon_width * context->icon_height * 3; i++)
2011-08-24 19:10:23 +04:00
{
if (!fgets(line, sizeof(line), fp) || (sscanf(line, "%d", &c) != 1))
goto out_fail;
rgb_data[i] = (BYTE)c;
2011-08-24 19:10:23 +04:00
}
/* background with same size, which will be used to erase the icon from old position */
if (!(context->bg_data = malloc(context->icon_width * context->icon_height * 3)))
goto out_fail;
memset(context->bg_data, 0xA0, context->icon_width * context->icon_height * 3);
context->icon_data = rgb_data;
fclose(fp);
return TRUE;
out_fail:
free(rgb_data);
context->bg_data = NULL;
fclose(fp);
return FALSE;
2011-08-24 19:10:23 +04:00
}
static void test_peer_draw_icon(freerdp_peer* client, int x, int y)
{
wStream* s;
RFX_RECT rect;
2011-08-24 19:10:23 +04:00
rdpUpdate* update = client->update;
SURFACE_BITS_COMMAND* cmd = &update->surface_bits_command;
testPeerContext* context = (testPeerContext*) client->context;
2011-08-24 19:10:23 +04:00
if (client->update->dump_rfx)
return;
2012-03-18 12:36:38 +04:00
if (!context)
2011-08-24 19:10:23 +04:00
return;
if (context->icon_width < 1 || !context->activated)
2011-08-24 19:10:23 +04:00
return;
test_peer_begin_frame(client);
rect.x = 0;
rect.y = 0;
rect.width = context->icon_width;
rect.height = context->icon_height;
2011-08-24 19:10:23 +04:00
if (context->icon_x >= 0)
2011-08-24 19:10:23 +04:00
{
s = test_peer_stream_init(context);
if (client->settings->RemoteFxCodec)
2012-03-18 12:36:38 +04:00
{
rfx_compose_message(context->rfx_context, s,
&rect, 1, context->bg_data, rect.width, rect.height, rect.width * 3);
cmd->codecID = client->settings->RemoteFxCodecId;
2012-03-18 12:36:38 +04:00
}
else
{
nsc_compose_message(context->nsc_context, s,
context->bg_data, rect.width, rect.height, rect.width * 3);
cmd->codecID = client->settings->NSCodecId;
2012-03-18 12:36:38 +04:00
}
cmd->destLeft = context->icon_x;
cmd->destTop = context->icon_y;
cmd->destRight = context->icon_x + context->icon_width;
cmd->destBottom = context->icon_y + context->icon_height;
cmd->bpp = 32;
cmd->width = context->icon_width;
cmd->height = context->icon_height;
cmd->bitmapDataLength = Stream_GetPosition(s);
2013-05-09 00:27:21 +04:00
cmd->bitmapData = Stream_Buffer(s);
update->SurfaceBits(update->context, cmd);
2011-08-24 19:10:23 +04:00
}
s = test_peer_stream_init(context);
if (client->settings->RemoteFxCodec)
2012-03-18 12:36:38 +04:00
{
rfx_compose_message(context->rfx_context, s,
&rect, 1, context->icon_data, rect.width, rect.height, rect.width * 3);
cmd->codecID = client->settings->RemoteFxCodecId;
2012-03-18 12:36:38 +04:00
}
else
{
nsc_compose_message(context->nsc_context, s,
context->icon_data, rect.width, rect.height, rect.width * 3);
cmd->codecID = client->settings->NSCodecId;
2012-03-18 12:36:38 +04:00
}
2011-08-24 19:10:23 +04:00
cmd->destLeft = x;
cmd->destTop = y;
cmd->destRight = x + context->icon_width;
cmd->destBottom = y + context->icon_height;
cmd->bpp = 32;
cmd->width = context->icon_width;
cmd->height = context->icon_height;
cmd->bitmapDataLength = Stream_GetPosition(s);
2013-05-09 00:27:21 +04:00
cmd->bitmapData = Stream_Buffer(s);
update->SurfaceBits(update->context, cmd);
2011-08-24 19:10:23 +04:00
context->icon_x = x;
context->icon_y = y;
test_peer_end_frame(client);
2011-08-24 19:10:23 +04:00
}
2012-10-09 11:26:39 +04:00
static BOOL test_sleep_tsdiff(UINT32 *old_sec, UINT32 *old_usec, UINT32 new_sec, UINT32 new_usec)
{
2012-10-09 11:26:39 +04:00
INT32 sec, usec;
if ((*old_sec == 0) && (*old_usec == 0))
{
*old_sec = new_sec;
*old_usec = new_usec;
return TRUE;
}
sec = new_sec - *old_sec;
usec = new_usec - *old_usec;
if ((sec < 0) || ((sec == 0) && (usec < 0)))
{
2014-09-12 19:38:12 +04:00
WLog_ERR(TAG, "Invalid time stamp detected.");
return FALSE;
}
*old_sec = new_sec;
*old_usec = new_usec;
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
while (usec < 0)
{
usec += 1000000;
sec--;
}
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 (sec > 0)
Sleep(sec * 1000);
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 (usec > 0)
USleep(usec);
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 TRUE;
}
BOOL tf_peer_dump_rfx(freerdp_peer* client)
{
wStream* s;
2012-10-09 11:26:39 +04:00
UINT32 prev_seconds;
UINT32 prev_useconds;
rdpUpdate* update;
rdpPcap* pcap_rfx;
pcap_record record;
2013-05-09 01:48:30 +04:00
s = Stream_New(NULL, 512);
if (!s)
return FALSE;
update = client->update;
if (!(pcap_rfx = pcap_open(test_pcap_file, FALSE)))
return FALSE;
prev_seconds = prev_useconds = 0;
while (pcap_has_next_record(pcap_rfx))
{
BYTE* tmp = NULL;
if (!pcap_get_next_record_header(pcap_rfx, &record))
break;
tmp = realloc(Stream_Buffer(s), record.length);
if (!tmp)
break;
Stream_Buffer(s) = tmp;
record.data = Stream_Buffer(s);
Stream_Capacity(s) = record.length;
pcap_get_next_record_content(pcap_rfx, &record);
Stream_Pointer(s) = Stream_Buffer(s) + Stream_Capacity(s);
if (test_dump_rfx_realtime && test_sleep_tsdiff(&prev_seconds, &prev_useconds, record.header.ts_sec, record.header.ts_usec) == FALSE)
break;
update->SurfaceCommand(update->context, s);
if (client->CheckFileDescriptor(client) != TRUE)
break;
}
Stream_Free(s, TRUE);
pcap_close(pcap_rfx);
return TRUE;
}
static void* tf_debug_channel_thread_func(void* arg)
{
void* fd;
wStream* s;
void* buffer;
DWORD BytesReturned = 0;
ULONG written;
testPeerContext* context = (testPeerContext*) arg;
if (WTSVirtualChannelQuery(context->debug_channel, WTSVirtualFileHandle, &buffer, &BytesReturned) == TRUE)
{
fd = *((void**) buffer);
WTSFreeMemory(buffer);
if (!(context->event = CreateWaitObjectEvent(NULL, TRUE, FALSE, fd)))
return NULL;
}
2013-05-09 01:48:30 +04:00
s = Stream_New(NULL, 4096);
WTSVirtualChannelWrite(context->debug_channel, (PCHAR) "test1", 5, &written);
while (1)
{
WaitForSingleObject(context->event, INFINITE);
if (WaitForSingleObject(context->stopEvent, 0) == WAIT_OBJECT_0)
break;
Stream_SetPosition(s, 0);
if (WTSVirtualChannelRead(context->debug_channel, 0, (PCHAR) Stream_Buffer(s),
Stream_Capacity(s), &BytesReturned) == FALSE)
{
if (BytesReturned == 0)
break;
Stream_EnsureRemainingCapacity(s, BytesReturned);
if (WTSVirtualChannelRead(context->debug_channel, 0, (PCHAR) Stream_Buffer(s),
Stream_Capacity(s), &BytesReturned) == FALSE)
{
/* should not happen */
break;
}
}
Stream_SetPosition(s, BytesReturned);
2014-09-12 19:38:12 +04:00
WLog_DBG(TAG, "got %lu bytes", BytesReturned);
}
2013-05-09 01:48:30 +04:00
Stream_Free(s, TRUE);
return 0;
}
BOOL tf_peer_post_connect(freerdp_peer* client)
2011-08-22 19:02:56 +04:00
{
2011-12-12 10:12:16 +04:00
testPeerContext* context = (testPeerContext*) client->context;
2011-08-22 19:02:56 +04:00
/**
* This callback is called when the entire connection sequence is done, i.e. we've received the
* Font List PDU from the client and sent out the Font Map PDU.
* The server may start sending graphics output and receiving keyboard/mouse input after this
* callback returns.
*/
2014-09-12 19:38:12 +04:00
WLog_DBG(TAG, "Client %s is activated (osMajorType %d osMinorType %d)", client->local ? "(local)" : client->hostname,
client->settings->OsMajorType, client->settings->OsMinorType);
if (client->settings->AutoLogonEnabled)
2011-08-22 19:02:56 +04:00
{
2014-09-12 19:38:12 +04:00
WLog_DBG(TAG, " and wants to login automatically as %s\\%s",
client->settings->Domain ? client->settings->Domain : "",
client->settings->Username);
2011-08-22 19:02:56 +04:00
/* A real server may perform OS login here if NLA is not executed previously. */
}
2011-08-23 11:51:51 +04:00
2014-09-12 19:38:12 +04:00
WLog_DBG(TAG, "");
WLog_DBG(TAG, "Client requested desktop: %dx%dx%d",
client->settings->DesktopWidth, client->settings->DesktopHeight, client->settings->ColorDepth);
#if (SAMPLE_SERVER_USE_CLIENT_RESOLUTION == 1)
context->rfx_context->width = client->settings->DesktopWidth;
context->rfx_context->height = client->settings->DesktopHeight;
2014-09-12 19:38:12 +04:00
WLog_DBG(TAG, "Using resolution requested by client.");
#else
client->settings->DesktopWidth = context->rfx_context->width;
client->settings->DesktopHeight = context->rfx_context->height;
2014-09-12 19:38:12 +04:00
WLog_DBG(TAG, "Resizing client to %dx%d", client->settings->DesktopWidth, client->settings->DesktopHeight);
client->update->DesktopResize(client->update->context);
#endif
2012-11-26 21:38:28 +04:00
/* A real server should tag the peer as activated here and start sending updates in main loop. */
if (!test_peer_load_icon(client))
{
WLog_DBG(TAG, "Unable to load icon");
return FALSE;
}
if (WTSVirtualChannelManagerIsChannelJoined(context->vcm, "rdpdbg"))
2011-12-12 10:12:16 +04:00
{
2014-03-03 21:10:06 +04:00
context->debug_channel = WTSVirtualChannelOpen(context->vcm, WTS_CURRENT_SESSION, "rdpdbg");
if (context->debug_channel != NULL)
{
2014-09-12 19:38:12 +04:00
WLog_DBG(TAG, "Open channel rdpdbg.");
if (!(context->stopEvent = CreateEvent(NULL, TRUE, FALSE, NULL)))
{
WLog_ERR(TAG, "Failed to create stop event");
return FALSE;
}
if (!(context->debug_channel_thread = CreateThread(NULL, 0,
(LPTHREAD_START_ROUTINE) tf_debug_channel_thread_func, (void*) context, 0, NULL)))
{
WLog_ERR(TAG, "Failed to create debug channel thread");
CloseHandle(context->stopEvent);
context->stopEvent = NULL;
return FALSE;
}
2011-12-12 10:12:16 +04:00
}
}
if (WTSVirtualChannelManagerIsChannelJoined(context->vcm, "rdpsnd"))
{
sf_peer_rdpsnd_init(context); /* Audio Output */
}
if (WTSVirtualChannelManagerIsChannelJoined(context->vcm, "encomsp"))
{
sf_peer_encomsp_init(context); /* Lync Multiparty */
}
/* Dynamic Virtual Channels */
sf_peer_audin_init(context); /* Audio Input */
/* Return FALSE here would stop the execution of the peer main loop. */
return TRUE;
}
BOOL tf_peer_activate(freerdp_peer* client)
{
testPeerContext* context = (testPeerContext*) client->context;
rfx_context_reset(context->rfx_context);
context->activated = TRUE;
//client->settings->CompressionLevel = PACKET_COMPR_TYPE_8K;
//client->settings->CompressionLevel = PACKET_COMPR_TYPE_64K;
//client->settings->CompressionLevel = PACKET_COMPR_TYPE_RDP6;
client->settings->CompressionLevel = PACKET_COMPR_TYPE_RDP61;
if (test_pcap_file != NULL)
{
client->update->dump_rfx = TRUE;
if (!tf_peer_dump_rfx(client))
return FALSE;
}
else
test_peer_draw_background(client);
return TRUE;
2011-08-22 19:02:56 +04:00
}
BOOL tf_peer_synchronize_event(rdpInput* input, UINT32 flags)
2011-08-23 07:50:41 +04:00
{
2014-09-12 19:38:12 +04:00
WLog_DBG(TAG, "Client sent a synchronize event (flags:0x%X)", flags);
2015-04-21 15:15:53 +03:00
return TRUE;
2011-08-23 07:50:41 +04:00
}
BOOL tf_peer_keyboard_event(rdpInput* input, UINT16 flags, UINT16 code)
2011-08-23 07:50:41 +04:00
{
freerdp_peer* client = input->context->peer;
2011-09-06 13:19:59 +04:00
rdpUpdate* update = client->update;
testPeerContext* context = (testPeerContext*) input->context;
2014-09-12 19:38:12 +04:00
WLog_DBG(TAG, "Client sent a keyboard event (flags:0x%X code:0x%X)", flags, code);
2011-09-06 13:19:59 +04:00
if ((flags & 0x4000) && code == 0x22) /* 'g' key */
2011-09-06 13:19:59 +04:00
{
2012-11-26 21:38:28 +04:00
if (client->settings->DesktopWidth != 800)
2011-09-06 13:19:59 +04:00
{
2012-11-26 21:38:28 +04:00
client->settings->DesktopWidth = 800;
client->settings->DesktopHeight = 600;
2011-09-06 13:19:59 +04:00
}
else
{
2013-06-24 20:02:21 +04:00
client->settings->DesktopWidth = SAMPLE_SERVER_DEFAULT_WIDTH;
client->settings->DesktopHeight = SAMPLE_SERVER_DEFAULT_HEIGHT;
2011-09-06 13:19:59 +04:00
}
2013-06-24 20:02:21 +04:00
context->rfx_context->width = client->settings->DesktopWidth;
context->rfx_context->height = client->settings->DesktopHeight;
update->DesktopResize(update->context);
context->activated = FALSE;
2011-09-06 13:19:59 +04:00
}
else if ((flags & 0x4000) && code == 0x2E) /* 'c' key */
{
if (context->debug_channel)
{
ULONG written;
WTSVirtualChannelWrite(context->debug_channel, (PCHAR) "test2", 5, &written);
}
}
else if ((flags & 0x4000) && code == 0x2D) /* 'x' key */
{
client->Close(client);
}
else if ((flags & 0x4000) && code == 0x13) /* 'r' key */
{
if (!context->audin_open)
{
context->audin->Open(context->audin);
context->audin_open = TRUE;
}
else
{
context->audin->Close(context->audin);
context->audin_open = FALSE;
}
}
else if ((flags & 0x4000) && code == 0x1F) /* 's' key */
{
}
2015-04-21 15:15:53 +03:00
return TRUE;
2011-08-23 07:50:41 +04:00
}
BOOL tf_peer_unicode_keyboard_event(rdpInput* input, UINT16 flags, UINT16 code)
2011-08-23 07:50:41 +04:00
{
2014-09-12 19:38:12 +04:00
WLog_DBG(TAG, "Client sent a unicode keyboard event (flags:0x%X code:0x%X)", flags, code);
2015-04-21 15:15:53 +03:00
return TRUE;
2011-08-23 07:50:41 +04:00
}
BOOL tf_peer_mouse_event(rdpInput* input, UINT16 flags, UINT16 x, UINT16 y)
2011-08-23 07:50:41 +04:00
{
2014-09-12 19:38:12 +04:00
//WLog_DBG(TAG, "Client sent a mouse event (flags:0x%X pos:%d,%d)", flags, x, y);
test_peer_draw_icon(input->context->peer, x + 10, y);
2015-04-21 15:15:53 +03:00
return TRUE;
2011-08-23 07:50:41 +04:00
}
BOOL tf_peer_extended_mouse_event(rdpInput* input, UINT16 flags, UINT16 x, UINT16 y)
2011-08-23 07:50:41 +04:00
{
2014-09-12 19:38:12 +04:00
//WLog_DBG(TAG, "Client sent an extended mouse event (flags:0x%X pos:%d,%d)", flags, x, y);
2015-04-21 15:15:53 +03:00
return TRUE;
2011-08-23 07:50:41 +04:00
}
static BOOL tf_peer_refresh_rect(rdpContext* context, BYTE count, RECTANGLE_16* areas)
{
BYTE i;
2014-09-12 19:38:12 +04:00
WLog_DBG(TAG, "Client requested to refresh:");
for (i = 0; i < count; i++)
{
2014-09-12 19:38:12 +04:00
WLog_DBG(TAG, " (%d, %d) (%d, %d)", areas[i].left, areas[i].top, areas[i].right, areas[i].bottom);
}
2015-04-21 15:15:53 +03:00
return TRUE;
}
static BOOL tf_peer_suppress_output(rdpContext* context, BYTE allow, RECTANGLE_16* area)
{
if (allow > 0)
{
2014-09-12 19:38:12 +04:00
WLog_DBG(TAG, "Client restore output (%d, %d) (%d, %d).", area->left, area->top, area->right, area->bottom);
}
else
{
2014-09-12 19:38:12 +04:00
WLog_DBG(TAG, "Client minimized and suppress output.");
}
2015-04-21 15:15:53 +03:00
return TRUE;
}
2011-08-18 12:06:32 +04:00
static void* test_peer_mainloop(void* arg)
{
2015-04-19 11:31:28 +03:00
HANDLE handles[32];
DWORD count;
DWORD status;
2011-12-12 12:42:42 +04:00
testPeerContext* context;
freerdp_peer* client = (freerdp_peer*) arg;
2011-08-18 12:06:32 +04:00
if (!test_peer_init(client))
{
freerdp_peer_free(client);
return NULL;
}
2011-08-18 12:06:32 +04:00
2011-08-23 07:50:41 +04:00
/* Initialize the real server settings here */
client->settings->CertificateFile = _strdup("server.crt");
client->settings->PrivateKeyFile = _strdup("server.key");
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
client->settings->RdpKeyFile = _strdup("server.key");
if (!client->settings->CertificateFile || !client->settings->PrivateKeyFile || !client->settings->RdpKeyFile)
{
WLog_ERR(TAG, "Memory allocation failed (strdup)");
freerdp_peer_free(client);
return NULL;
}
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
client->settings->RdpSecurity = TRUE;
client->settings->TlsSecurity = TRUE;
client->settings->NlaSecurity = 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
client->settings->EncryptionLevel = ENCRYPTION_LEVEL_CLIENT_COMPATIBLE;
/* client->settings->EncryptionLevel = ENCRYPTION_LEVEL_HIGH; */
/* client->settings->EncryptionLevel = ENCRYPTION_LEVEL_LOW; */
/* client->settings->EncryptionLevel = ENCRYPTION_LEVEL_FIPS; */
client->settings->RemoteFxCodec = TRUE;
client->settings->ColorDepth = 32;
client->settings->SuppressOutput = TRUE;
client->settings->RefreshRect = TRUE;
2011-08-22 19:02:56 +04:00
client->PostConnect = tf_peer_post_connect;
client->Activate = tf_peer_activate;
2011-08-23 07:50:41 +04:00
client->input->SynchronizeEvent = tf_peer_synchronize_event;
client->input->KeyboardEvent = tf_peer_keyboard_event;
client->input->UnicodeKeyboardEvent = tf_peer_unicode_keyboard_event;
client->input->MouseEvent = tf_peer_mouse_event;
client->input->ExtendedMouseEvent = tf_peer_extended_mouse_event;
2011-08-23 07:50:41 +04:00
client->update->RefreshRect = tf_peer_refresh_rect;
client->update->SuppressOutput = tf_peer_suppress_output;
client->settings->MultifragMaxRequestSize = 0xFFFFFF; /* FIXME */
2011-08-18 12:06:32 +04:00
client->Initialize(client);
2011-12-12 12:42:42 +04:00
context = (testPeerContext*) client->context;
2014-09-12 19:38:12 +04:00
WLog_INFO(TAG, "We've got a client %s", client->local ? "(local)" : client->hostname);
2011-08-18 12:06:32 +04:00
while (1)
{
2015-04-19 11:31:28 +03:00
count = 0;
handles[count++] = client->GetEventHandle(client);
handles[count++] = WTSVirtualChannelManagerGetEventHandle(context->vcm);
2013-06-24 20:02:21 +04:00
2015-04-19 11:31:28 +03:00
status = WaitForMultipleObjects(count, handles, FALSE, INFINITE);
2011-08-18 12:06:32 +04:00
2015-04-19 11:31:28 +03:00
if (status == WAIT_FAILED)
2011-08-18 12:06:32 +04:00
{
2015-04-19 11:31:28 +03:00
WLog_ERR(TAG, "WaitForMultipleObjects failed (errno: %d)", errno);
2011-08-18 12:06:32 +04:00
break;
}
if (client->CheckFileDescriptor(client) != TRUE)
2011-12-12 12:42:42 +04:00
break;
if (WTSVirtualChannelManagerCheckFileDescriptor(context->vcm) != TRUE)
2011-08-18 12:06:32 +04:00
break;
}
2014-09-12 19:38:12 +04:00
WLog_INFO(TAG, "Client %s disconnected.", client->local ? "(local)" : client->hostname);
2011-08-18 12:06:32 +04:00
client->Disconnect(client);
freerdp_peer_context_free(client);
2011-08-18 12:06:32 +04:00
freerdp_peer_free(client);
return NULL;
}
static BOOL test_peer_accepted(freerdp_listener* instance, freerdp_peer* client)
2011-08-18 12:06:32 +04:00
{
HANDLE hThread;
if (!(hThread = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE) test_peer_mainloop, (void*) client, 0, NULL)))
return FALSE;
CloseHandle(hThread);
return TRUE;
2011-08-18 12:06:32 +04:00
}
static void test_server_mainloop(freerdp_listener* instance)
{
2015-04-19 11:36:20 +03:00
HANDLE handles[32];
DWORD count;
DWORD status;
2011-08-18 12:06:32 +04:00
while (1)
{
count = instance->GetEventHandles(instance, handles, 32);
if (0 == count)
2011-08-18 12:06:32 +04:00
{
2015-04-19 11:36:20 +03:00
WLog_ERR(TAG, "Failed to get FreeRDP event handles");
2011-08-18 12:06:32 +04:00
break;
}
2015-04-19 11:36:20 +03:00
status = WaitForMultipleObjects(count, handles, FALSE, INFINITE);
2011-08-18 12:06:32 +04:00
2015-04-19 11:36:20 +03:00
if (WAIT_FAILED == status)
2011-08-18 12:06:32 +04:00
{
2015-04-19 11:36:20 +03:00
WLog_ERR(TAG, "select failed");
2011-08-18 12:06:32 +04:00
break;
}
if (instance->CheckFileDescriptor(instance) != TRUE)
2011-08-18 12:06:32 +04:00
{
2014-09-12 19:38:12 +04:00
WLog_ERR(TAG, "Failed to check FreeRDP file descriptor");
2011-08-18 12:06:32 +04:00
break;
}
}
instance->Close(instance);
}
int main(int argc, char* argv[])
{
2014-11-12 22:06:34 +03:00
WSADATA wsaData;
2011-08-18 12:06:32 +04:00
freerdp_listener* instance;
char* file;
char name[MAX_PATH];
int port = 3389, i;
for (i=1; i<argc; i++)
{
char* arg = argv[i];
if (strncmp(arg, "--fast", 7) == 0)
test_dump_rfx_realtime = FALSE;
else if (strncmp(arg, "--port=", 7) == 0)
{
StrSep(&arg, "=");
if (!arg)
return -1;
port = strtol(arg, NULL, 10);
if ((port < 1) || (port > 0xFFFF))
return -1;
}
else if (strncmp(arg, "--", 2))
test_pcap_file = arg;
}
2011-08-18 12:06:32 +04:00
2014-03-03 21:10:06 +04:00
WTSRegisterWtsApiFunctionTable(FreeRDP_InitWtsApi());
2011-08-18 12:06:32 +04:00
instance = freerdp_listener_new();
if (!instance)
return -1;
2011-08-18 12:06:32 +04:00
instance->PeerAccepted = test_peer_accepted;
2014-11-12 22:06:34 +03:00
if (WSAStartup(MAKEWORD(2, 2), &wsaData) != 0)
{
freerdp_listener_free(instance);
return -1;
}
2014-11-12 22:06:34 +03:00
2011-08-18 12:06:32 +04:00
/* Open the server socket and start listening. */
2015-07-03 14:26:15 +03:00
sprintf_s(name, sizeof(name), "tfreerdp-server.%d", port);
file = GetKnownSubPath(KNOWN_PATH_TEMP, name);
if (!file)
{
freerdp_listener_free(instance);
WSACleanup();
return -1;
}
2014-11-12 22:06:34 +03:00
if (instance->Open(instance, NULL, port) &&
instance->OpenLocal(instance, file))
2011-08-18 12:06:32 +04:00
{
/* Entering the server main loop. In a real server the listener can be run in its own thread. */
test_server_mainloop(instance);
}
free (file);
2011-08-18 12:06:32 +04:00
freerdp_listener_free(instance);
2014-11-12 22:06:34 +03:00
WSACleanup();
2011-08-18 12:06:32 +04:00
return 0;
}