libfreerdp-core: expand comments for connection sequence, split in more steps server-side connection code

This commit is contained in:
Marc-André Moreau 2013-07-18 15:18:59 -04:00
parent 7e63668090
commit f27ab422e3
5 changed files with 180 additions and 57 deletions

View File

@ -313,7 +313,7 @@ BOOL rdp_recv_deactivate_all(rdpRdp* rdp, wStream* s)
while(0);
}
rdp->state = CONNECTION_STATE_CAPABILITY;
rdp->state = CONNECTION_STATE_CAPABILITIES_EXCHANGE;
while (rdp->state != CONNECTION_STATE_ACTIVE)
{
@ -370,6 +370,9 @@ BOOL rdp_server_accept_client_font_list_pdu(rdpRdp* rdp, wStream* s)
if (!rdp_send_server_font_map_pdu(rdp))
return FALSE;
rdp->state = CONNECTION_STATE_ACTIVE;
update_reset_state(rdp->update);
return TRUE;
}

View File

@ -61,6 +61,103 @@
*
*/
/**
*
* Connection Sequence
*
* 1. Connection Initiation: The client initiates the connection by sending the server a
* Class 0 X.224 Connection Request PDU (section 2.2.1.1). The server responds with a
* Class 0 X.224 Connection Confirm PDU (section 2.2.1.2). From this point, all subsequent
* data sent between client and server is wrapped in an X.224 Data Protocol Data Unit (PDU).
*
* 2. Basic Settings Exchange: Basic settings are exchanged between the client and server by
* using the MCS Connect Initial PDU (section 2.2.1.3) and MCS Connect Response PDU (section 2.2.1.4).
* The Connect Initial PDU contains a Generic Conference Control (GCC) Conference Create Request,
* while the Connect Response PDU contains a GCC Conference Create Response. These two GCC packets
* contain concatenated blocks of settings data (such as core data, security data, and network data)
* which are read by client and server.
*
* 3. Channel Connection: The client sends an MCS Erect Domain Request PDU (section 2.2.1.5),
* followed by an MCS Attach User Request PDU (section 2.2.1.6) to attach the primary user identity
* to the MCS domain. The server responds with an MCS Attach User Confirm PDU (section 2.2.1.7)
* containing the User Channel ID. The client then proceeds to join the user channel, the
* input/output (I/O) channel, and all of the static virtual channels (the I/O and static virtual
* channel IDs are obtained from the data embedded in the GCC packets) by using multiple MCS Channel
* Join Request PDUs (section 2.2.1.8). The server confirms each channel with an MCS Channel Join
* Confirm PDU (section 2.2.1.9). (The client only sends a Channel Join Request after it has received
* the Channel Join Confirm for the previously sent request.)
*
* From this point, all subsequent data sent from the client to the server is wrapped in an MCS Send
* Data Request PDU, while data sent from the server to the client is wrapped in an MCS Send Data
* Indication PDU. This is in addition to the data being wrapped by an X.224 Data PDU.
*
* 4. RDP Security Commencement: If Standard RDP Security mechanisms (section 5.3) are being employed and
* encryption is in force (this is determined by examining the data embedded in the GCC Conference Create
* Response packet) then the client sends a Security Exchange PDU (section 2.2.1.10) containing an encrypted
* 32-byte random number to the server. This random number is encrypted with the public key of the server
* as described in section 5.3.4.1 (the server's public key, as well as a 32-byte server-generated random
* number, are both obtained from the data embedded in the GCC Conference Create Response packet). The client
* and server then utilize the two 32-byte random numbers to generate session keys which are used to encrypt
* and validate the integrity of subsequent RDP traffic.
*
* From this point, all subsequent RDP traffic can be encrypted and a security header is included with the
* data if encryption is in force. (The Client Info PDU (section 2.2.1.11) and licensing PDUs ([MS-RDPELE]
* section 2.2.2) are an exception in that they always have a security header). The Security Header follows
* the X.224 and MCS Headers and indicates whether the attached data is encrypted. Even if encryption is in
* force, server-to-client traffic may not always be encrypted, while client-to-server traffic must always be
* encrypted (encryption of licensing PDUs is optional, however).
*
* 5. Secure Settings Exchange: Secure client data (such as the username, password, and auto-reconnect cookie)
* is sent to the server by using the Client Info PDU (section 2.2.1.11).
*
* 6. Optional Connect-Time Auto-Detection: During the optional connect-time auto-detect phase the goal is to
* determine characteristics of the network, such as the round-trip latency time and the bandwidth of the link
* between the server and client. This is accomplished by exchanging a collection of PDUs (specified in section 2.2.1.4)
* over a predetermined period of time with enough data to ensure that the results are statistically relevant.
*
* 7. Licensing: The goal of the licensing exchange is to transfer a license from the server to the client.
* The client stores this license and on subsequent connections sends the license to the server for validation.
* However, in some situations the client may not be issued a license to store. In effect, the packets exchanged
* during this phase of the protocol depend on the licensing mechanisms employed by the server. Within the context
* of this document, it is assumed that the client will not be issued a license to store. For details regarding
* more advanced licensing scenarios that take place during the Licensing Phase, see [MS-RDPELE] section 1.3.
*
* 8. Optional Multitransport Bootstrapping: After the connection has been secured and the Licensing Phase has run
* to completion, the server can choose to initiate multitransport connections ([MS-RDPEMT] section 1.3).
* The Initiate Multitransport Request PDU (section 2.2.15.1) is sent by the server to the client and results
* in the out-of-band creation of a multitransport connection using messages from the RDP-UDP, TLS, DTLS, and
* multitransport protocols ([MS-RDPEMT] section 1.3.1).
*
* 9. Capabilities Exchange: The server sends the set of capabilities it supports to the client in a Demand Active PDU
* (section 2.2.1.13.1). The client responds with its capabilities by sending a Confirm Active PDU (section 2.2.1.13.2).
*
* 10. Connection Finalization: The client and server exchange PDUs to finalize the connection details. The client-to-server
* PDUs sent during this phase have no dependencies on any of the server-to-client PDUs; they may be sent as a single batch,
* provided that sequencing is maintained.
*
* - The Client Synchronize PDU (section 2.2.1.14) is sent after transmitting the Confirm Active PDU.
* - The Client Control (Cooperate) PDU (section 2.2.1.15) is sent after transmitting the Client Synchronize PDU.
* - The Client Control (Request Control) PDU (section 2.2.1.16) is sent after transmitting the Client Control (Cooperate) PDU.
* - The optional Persistent Key List PDUs (section 2.2.1.17) are sent after transmitting the Client Control (Request Control) PDU.
* - The Font List PDU (section 2.2.1.18) is sent after transmitting the Persistent Key List PDUs or, if the Persistent Key List
* PDUs were not sent, it is sent after transmitting the Client Control (Request Control) PDU (section 2.2.1.16).
*
* The server-to-client PDUs sent during the Connection Finalization Phase have dependencies on the client-to-server PDUs.
*
* - The optional Monitor Layout PDU (section 2.2.12.1) has no dependency on any client-to-server PDUs and is sent after the Demand Active PDU.
* - The Server Synchronize PDU (section 2.2.1.19) is sent in response to the Confirm Active PDU.
* - The Server Control (Cooperate) PDU (section 2.2.1.20) is sent after transmitting the Server Synchronize PDU.
* - The Server Control (Granted Control) PDU (section 2.2.1.21) is sent in response to the Client Control (Request Control) PDU.
* - The Font Map PDU (section 2.2.1.22) is sent in response to the Font List PDU.
*
* Once the client has sent the Confirm Active PDU, it can start sending mouse and keyboard input to the server, and upon receipt
* of the Font List PDU the server can start sending graphics output to the client.
*
* Besides input and graphics data, other data that can be exchanged between client and server after the connection has been
* finalized includes connection management information and virtual channel messages (exchanged between client-side plug-ins
* and server-side applications).
*/
/**
* Establish RDP Connection based on the settings given in the 'rdp' parameter.
* @msdn{cc240452}
@ -77,19 +174,18 @@ BOOL rdp_client_connect(rdpRdp* rdp)
if (settings->GatewayEnabled)
{
char* user;
char* user;
char* domain;
char* cookie;
int user_length = 0;
int user_length = 0;
int domain_length;
int cookie_length;
if (settings->Username)
{
user = settings->Username;
user_length = strlen(settings->Username);
}
if (settings->Username)
{
user = settings->Username;
user_length = strlen(settings->Username);
}
if (settings->Domain)
domain = settings->Domain;
@ -105,10 +201,10 @@ BOOL rdp_client_connect(rdpRdp* rdp)
CharUpperBuffA(cookie, domain_length);
cookie[domain_length] = '\\';
if (settings->Username)
CopyMemory(&cookie[domain_length + 1], user, user_length);
if (settings->Username)
CopyMemory(&cookie[domain_length + 1], user, user_length);
cookie[cookie_length] = '\0';
cookie[cookie_length] = '\0';
nego_set_cookie(rdp->nego, cookie);
free(cookie);
@ -505,7 +601,7 @@ BOOL rdp_client_connect_mcs_channel_join_confirm(rdpRdp* rdp, wStream* s)
if (!rdp_send_client_info(rdp))
return FALSE;
rdp->state = CONNECTION_STATE_LICENSE;
rdp->state = CONNECTION_STATE_LICENSING;
}
return TRUE;
@ -524,7 +620,7 @@ BOOL rdp_client_connect_license(rdpRdp* rdp, wStream* s)
if (rdp->license->state == LICENSE_STATE_COMPLETED)
{
rdp->state = CONNECTION_STATE_CAPABILITY;
rdp->state = CONNECTION_STATE_CAPABILITIES_EXCHANGE;
}
return TRUE;
@ -623,8 +719,8 @@ BOOL rdp_server_accept_nego(rdpRdp* rdp, wStream* s)
fprintf(stderr, "Client Security: NLA:%d TLS:%d RDP:%d\n",
(rdp->nego->requested_protocols & PROTOCOL_NLA) ? 1 : 0,
(rdp->nego->requested_protocols & PROTOCOL_TLS) ? 1 : 0,
(rdp->nego->requested_protocols == PROTOCOL_RDP) ? 1: 0);
(rdp->nego->requested_protocols & PROTOCOL_TLS) ? 1 : 0,
(rdp->nego->requested_protocols == PROTOCOL_RDP) ? 1: 0);
fprintf(stderr, "Server Security: NLA:%d TLS:%d RDP:%d\n",
settings->NlaSecurity, settings->TlsSecurity, settings->RdpSecurity);
@ -648,8 +744,8 @@ BOOL rdp_server_accept_nego(rdpRdp* rdp, wStream* s)
fprintf(stderr, "Negotiated Security: NLA:%d TLS:%d RDP:%d\n",
(rdp->nego->selected_protocol & PROTOCOL_NLA) ? 1 : 0,
(rdp->nego->selected_protocol & PROTOCOL_TLS) ? 1 : 0,
(rdp->nego->selected_protocol == PROTOCOL_RDP) ? 1: 0);
(rdp->nego->selected_protocol & PROTOCOL_TLS) ? 1 : 0,
(rdp->nego->selected_protocol == PROTOCOL_RDP) ? 1: 0);
if (!nego_send_negotiation_response(rdp->nego))
return FALSE;
@ -746,35 +842,26 @@ BOOL rdp_server_accept_mcs_channel_join_request(rdpRdp* rdp, wStream* s)
}
if (rdp->mcs->user_channel_joined && rdp->mcs->global_channel_joined && all_joined)
rdp->state = CONNECTION_STATE_MCS_CHANNEL_JOIN;
rdp->state = CONNECTION_STATE_RDP_SECURITY_COMMENCEMENT;
return TRUE;
}
BOOL rdp_server_accept_client_keys(rdpRdp* rdp, wStream* s)
{
if (!rdp_server_establish_keys(rdp, s))
return FALSE;
rdp->state = CONNECTION_STATE_ESTABLISH_KEYS;
rdp->state = CONNECTION_STATE_SECURE_SETTINGS_EXCHANGE;
return TRUE;
}
BOOL rdp_server_accept_client_info(rdpRdp* rdp, wStream* s)
{
if (!rdp_recv_client_info(rdp, s))
return FALSE;
rdp->state = CONNECTION_STATE_LICENSE;
if (!license_send_valid_client_error_packet(rdp->license))
return FALSE;
rdp->state = CONNECTION_STATE_CAPABILITY;
return TRUE;
}
@ -783,9 +870,6 @@ BOOL rdp_server_accept_confirm_active(rdpRdp* rdp, wStream* s)
if (!rdp_recv_confirm_active(rdp, s))
return FALSE;
rdp->state = CONNECTION_STATE_ACTIVE;
update_reset_state(rdp->update);
if (!rdp_send_server_synchronize_pdu(rdp))
return FALSE;
@ -800,7 +884,7 @@ BOOL rdp_server_reactivate(rdpRdp* rdp)
if (!rdp_send_deactivate_all(rdp))
return FALSE;
rdp->state = CONNECTION_STATE_CAPABILITY;
rdp->state = CONNECTION_STATE_CAPABILITIES_EXCHANGE;
if (!rdp_send_demand_active(rdp))
return FALSE;

View File

@ -37,11 +37,14 @@ enum CONNECTION_STATE
CONNECTION_STATE_MCS_ERECT_DOMAIN = 3,
CONNECTION_STATE_MCS_ATTACH_USER = 4,
CONNECTION_STATE_MCS_CHANNEL_JOIN = 5,
CONNECTION_STATE_ESTABLISH_KEYS = 6,
CONNECTION_STATE_LICENSE = 7,
CONNECTION_STATE_CAPABILITY = 8,
CONNECTION_STATE_FINALIZATION = 9,
CONNECTION_STATE_ACTIVE = 10
CONNECTION_STATE_RDP_SECURITY_COMMENCEMENT = 6,
CONNECTION_STATE_SECURE_SETTINGS_EXCHANGE = 7,
CONNECTION_STATE_CONNECT_TIME_AUTO_DETECT = 8,
CONNECTION_STATE_LICENSING = 9,
CONNECTION_STATE_MULTITRANSPORT_BOOTSTRAPPING = 10,
CONNECTION_STATE_CAPABILITIES_EXCHANGE = 11,
CONNECTION_STATE_FINALIZATION = 12,
CONNECTION_STATE_ACTIVE = 13
};
BOOL rdp_client_connect(rdpRdp* rdp);

View File

@ -211,6 +211,11 @@ static int peer_recv_tpkt_pdu(freerdp_peer* client, wStream* s)
return -1;
break;
case PDU_TYPE_CONFIRM_ACTIVE:
if (!rdp_server_accept_confirm_active(rdp, s))
return -1;
break;
default:
fprintf(stderr, "Client sent pduType %d\n", pduType);
return -1;
@ -228,8 +233,6 @@ static int peer_recv_fastpath_pdu(freerdp_peer* client, wStream* s)
rdp = client->context->rdp;
fastpath = rdp->fastpath;
//if (!fastpath_read_header_rdp(fastpath, s, &length))
// return -1;
fastpath_read_header_rdp(fastpath, s, &length);
@ -258,9 +261,12 @@ static int peer_recv_pdu(freerdp_peer* client, wStream* s)
static int peer_recv_callback(rdpTransport* transport, wStream* s, void* extra)
{
int status = -1;
freerdp_peer* client = (freerdp_peer*) extra;
rdpRdp* rdp = client->context->rdp;
printf("rdp->state: %d\n", rdp->state);
switch (rdp->state)
{
case CONNECTION_STATE_INITIAL:
@ -301,41 +307,67 @@ static int peer_recv_callback(rdpTransport* transport, wStream* s, void* extra)
return -1;
break;
case CONNECTION_STATE_MCS_CHANNEL_JOIN:
case CONNECTION_STATE_RDP_SECURITY_COMMENCEMENT:
if (rdp->settings->DisableEncryption)
{
if (!rdp_server_accept_client_keys(rdp, s))
return -1;
break;
}
rdp->state = CONNECTION_STATE_ESTABLISH_KEYS;
/* FALLTHROUGH */
case CONNECTION_STATE_ESTABLISH_KEYS:
rdp->state = CONNECTION_STATE_SECURE_SETTINGS_EXCHANGE;
return peer_recv_callback(transport, s, extra);
break;
case CONNECTION_STATE_SECURE_SETTINGS_EXCHANGE:
if (!rdp_server_accept_client_info(rdp, s))
return -1;
IFCALL(client->Capabilities, client);
if (!rdp_send_demand_active(rdp))
return -1;
rdp->state = CONNECTION_STATE_LICENSING;
return peer_recv_callback(transport, NULL, extra);
break;
case CONNECTION_STATE_LICENSE:
/* TODO: we don't support licensing so nothing here */
case CONNECTION_STATE_LICENSING:
if (!license_send_valid_client_error_packet(rdp->license))
return FALSE;
rdp->state = CONNECTION_STATE_CAPABILITIES_EXCHANGE;
return peer_recv_callback(transport, NULL, extra);
break;
case CONNECTION_STATE_CAPABILITY:
if (!rdp_server_accept_confirm_active(rdp, s))
case CONNECTION_STATE_CAPABILITIES_EXCHANGE:
if (!s)
{
IFCALL(client->Capabilities, client);
if (!rdp_send_demand_active(rdp))
return -1;
}
else
{
/**
* During reactivation sequence the client might sent some input or channel data
* before receiving the Deactivate All PDU. We need to process them as usual.
*/
Stream_SetPosition(s, 0);
return peer_recv_pdu(client, s);
if (!rdp_server_accept_confirm_active(rdp, s))
{
Stream_SetPosition(s, 0);
return peer_recv_pdu(client, s);
}
rdp->state = CONNECTION_STATE_FINALIZATION;
}
break;
case CONNECTION_STATE_FINALIZATION:
if (peer_recv_pdu(client, s) < 0)
return -1;
break;
case CONNECTION_STATE_ACTIVE:
@ -360,6 +392,7 @@ static BOOL freerdp_peer_close(freerdp_peer* client)
*/
if (!rdp_send_deactivate_all(client->context->rdp))
return FALSE;
return mcs_send_disconnect_provider_ultimatum(client->context->rdp->mcs);
}

View File

@ -926,12 +926,12 @@ static int rdp_recv_callback(rdpTransport* transport, wStream* s, void* extra)
status = -1;
break;
case CONNECTION_STATE_LICENSE:
case CONNECTION_STATE_LICENSING:
if (!rdp_client_connect_license(rdp, s))
status = -1;
break;
case CONNECTION_STATE_CAPABILITY:
case CONNECTION_STATE_CAPABILITIES_EXCHANGE:
if (!rdp_client_connect_demand_active(rdp, s))
status = -1;
break;