The VirtualChannelChunkSize can only be larger than 1600 Bytes, when
both client and server write that value in their capability set
regardless of the value itself.
Also, Microsoft clients and servers only advertise the capabilities that
are relevant for the other peer, e.g. mstsc only tells the server that
it supports decompressing compressed data from the server, but it does
not advertise, that it is able to compress data for the server.
Additionally, correctly apply the read capabilities after reading them.
The VirtualChannelChunkSize setting refers to the VCChunkSize for static
channels and not to the maximum size for DVC data PDUs.
DVC data PDUs are according to [MS-RDPEDYC] always limited to 1600
Bytes.
When enumerating smartcard certificates we check if we have duplicates
in our certificate list. In case we detect a duplicate we just return
`TRUE` (indicating that we consumed the certificate info) but do not
free the smartcard info instance.
Server side we often see "FreeRDP_ChannelDefArray::len expected to be >= 31,
but have XXX", where XXX is lower than 31.
This patche fixes that, the old code was setting the size of ChannelDefArray to the
number of ChannelCount, which is usually not what we want. We want to keep it to 31
and have ChannelCount indicate how many of these channels are used.
* unify reading of domain and username strings with all the checks
* add handling of (undocumented) padding in [MS-RDPBCGR]
2.2.10.1.1.2 Logon Info Version 2 (TS_LOGON_INFO_VERSION_2)
occurring with windows 11
* move type definition to WinPR as used there too.
* supported keyboard types are defined in
[MS-RDPBCGR] 2.2.1.3.2 Client Core Data (TS_UD_CS_CORE)]
use a enum instead of magic numbers to make code more readable.
Commit 2de7a4c249 introduced major changes
in the gateway authentication code. One of these changes was to decouple
NTLM specific authentication from the gateway code.
However with these changes, gateway authenciation with the old RPC code
stopped working and returned an authentication error. The problem is
that currently `credssp_auth_encrypt` encrypts the given message along
creating a signature.
The old code prevented encryption of the message by specifying
`SECBUFFER_READONLY` on the message buffer. The native Windows SSPI then
leaves this buffer as-is and gateway authentication works again.
This fix only applies to Windows platforms using the native SSPI API.
Interestingly this works on other platforms using the WinPR SSPI so
there seems to be a difference between the implementations (but that's a
topic for another PR).
The attributes xPos and yPos for a Color Pointer Update are confusing,
as they may be confused with the xPos and yPos of the pointer bitmap on
the actual screen.
Rename these attributes to what they actually represent, and that is the
hotspot position.
xPos and yPos are still members of the hotspot. However, hotSpotX and
hotSpotY are much more clearer.
In addition to that, the Large Pointer Update uses the same names for
the hotspot coordinates.
Currently, FreeRDP-based server implementations can do connect-time
autodetection.
However, without having any control over it.
In order to be able to override the default connect-time autodetection
handling, introduce three new states for the state machine of the
connection sequence and two new callbacks for the autodetect handling.
These are:
- CONNECTION_STATE_CONNECT_TIME_AUTO_DETECT_BEGIN
- CONNECTION_STATE_CONNECT_TIME_AUTO_DETECT_IN_PROGRESS
- CONNECTION_STATE_CONNECT_TIME_AUTO_DETECT_END
- OnConnectTimeAutoDetectBegin()
- OnConnectTimeAutoDetectProgress()
The END state is pretty simple: When the autodetection is finished and
the autodetect state is FREERDP_AUTODETECT_STATE_COMPLETE, transition
into the next state of the connection sequence.
The BEGIN state is entered, when capability-wise network autodetection
is available.
In this state, the OnConnectTimeAutoDetectBegin callback is called, the
server implementation may initialize any related handling here.
If the server implementation determines, that no further handling is
required, it can end the autodetection phase by returning
FREERDP_AUTODETECT_STATE_COMPLETE.
If not, and an autodetection request is sent, it returns
FREERDP_AUTODETECT_STATE_REQUEST.
The state machine of the connection sequence will then switch into the
IN_PROGRESS state.
In the IN_PROGRESS state, any incoming PDU is handled first, then the
OnConnectTimeAutoDetectProgress callback is called.
Like in the BEGIN state, the return value will determine, whether the
state machine of the connection sequence goes into the END state or goes
into (or rather stays) in the IN_PROGRESS state.
The current state of the autodetect API for the server side does not
include all allowed scenarios where the network autodetection can be
used.
This for example includes the connect-time autodetection, as the
related calls are hidden inside FreeRDP, and not exposed as public API.
In order to avoid duplicate send methods, check the state of the
connection sequence.
If the connection sequence is not yet done, use the connect-time request
types.
Otherwise, use the continuous request types.
The Bandwidth Measure Payload PDU is a little special case, as it is
only allowed to be sent during the connection sequence.
To ensure this, add an assertion in its sending method.
Also fix the handling for the Network Characteristics Sync PDU:
Previously, after parsing the PDU data, the read data was just sent
again to the client, which is wrong.
To fix this issue, introduce a callback for this client-to-server PDU,
so that the actual server implementation can hook up its own handling
for this PDU.
Depending on the situation, the server side may want to discard or use
the retrieved data here.
Moreover, decouple the send-handling for the Network Characteristics
Result PDU from the local autodetect variables.
Currently, these variables are shared between the send and receive
methods.
This leads to access problems, where the server side, wants to use a
different thread to send the autodetect PDU, as the receive handler may
receive an autodetect PDU and overwrite these values with possible
nonsense values.
This is especially the case with RTT response PDUs, as the written
netCharAverageRTT and netCharBaseRTT values are only correct, when only
one RTTRequest happens at a time and no stray RTTResponses are received.
rts_read_common_pdu_header is used to determine if the packet was read
successfully. In that case it might fail but there should be no logging
done to not spam it with unnecessary warnings.
TargetCertificate option is set in TARGET_CERTIFICATE_CONTAINER format.
Exposed ELEMENT_TYPE_CERTIFICATE and ENCODING_TYPE_ASN1_DER1 to allow
building it externally in the mentioned format.
Progressive codec was not honoring the threading flags in settings like does
remoteFX, so even when no multiple threads decoding was asked, progressive was
using multiple threads anyway. This patch fixes it.
During the recent changes the possiblity to perform NLA auth using the
current identity was removed.
In case we receive AUTH_NO_CREDENTIALS with NLA we should resume using a
NULL-identity and not abort the connection.
Authenticate and GatewayAuthenticate return FALSE when there are no
credentials supplied. AuthenticateEx indicates connection termination
with that return value. Handle this accordingly
the new AuthenticateEx callback has a default implementation. To not
break old clients only setting Authenticate or GatewayAuthenticate
callbacks prefer the old ones over the new one.
The spec states that the GUID must be sent as a Base64-encoded GUID in
Unicode format. However in the redirection code we read the (correctly
formatted) GUID and convert it to a binary BLOB.
This PR removes the unnecessary conversion which now results in a
correct RDSTLS auth request.
It also removes some dead code in `rdstls_write_data`.
The client tries to connect using RDSTLS only when it has received a
server redirection PDU with LB_PASSWORD_IS_ENCRYPTED flag.
The server exposes RDSTLS on negotiation if it has been configured on settings.
Then authenticates a client using configured credentials from settings:
RedirectionGuid, Username, Domain, Password.
If a client reconnects on redirection process and uses NLA authentication,
the client was using the old password because it wasn't setting
usePassword to false.
With this commit the client will use the new password.
* extract the certificate from the redirection PDU
* if there is a certificate provided accept it if it matches the
redirection target certificate without further user checks
most protocol internal caches do not need to be exposed. this reduces
the public API and allows us to more easily improve/change this during a
release cycle
Too often experimental flags had been used without the user noticing
that. As bug reports are hard to analyze without proper information take
this approach and inform about experimental flags in use by logging
these.
Currently smartcard settings were only updated in the WIN32 code path.
This must be done on all platforms to have the correct settings (i.e.
pkinitArgs) correctly applied.
Windows seems to favor using the legacy Crypto API (CAPI) for
enumerating RSA key containers and only relies on the newer CNG APIs for
ECC keys.
This PR adds support for CAPI key container enumeration on Windows.
The PR also fixes an issue where the CSP was always set to the MS Base
Smart Card Provider during NLA authentication.
This PR adds a few changes so that a client is able to change the
authentication/logon type in the Authentication callback. I.e. if the
client was started without user/domain the authentication callback is
now able to activate smart card logon by setting the SmartcardLogon
setting along with csp/container/reader name.
Currently if the authentication callback returns `FALSE` the utils
function handle this as scenario as no credentials provided (returns
`AUTH_NO_CREDENTIALS)`.
This PR introduces a new `auth_status` called `AUTH_CANCELLED` that is
returned if the authentication callback returns `FALSE`. If the callback
returns `TRUE` and username or password are empty the util function will
continue to return `AUTH_NO_CREDENTIALS`.
THe PR also fixes some incorrect returns in RPC over HTTP gateway code.
* Properly split certificate_store, certificate_data, certificate and
private key functions to files
* Prefix all functions with freerdp_ to have a unique name
* Update certificate store to use one file per host instead of
known_hosts2
* Merge CryptoCert and rdpCertificate
Currently the proxy's TLS fallback if an NLA connection attempt failed
is broken. There are two issues with the current code that this PR
fixes:
- freerdp_reconnect is used which requires an already established
connection to work correctly. This is not the case since the NLA
connectin attempt failed. This resulted in a seemingly working TLS
connection but i.e. channels where missing/not working.
- The fallback connection attempt just altered the NLA security setting
in the instance's settings. However these settings have been already
modified by the NLA connection attempt so we need to create a copy of
the original connection settings before doing the first connect.
The PR also introduces freerdp_reset_context which restores the initial
connection settings for the given instance.
* Remove duplications in rdpRsaKey, reuse rdpCertificate for public
components
* Move all private key and certificate code to certificate.c,
remove the tssk_* variables from gcc
* Handle update of client and server random keys in wrapping functions
* Simplify gcc_write_server_security_data, use certificate.c functions
to write the certificate data
* Refactor security_establish_keys, use the random values stored in
settings directly
The TPKT header length does not match the [MS-RDPBCGR] 2.2.1.11.1.1
Info Packet (TS_INFO_PACKET) and 2.2.1.11.1.1.1 Extended Info Packet
(TS_EXTENDED_INFO_PACKET) length. print a warning and consume the rest
of the data.
now rdp_write_extended_info_packet only adds the
cbDynamicDSTTimeZoneKeyName, dynamicDSTTimeZoneKeyName and
dynamicDaylightTimeDisabled fields if both, client and server support
the dynamic timezone settings.
__LINE__ is not particularily well defined (most fall back to int).
We want to ensure that all the uses in a format string match the format
specifier, so do an explicit cast
REDIRECTION_VERSION6 breaks redirection for currently unknown reasons.
Revert to the last known good version until we receive an update on
documentation for the redirection handling
* Added missing definitions for RNS_UD_CS_SUPPORT_SKIP_CHANNELJOIN
and RNS_UD_SC_SKIP_CHANNELJOIN_SUPPORTED flags
* Updated stringification functions for these flags
* Implemented client and server EarlyCapabilityFlags filter for
these flags as FreeRDP currently does not implement them.
When using Enhanced RAIL the HandshakeEx flag must also be set. However
in the current code it was always overwritten by the server flags (which
might lack the flag).
The length had more bytes than the RDP_SERVER_REDIRECTION_PACKET
structure because it was counting bytes before the struct.
Using a start variable from the beginnig of sending the structure fixes
it.
When a FreeRDP-based server tried to open a DVC, but the client answered
the DVC create request with a negative CreationStatus in the DVC create
response PDU, the server can then assume that no actual PDUs can be
received for that channel.
However, as long as the channel handle exists, FreeRDP happily forwards
any potential PDU for that handle disregarding the CreationStatus.
This is problematic, since the channel handling usually runs in its own
thread and as a result, the channel may not be destructed yet, when
receiving such stray PDU.
The PDU may be processed, even though it is not expected to be.
A situation, where this becomes problematic is the AUDIO_PLAYBACK_DVC
channel.
It may be the case, that the client answered the DVC create request
with a negative result, the server may try to close the handle and open
the static channel (RDPSND) instead, but before the server can close the
channel handle, the client actually sends PDUs regarding the format
negotiation.
In this case, the server may unintentionally already set things up,
which was not desired (the DVC is about to be closed anyway).
While this specific situation is hypothetical, since it would depend on
a malicious client, it is still possible to happen, especially since the
server implementation does not invoke the format negotiation, but
FreeRDP does it automatically, as soon as the DVC create request is
sent.
Fix this issue by discarding any data PDUs (DYNVC_DATA_FIRST and
DYNVC_DATA) of channels, that were not opened successfully.
With all calls when WTSVirtualChannelQuery returns FALSE that means that
no ppBuffer was allocated, that was not the case with class=WTSVirtualChannelReady.
Most callers were not aware of that, leading to leaks for example when the channel is
not available client-side, the patch changes that so that you have to call call WTSFreeMemory
only if WTSVirtualChannelQuery returned TRUE.
In case alternate shell was set to an empty string ("") the old code
would try to convert it to a WChar string. This resulted in a NULL
pointer being returned by `ConvertUtf8ToWCharAlloc` that was interpreted
as an error and the connection failed.
* Removed comments with invalid assumptions
* Added arguments to rdp_read_info_null_string to indicate if the string
is expected to be '\0' terminated and what is actually read for error
logs
Multi-transport flags must be merged between local and remote so that on both sides
we know the shared parameters. Also this patch sends multi-transport GCC block when
multi-transport is enabled.
We no longer have a blocking polling loop in transport. Instead assume
there is more data after a packet was processed and let the transport
try again. If there is another packet ready, this repeats until only a
partly received (or no new data available) situation is reached.
